Реализовать стандартную библиотеку C на C ++ - PullRequest
4 голосов
/ 24 февраля 2011

Скажем, ОС / ядро ​​написано с учетом C ++ и не «делает» ничего, что связано с чистым стилем C, но вместо этого предоставляет стандартную библиотеку C, основанную на полноценной стандартной библиотеке C ++. Это возможно? Если нет, то почему?

PS: я знаю, что библиотека C является "частью C ++", но, допустим, она внутренне основана на реализации на C ++.

Небольшое обновление: Кажется, я вызвал дискуссию о том, что "разрешено" моими правилами здесь. Вообще говоря: реализация библиотеки C Standard должна использовать C ++ везде, где это возможно / Right (tm). Я в основном думаю об алгоритмах и действиях со статическими объектами класса за кулисами. Я не на самом деле , исключая какие-либо языковые функции, но вместо этого пытаюсь сделать акцент на разумной реализации C ++. Что касается примера setjmp, я не вижу причин, по которым действительный C (который использовал бы либо другие предварительно реализованные в C ++ части библиотеки C, либо вообще не использовал бы другие библиотечные функции) был бы нарушением моих «правил». Если в библиотеке C ++ нет аналога, зачем обсуждать его использование.

Ответы [ 5 ]

4 голосов
/ 19 августа 2011

На самом деле, c ++ может быть во многих отношениях на быстрее , чем c, благодаря своей способности поддерживать многие конструкции времени перевода, такие как шаблоны выражений. По этой причине матричные библиотеки c ++, как правило, гораздо более оптимизированы, чем c, включают меньше временных, развертываемых циклов и т. Д. С новыми функциями c ++ 0x, такими как шаблоны вариантов, функция printf, например, может быть намного быстрее и безопаснее типов, чем версия реализована в ц. Он даже сможет соблюдать интерфейсы многих конструкций c и оценивать некоторые из их аргументов (например, строковые литералы).

К сожалению, многие люди думают, что c быстрее, чем c ++, потому что многие люди используют ООП, чтобы означать, что все отношения и использование должны происходить через большие иерархии наследования, виртуальную диспетчеризацию и т. Д. Это привело к тому, что некоторые ранние сравнения полностью отличались от того, что считается хорошее использование в эти дни. Если бы вы использовали виртуальную диспетчеризацию там, где это уместно (например, как файловые системы в ядре, где они создают виртуальные таблицы через указатели функций и часто в основном собирают c ++ в c), у вас не будет пессимизации от c и со всеми новыми функциями. , может быть значительно быстрее.

Мало того, что скорость - это возможное улучшение, но есть места, где реализация выиграет от большей безопасности типов. В c есть общие приемы (например, хранение данных в пустых указателях, когда они должны быть общими), которые нарушают безопасность типов и где c ++ может обеспечить строгую проверку ошибок. Это не всегда транслируется через интерфейсы к библиотеке c, так как они имеют фиксированную типизацию, но это определенно будет полезно для разработчиков библиотеки и может помочь в некоторых местах, где возможно извлечь больше информации из вызовов предоставляя интерфейсы «как если» (например, интерфейс, который принимает void *, может быть реализован как универсальный интерфейс с концептуальной проверкой того, что аргумент неявно преобразуется в void *).

Я думаю, это было бы отличным испытанием силы c ++ над c.

4 голосов
/ 24 февраля 2011

Да, это возможно.Это было бы очень похоже на экспорт C API из библиотеки, написанной на C ++, FORTRAN, ассемблере или почти любом другом языке.

1 голос
/ 24 февраля 2011

Учитывая, что «чистый материал C» имеет такое большое совпадение с C ++, я не вижу, как вы могли бы избежать этого целиком во всем, а тем более в ядре ОС. В конце концов, операция + - это "чистый материал C"? :)

Тем не менее, вы, безусловно, могли бы реализовать определенные функции библиотеки C, используя классы и еще много чего. Реализовать qsort используя std :: sort? Конечно, без проблем. Только не забудь свой extern "C".

0 голосов
/ 24 февраля 2011

Я не вижу причин, почему вы не могли бы сделать это, но я также не вижу причин, по которым кто-то мог бы использовать такую ​​реализацию. Он будет использовать намного больше памяти и, по крайней мере, несколько медленнее, чем обычная реализация ... хотя это может быть не намного хуже, чем glibc, чья реализация stdio в любом случае уже по сути C ++ ... (Lookup GNU libio ... вы будете в ужасе.)

0 голосов
/ 24 февраля 2011

Ядра, такие как Linux, имеют очень строгий ABI, основанный на системных вызовах, ioctl, файловых системах и соответствующий довольно многим стандартам (основным из которых является POSIX).Поскольку ABI должен быть стабильным, его поверхность также ограничена.Было бы много работы (особенно потому, что вам нужно минимально полезное ядро), но эти стандарты могут быть реализованы на любом языке.

Редактировать: Вы упомянули и libc.Это не является частью ядра, и язык libc может быть совершенно не связан с языком ядра благодаря вышеупомянутому ABI.В отличие от ядра, libc должен быть C или иметь очень хороший ffi для C. C ++ с частями в extern C будет соответствовать всем требованиям.

...