Я хочу написать библиотеку, которая будет динамически связана с другими программами, работающими в современных операционных системах, таких как Windows, Linux и OS/X (т. Е. Будет использоваться как модульили .so).Выбор языка для переносимой библиотеки
Что является наиболее подходящим языком в этом случае? Должен ли я придерживаться равнины C? Или C++ тоже нормально?
Вы можете использовать C или C++ для реализации, но я бы рекомендовал определить интерфейс в чистом C. Его будет намного проще интегрировать.
Я бы сказал, что C является наиболее предсказуемо переносимым, но C++ выполним.
Я бы также сказал, что C является самым низким общим знаменателем. У вас всегда есть возможность написать оболочку C++ в основную библиотеку, если она лучше интегрируется с вызывающим приложением.
Рассмотрите фактор наименьшего общего знаменателя и сделайте, чтобы потребители ваших библиотек принимали решения, которые лучше всего подходят для них. Конструкция extern c, вероятно, все еще путает некоторых людей, и вы хотите, чтобы ваша библиотека далеко продвинулась и охватила самую широкую аудиторию. Определенно сделайте интерфейсы чистыми c. C++ прекрасно, если вы избегаете некоторых более темных углов (например, STL). C - самая портативная панель. Создание библиотек для всех доступных платформ - это не маленький подвиг, поэтому не забудьте взглянуть на некоторые подсказки here. Вы также можете рассмотреть возможность использования autoconf и т. П.
Люди, которые не grok 'extern« C », не являются разработчиками на C++, которые вы хотите удовлетворить. Они такие люди, которые будут обманывать вас другими простыми вещами вместо RTFM/RTFSO. // Использование AUtoconf означает, что ваша программа станет более переносимой для машин Unix 20-го века, но менее переносимой для Windows. Для большинства людей это означает отказ от 95% рынка в обмен на 0,01% рынка (не преувеличенный), а тем более для серверного программного обеспечения. – MSalters
Я не могу ничего сделать, но соглашусь с вашими заявлениями. Это сложная проблема, которая не имеет простого решения. – ojblass
Использование CMake вместо autoconf даст вам тот же набор интроспекции и конфигурации + больше. Включая Windows. И как личное мнение, в гораздо более чистом виде. – Joakim
Сложность создания библиотеки C++, распределенная в двоичной форме, заключается в том, что ваши клиенты - пользователи библиотеки - обычно вынуждены использовать один и тот же компилятор C++ при создании библиотеки. Это может быть проблематично, если вы хотите быть в курсе событий, а они нет, или если они хотят быть в курсе событий, а вы этого не делаете. Если вы имеете дело с источником, это не проблема, если ваш C++ достаточно портативен, чтобы он мог использоваться всеми компиляторами, которые используют ваши клиенты.
Если код может быть использован с C, я бы, вероятно, написал код для интерфейса C. Альтернативный, предоставить два интерфейса - собственный C++-интерфейс и C-интерфейс. Но это больше, чем просто интерфейс C. С другой стороны, могут быть преимущества интерфейса C++ (возможно, с использованием итераторов STL и т. Д.), И это может повлиять на ваше решение.
Также дает людям, потребляющим библиотеки свободу выбора того, что лучше всего подходит для них. – ojblass
Да. Мало кто возражает против идеи прямого интерфейса OpenGL ES. Но программист Objective-C вообще не может копать интерфейс C++. – Nosredna