Нужно ли реализовывать порт библиотеки C в C?
Я работаю над ядром. Одной из задач при написании ядра является то, что библиотека C должна быть портирована. Некоторые функции, такие как memcmp
, strlen
и так далее надо переписать. Большую часть времени я вижу код, написанный на C, а затем завернутый в extern "C"
, Однако это усложняет мой процесс сборки, потому что много файлов написано на C, и много файлов написано на C++, которые должны быть связаны друг с другом, и это просто головная боль. Было бы неплохо, если бы все это можно было написать на C++.
Будет ли это иметь смысл?
1 ответ
Если этот порт предназначен только для вашего ядра, то вы вполне можете делать все, что хотите. Если вы планируете предоставлять доступ к этой библиотеке пользователям вашего ядра, тогда интерфейс должен быть на языке C. Однако реализация может быть на любом языке, который вы хотите.
Теперь для большинства функций нет особого смысла использовать функцию C++, а затем создавать функцию C для доступа к функции C++, поскольку сама функция не будет использовать C++ (по крайней мере, для таких функций, как , вы бы не действительно нужно использовать
std::find()
, вы можете переписать это на C с помощью простого цикла).
Вы также можете повторно использовать нужные вам функции из библиотеки GNU C. т.е. просто скопируйте эти функции в свою реализацию. Просто не забудьте сохранить ту же лицензию. В этой библиотеке есть много реализаций таких низкоуровневых функций на разных языках ассемблера для ускорения. Функция, например, загружает 64 бита и определяет, есть ли байт 0x00, используя логику (
NOT
,
AND
,
XOR
...), что делает функцию чрезвычайно эффективной.
Библиотека GNU C также включает специальные функции, которые вызывают функции ядра. Те, которые, очевидно, вам не нужны прямо в вашем ядре (ну, наверное, нет, это будет зависеть от вашего ядра).
Наконец, библиотека C намного сложнее, чем просто несколько функций, таких как . Он должен работать с тысячами программ, каждая из которых может быть связана с немного отличающимися версиями. Таким образом, на самом деле может быть 20 версий в одной и той же библиотеке C. Вероятно, это не то, о чем вы хотели бы беспокоиться какое-то время (пока ваше ядро не будет использоваться многими), но это может быть важно для долгосрочной стабильности программного обеспечения, работающего на вашем компьютере. Это особенно важно, если одно программное обеспечение ожидает возврата определенной функции.
EINVAL
(старая версия) и другой, который возвращает
EIO
(более новая версия). Такая крошечная разница действительно важна при работе с тысячами программ.
Опять же, похоже, что вы имеете в виду наличие вспомогательных функций в вашем ядре. Вспомогательные функции, которые доступны в библиотеке C, но не являются реальной библиотекой C (я не думаю, что ядро связывается таким образом). Это должна быть ваша библиотека вспомогательных функций, специфичная для вашего ядра, которую вы связываете статически. На самом деле вы должны добавлять только те функции, которые используются вашим ядром, не более того.
Наконец, если ваше ядро написано на C++, то ваши вспомогательные функции также могут быть написаны на C++. Однако, если вы планируете иметь несколько небольших частей, использующих только C, и некоторые из этих вспомогательных функций будут использоваться в этих небольших частях, тогда будет проще написать эти вспомогательные функции на C.
strlen()
очевидно, необходим только в C, так как в C++ вы хотели бы использовать
std::string::length()
вместо этого член функции.