Идеальная кроссплатформенная библиотека

Question

Нужно создать новую библиотеку программного обеспечения. Эта библиотека не имеет системных процедур ввода-вывода и содержит только функции Init (config), Run (some_data_inputs) и DeInit (config) и несколько typedef и определений. Функция Run () просто обрабатывает заданные входные данные и генерирует выходные данные, без прерываний, потоков, блокировок и т. Д. Однако для внутренних нужд ей требуется некоторое количество оперативной памяти. Интерфейс описан в заголовочном файле, а статическая библиотека содержит реализацию.

Эта библиотека должна быть максимально многоплатформенной. Должно пройти несколько минут, чтобы перенести эту библиотеку на любую новую платформу на любую новую ОС + ЦП. Иногда эту библиотеку можно использовать даже на платформах без операционных систем.

Итак, прежде чем начинать разработку, нужно решить:

1. Должна ли эта библиотека быть написана в ANSI-C или даже в подмножестве ANSI-C, потому что некоторые платформы могут не полностью поддерживать ANSI-C?
2. Писать ли абстракцию слой, который инкапсулирует ОС + процессор?
3. Должен ли этот слой абстракции включить собственный менеджер памяти (malloc / free рутины) или все платформы уже сегодня это предоставляют?

Answer 1

1. Должна ли эта библиотека быть написана в ANSI-C или даже в подмножестве ANSI-C потому что некоторые платформы могут не поддерживать ANSI-C полностью?

Также я не предлагаю ISO C. ANSI не был органом по стандартизации для C с 1990 года. ISO C90 должен быть повсеместным. В зависимости от возможностей целевой платформы прилагаемая стандартная библиотека может быть подмножеством или может потребовать реализации заглушек для ее переноса на конкретную цель. Библиотека Newlib C, часто используемая во встроенных системах, использующих, например, GCC, требует базовых заглушек ввода-вывода (в этом случае не требуется, поскольку вы указали, что операции ввода-вывода не выполняются) и реализуемой функции sbrk (). sbrk () предоставляет память распределителю кучи; она не требует ОС или может запросить память у ОС.

1. Нужно ли писать слой абстракции, который инкапсулирует ОС + процессор?

Дайте ограничения, которые вы наложили на этот дизайн библиотеки, кажется, что нет проблем с ОС. Стандартная библиотека предоставляет требования к выделению памяти.

1. Должен ли этот уровень абстракции включать собственный менеджер памяти (malloc / free рутины) или все платформы уже сегодня это предоставляют?

Ответил в (1); предоставить их как часть стандартной библиотеки или использовать существующую реализацию для платформы.

В конце концов, вам нужно написать свою библиотеку для использования C90 и стандартной библиотеки, тогда просто нужно перенести стандартную библиотеку на целевой объект, если это еще не сделано.

Answer 2

В обратном порядке:

(3). Вам нужны ваши собственные процедуры управления памятью, если не по любой другой причине, а просто потому, что вы ожидаете, что она может быть перенесена на платформу без базовой ОС. Тогда вам также понадобится реализация почти для всего остального: строковых библиотек, математических библиотек и т. Д. Вы должны либо сами кодировать их, либо пытаться найти готовые библиотеки кода, которые предоставляют их для каждой платформы.

(2). ОС и ЦП являются несколько ортогональными переменными. Возможно, вам лучше будет создать два уровня абстракции (один для разных операционных систем, один для разных аппаратных платформ), а затем включить / переопределить определения по мере необходимости для каждой новой платформы. Но да, уровень абстракции является более управляемым решением, чем загромождать ваш код целыми ордами # ifdefs.

(1). Это не простой вопрос. Например, если вы ожидаете, что ваша библиотека будет работать на встроенной системе или даже на микроконтроллере, то вполне вероятно, что не все функции ANSI C доступны, в зависимости от уровня зрелости инструментов разработки. Также могут быть ограничения, не обязательно связанные с самим языком. Аппаратные блоки с плавающей запятой относительно редко встречаются во встроенных системах. Размеры стеков могут быть ограничены и т. Д. Я предлагаю вам сделать обзор интересующих вас платформ и попытаться выбрать общее подмножество.

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

(- 1). Вы должны понять из-за нехватки (или даже полного отсутствия) библиотек с требуемым уровнем переносимости, что то, чего вы хотите достичь, не будет легким. Будьте готовы!

Answer 3

Существует множество различных стилей системной архитектуры, и написать что-то нетривиальное, легко переносимое для всех из них, вероятно, невозможно.

Тем не менее, я предлагаю вам написать свои интерфейсы, чтобы они брали указатель на структуру, которая содержит все необходимые системные функции. Это можно сделать либо при каждом вызове, либо только один раз в процедуре инициализации.

Таким образом, вы будете ограничивать места, где различия в коде для разных архитектур, кодом, который генерирует структуру указателей функций.

Это также позволяет легко протестировать библиотеку на предмет обработки сбоя одной или нескольких из этих подпрограмм, изменив только эту структуру, так что если вы хотите проверить правильность обработки сбоя malloc, вы просто замените malloc указатель в структуре с ошибкой.

Вы можете также обернуть системные функции в конкретной системе функциями, которые предоставляют вам интерфейс, ожидаемый вашей библиотекой, а также, по крайней мере, частичную обработку ошибок (например, перевод в / из errno).