The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

17.10.2010 20:53  Идеи по усовершенствованию реализации библиотек на языке Си

Расти Рассел (Paul "Rusty" Russel), являющийся разработчиком таких систем как netfilter/iptables и lguest, в своем блоге поделился идеями по разработке библиотек на языке Си, в контексте развития своего нового проекта CCAN - адаптированного для языка Си аналога архива CPAN, в котором представлены небольшие модули с реализацией определенных функций.

Поводом для написания статьи послужил анализ исходных текстов библиотеки для обработки динамических массивов разреженных данных по хеш-индексу Judy и свободного аудио-кодека codec2:

  1. Подготовка существующего кода для пакетирования в библиотеку нарушает наглядность, в основном, из-за большого объема инфраструктуры пакетной информации, требуемой для autoconf, и, даже если исходные тексты, как это часто делается, поместить в src/, порядка не добавится. Например, код Judy состоит из 29 файлов, а к этому добавляется еще 33 файла инфраструктуры - automake, Authors, Changelog, INSTALL, COPYING и 13 файлов README.
  2. Повторяющееся переопределение стандартных типов (типа typedef long или typedef void*) ухудшает читаемость кода, вместо желаемого обеспечения безопасности типов. Так же следует избегать помещения определения структур и объединений (struct, union) в заголовочные файлы (public header files), доступные пользователю библиотеки.
  3. Не стоит выдумывать сложные наименования библиотечных вызовов, напротив, таковые должны быть как можно более короткими, но - запоминаемыми: например, если в библиотеке есть функции создания и разрушения контекста, достаточно их назвать mylib_new() и mylib_free() - в этом случае каждому будет понятно что это такое и что с ним делать.
  4. Идентично сказанному, если для работы библиотеки требуется инициализация, то вызов должен называться mylib_init() или mylib_setup().
  5. Вызовы к библиотеке должны быть реализованы так, чтобы толкование к их использованию было однозначным: например, если успешное завершение вызова mylib_init() необходимо для работы последующих вызовов к библиотеке, то любое нарушение этого правила должно приводить к аварийному завершению программы, скажем через abort() или assert(). Если нужно, или хочется дать пользователю возможность обработки фатальных ошибок библиотеки, сделайте это по аналогии макроса NDEBUG в assert(). В любом случае, обработка пользовательских ошибок не должна тратить время разработчика библиотеки.
  6. Если единственная предполагаемая ошибка при выполнении библиотечного кода - это "нехватка памяти" (out-of-memory), оставьте обработку ошибки пользователю (при этом можно практически быть уверенным в том, что пользователи этого делать не будут, и в этом случае можно ссылаться на правило - "не проверенный тестами код всегда содержит ошибки"). При возникновении ошибок такого типа обычно возвращается NULL в качестве результата. Также можно предложить пользователю зарегистрировать свой обработчик ошибок и пользоваться функционалом setjmp(). Однако это не должно делаться в библиотечном коде.
  7. Всегда возвращайте ошибку пользователю при ее возникновении в коде разрабатываемой библиотеки. Если ошибочная функция возвращает указатель, использование NULL, как индикатора ошибки - обычная практика. Другие типы ошибок также могут возвращать специальные указатели, но чаще всего применяются более простые способы.
  8. Следует тщательно подходить к разработке интерфейса пользователя: лучше его сделать простым и понятным для 90% пользователей (оставшиеся 10% не будут пользоваться им вообще, или переделают по-своему), чем разработать сложный многоуровневый интерфейс и остаться с половиной (из возможного числа) пользователей, так как для другой половины будет проще написать свой собственный интерфейс, чем тратить время на исследование написанного вами.
  9. Имеется стандартное правило для наименования низкоуровневых функций - когда имя начинается с символа подчеркивания (например, _exit()). Следует избегать использования низкоуровневых функций в библиотечном интерфейсе, по причине описанной в предыдущем пункте. Вполне вероятно, что стоит подумать над общей архитектурой и разработать две библиотеки с простым интерфейсом (где одна будет пользоваться функциями другой), вместо одной, но с сложным, многоуровневым интерфейсом.
  10. Вместо использования пространств имен (namespaces), придумайте один префикс к всем поименованным объектам вашей библиотеки, например, opt_, judy или talloc_. Конечно, есть небольшая вероятность что имя объекта в вашей библиотеки пересечется с каким-нибудь другим объектом в пользовательской программе, но все же лучше оставить этот риск, чем давать сложные, практически уникальные, имена типа ccan_rusty_russell_opt_ prefixes, что безусловно добавит головной боли пользователю при использовании вашей библиотеки.
  11. Заголовочные файлы (headers), предоставляемые пользователю, должны быть легко читаемы. Комментарии, в этих файлах могут быть использованы системами самодументирования (как например kerneldoc или doxygen) для поддержания актуальной документации разрабатываемой библиотеки.
  12. На стадии разработки не стоит утруждаться вопросами портирования кода на другие платформы. Если вы сами не собираетесь тестировать код на платформе, отличной от той, где велась разработка, оставьте это на потом. Может быть, это сделает тот, кому это нужно.
  13. Не стоит загромождать заголовочные файлы конструкциями C++ - если вдруг ваша библиотека понадобится разработчику на C++, будет не сложно такую конструкцию добавить непосредственно в код разрабатываемой пользовательской программы, непосредственно перед #include вашего заголовочного файла.
  14. Следует помнить, что в заметке говорится о разработке на языке C, с принятыми в этом языке идентификаторами из строчных букв, с возможными разделителями из символа подчеркивания. Идентификаторы из прописных и строчных букв (BumbyCaps) в языке C не приняты.

В какой-то степени все сказанное касается CCAN и размышлений о том "как убедить людей использовать этот код". Все, что находится на CCAN, сделано на основании Золотого Правила CCAN - "наш код не должен быть уродливым" - CCAN Golden Rule: Our Code Should Not Be Ugly.

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

  • В пакете должен быть файл config.h. Файл включается во все исходные модули собираемой библиотеки, как правило, содержит некоторые специфичные для инсталляции макроопределения в виде #define HAVE_FOO
  • _info файл - на самом деле является C-кодом, в котором [в комментариях] в формате kerneldoc содержатся сведения об авторе, описание пакета и прочая мета-информация, предназначенная для чтения человеком. Этот файл также содержит некоторый исполнимый код, в котором указываются зависимости пакета.
  • "Главный" заголовочный файл, поименованный также как собираемый модуль, с суффиксом ".h", в котором содержится пользовательская документация к пакету, например, описание API для библиотеки.
  • Директория test, содержащая набор примеров, иллюстрирующих функциональность пакета в формате run-*
  • Может быть определен макрос DEBUG, предназначенный для получения отладочной информации, часто в ущерб производительности. Заметим, что это никак не касается функциональности проверок ошибок NDEBUG, о которой упоминалось выше.

Иными словами, это дает возможность сразу увидеть описание модуля при просмотре CCAN.

На CCAN также имеется небольшая утилита namespacize (весьма примитивная, нуждается в доработке), которая предназначена для модификации кода в контексте пространств имен. В настоящее время утилита добавляет префикс ccan_ к вызовам модуля, модифицируя соответственно, все зависимые модули. Таким образом можно решить проблему уникальности имен.

Дополнительная утилита ccanlint, которая выполняет семантический анализ кода, и, в идеале, должна выявить все, о чем говорилось в этом тексте. Разумеется, "интеллекта" утилиты недостаточно, чтобы проверять интерфейсы, однако она вполне хорошо справляется с выявление kerneldoc-комментариев, и даже выделяет из кода и компилирует примеры - фрагменты кода для проверки на наличие "лишних", т.е никогда не выполняемых фрагментов кода в модуле (bitrotted code pieces).

  1. Главная ссылка к новости (http://rusty.ozlabs.org/?p=140...)
Автор новости: vr13
Тип: Обобщение
Ключевые слова: gcc, module, lib
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Линейный вид | Ajax | Показать все | RSS
 
  • 1.3, croster, 22:09, 17/10/2010 [ответить] [смотреть все]
  • +2 +/
    Не согласен с пунктом 12 "На стадии разработки не стоит утруждаться вопросами портирования кода на другие платформы."
    Если разработчик не потрудился проверить работу на нескольких платформах, то он может завязать свою разработку на специфических функциях, работающих лишь на одной платформе. И портирование может превратиться в непростую задачу. Зачем усложнять другим жизнь, когда можно сразу сделать всё по-нормальному?
     
     
  • 2.4, ананим, 22:22, 17/10/2010 [^] [ответить] [смотреть все] [показать ветку]
  • +8 +/
    это у нас так принято, а для человека пологающегося интуитивно на анси С (да и С++) - это естественно.
    под портированием под платформу они как раз подразумевают специфичные функции.
    но, повторяю, когда источником является мсдн, то... ну трухина вы видели.
     
  • 2.8, Ананимуз, 22:54, 17/10/2010 [^] [ответить] [смотреть все] [показать ветку]
  • +/
    А разработчику этого кода оно точно нужно Боюсь многие в таком случае просто ... весь текст скрыт [показать] [показать ветку]
     
  • 2.9, Aesthetus Animus, 23:38, 17/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +2 +/
    Цитируйте до конца Если вы сами не собираетесь тестировать код на платформе,... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.11, croster, 23:47, 17/10/2010 [^] [ответить] [смотреть все]  
  • +1 +/
    Код может быть написан грамотно, но прибит гвоздями к Windows Linux Потом мож... весь текст скрыт [показать]
     
     
  • 4.35, ананим, 14:35, 18/10/2010 [^] [ответить] [смотреть все]  
  • +1 +/
    это уже не грамотный код с точки срения стандартов к примеру fprintf есть в ст... весь текст скрыт [показать]
     
     
  • 5.39, Морозов Алексей, 20:00, 18/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Есть-то он есть, да кто ж его ест В смысле, для того, чтобы правильно и _портаб... весь текст скрыт [показать]
     
     
  • 6.45, Аноним, 00:07, 19/10/2010 [^] [ответить] [смотреть все]  
  • –1 +/
    _портабельно_ - это как указанно в ANSI C стандарте А он на всех платформах еди... весь текст скрыт [показать]
     
     
  • 7.46, Crazy Alex, 00:15, 19/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Та часть, которая предсказуемо работает на всех платформах, уж очень ограниченна... весь текст скрыт [показать]
     
     
  • 8.54, ананим, 11:56, 19/10/2010 [^] [ответить] [смотреть все]  
  • +/
    приведите пример ограниченности пока только сферически-нетривиальные кони в в... весь текст скрыт [показать]
     
     
  • 9.57, Морозов Алексей, 06:08, 21/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Нет, практический опыт написания низкоуровневых приложений а иначе нахрена C ... весь текст скрыт [показать]
     
     
  • 10.59, kshetragia, 05:25, 22/10/2010 [^] [ответить] [смотреть все]  
  • +/
    э-э-э inttypes h не По крайней мере это работает для linux bsd x32 x64 Для... весь текст скрыт [показать]
     
     
  • 11.63, Морозов Алексей, 22:35, 22/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Задание, напомню, касалось вывода целочисленных типов в поток посредством порта... весь текст скрыт [показать]
     
     
  • 12.71, kshetragia, 11:29, 25/10/2010 [^] [ответить] [смотреть все]  
  • +/
    гм.. уже посмотрел..

     
  • 10.60, PereresusNeVlezaetBuggy, 08:41, 22/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Для size_t и ptrdiff_t в POSIX имеются варианты конверсии z и t , соответстве... весь текст скрыт [показать]
     
     
  • 11.61, PereresusNeVlezaetBuggy, 08:48, 22/10/2010 [^] [ответить] [смотреть все]  
  • +/
    А если собирать не посредством VC , то и таких проблем не возникнет ... весь текст скрыт [показать]
     
  • 11.62, Морозов Алексей, 22:30, 22/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Спасибо, Капитан Вы хотите предложить таскать мне за собой гнутый рантайм или ... весь текст скрыт [показать]
     
     
  • 12.64, Морозов Алексей, 22:39, 22/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Ну и да, выше упоминается off_t, а не ptrdiff_t Который, как известно, нынче ск... весь текст скрыт [показать]
     
     
  • 13.66, PereresusNeVlezaetBuggy, 23:15, 22/10/2010 [^] [ответить] [смотреть все]  
  • +/
    inttypes h входит в C99 Что ещё тут сказать Да, не все компиляторы поддержив... весь текст скрыт [показать]
     
  • 12.65, PereresusNeVlezaetBuggy, 23:07, 22/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Всего лишь заголовочный файл Мимо ... весь текст скрыт [показать]
     
     
  • 13.67, Морозов Алексей, 04:43, 23/10/2010 [^] [ответить] [смотреть все]  
  • +/
    П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий in... весь текст скрыт [показать]
     
     
  • 14.68, PereresusNeVlezaetBuggy, 05:04, 23/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Вы это серьёзно Или вы в inttypes h ни разу не заглядывали code fprintf m... весь текст скрыт [показать]
     
     
  • 15.69, Морозов Алексей, 11:38, 23/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Отлично Вы эти макросы в реальной жизни пробовали применять Впрочем, вижу, про... весь текст скрыт [показать]
     
     
  • 16.70, PereresusNeVlezaetBuggy, 13:13, 23/10/2010 [^] [ответить] [смотреть все]  
  • +/
    gt оверквотинг удален Этот вопрос не ставился Был вопрос о реальности портабе... весь текст скрыт [показать]
     
  • 9.58, Морозов Алексей, 06:18, 21/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Да, готовьтесь к тому, что во второй части нашей увлекательной викторины а умее... весь текст скрыт [показать]
     
  • 3.17, Фкуку, 01:40, 18/10/2010 [^] [ответить] [смотреть все]  
  • –2 +/
    Нет слов VM POSIX Ничего не говорят ИМХО, код на Си, НЕ ЗАДУМАННЫЙ ... весь текст скрыт [показать]
     
     
  • 4.21, www2, 07:42, 18/10/2010 [^] [ответить] [смотреть все]  
  • +6 +/
    Если думать обо всём и сразу, то есть риск вообще не сдвинуться с места, погрязнув во второстепенных вопросах. В Free Software принят подход Release Early, Realease Often. Выпускай раньше, выпускай чаще. Пусть код будет работать уже сейчас хотя бы на части платформ, чем теоретически будет работать на всех платформах, но через неопределённое время. То, что уже выпущено - это не окончательный вариант, а материал для дальнейшей работы.
     
  • 4.33, ананим, 14:20, 18/10/2010 [^] [ответить] [смотреть все]  
  • +/
    код на анси С сам по себе кроссплатформеннее некуда и анси С полностью соответс... весь текст скрыт [показать]
     
  • 4.47, Crazy Alex, 00:24, 19/10/2010 [^] [ответить] [смотреть все]  
  • +1 +/
    Пункт 1, как раз - чуть ли не единственный разумный пункт autotools это вообще ... весь текст скрыт [показать]
     
     
  • 5.56, ананим, 04:16, 20/10/2010 [^] [ответить] [смотреть все]  
  • +/
    остаётся только заставить все целевые платформы следовать этому, не побоюсь сказ... весь текст скрыт [показать]
     
     
  • 6.75, Crazy Alex, 05:59, 03/11/2010 [^] [ответить] [смотреть все]  
  • +/
    Ничего страшного К pkg-config приучается же народ понемногу А если на паре-тро... весь текст скрыт [показать]
     
  • 5.73, Aleksey Cheusov, 17:45, 25/10/2010 [^] [ответить] [смотреть все]  
  • +/
    http sourceforge net projects mk-configure http mova org cheusov pub mk-co... весь текст скрыт [показать]
     
  • 2.18, 2Nike, 02:02, 18/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +5 +/
    Проблема в том, что разработчик не всегда имеет одинаковый скилл на всех платфор... весь текст скрыт [показать] [показать ветку]
     
  • 2.34, z, 14:34, 18/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    какие сложности - бери да пиши всё с нуля... весь текст скрыт [показать] [показать ветку]
     
  • 2.55, andr.ru, 12:17, 19/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    Как минимум надо переходить от Си на С , кодом гораздо проще управлять А вообщ... весь текст скрыт [показать] [показать ветку]
     
  • 1.6, Aesthetus Animus, 22:39, 17/10/2010 [ответить] [смотреть все]  
  • +1 +/
    Очень здравая и ясная идея! То, что перечислено в списке, - в общем то очевидно, но наконец это все сказано в одном ключе и в слух.
     
     
  • 2.10, 310dej, 23:40, 17/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    Очевидное зло - Есть библиотеки хорошие, и есть не хорошие, а есть и корпорати... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.15, Андрей, 00:42, 18/10/2010 [^] [ответить] [смотреть все]  
  • +/
    если им это покажется здравым и полезным - то "ВайНо?"
     
  • 1.12, Ariel, 23:58, 17/10/2010 [ответить] [смотреть все]  
  • +/
    >mylib_free()

    Так нужно:
    MyContextFree(MyContext *con)

     
     
  • 2.20, www2, 07:36, 18/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +1 +/
    Там же ясно написано, что в Plain C не принято использовать CamelCase.
     
     
  • 3.23, klalafuda, 08:00, 18/10/2010 [^] [ответить] [смотреть все]  
  • –4 +/
    Простите - кем написано Расти Раселом Пардон, но при всем уважении к его творе... весь текст скрыт [показать]
     
     
  • 4.24, www2, 08:11, 18/10/2010 [^] [ответить] [смотреть все]  
  • +3 +/
    Это не его личная позиция, это общепринятая практика Посмотрите на стандартные ... весь текст скрыт [показать]
     
     
  • 5.26, klalafuda, 08:17, 18/10/2010 [^] [ответить] [смотреть все]  
  • +/
    При всем уважении к стандартам ANSI C и POSIX, описываемое ими API и принятая в ... весь текст скрыт [показать]
     
     
  • 6.27, www2, 08:26, 18/10/2010 [^] [ответить] [смотреть все]  
  • +3 +/
    Такой стиль был принят - создателеми языка Д Ричи , - всей группой разработчи... весь текст скрыт [показать]
     
     
  • 7.28, klalafuda, 08:58, 18/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Вообще то мир C распространяется существенно дальше K R, ANSI C, POSIX etc и м... весь текст скрыт [показать]
     
     
  • 8.29, www2, 09:19, 18/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Вообще-то, именно так и принято Хотя я конечно не говорю, что всё остальное зап... весь текст скрыт [показать]
     
  • 8.37, Аноним, 16:02, 18/10/2010 [^] [ответить] [смотреть все]  
  • +3 +/
    Вот уж что точно не надо вспоминать Все эти ужасные BOOL и BYTE, всяческие hVie... весь текст скрыт [показать]
     
     
  • 9.49, Crazy Alex, 00:28, 19/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Ну, их в основном за длину названий и венгерскую нотацию ругают Кстати, венгерс... весь текст скрыт [показать]
     
  • 5.48, Crazy Alex, 00:26, 19/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Вы будете удивлены, но в плюсах точно так же принято функции стандартной библиот... весь текст скрыт [показать]
     
  • 4.31, Аноним, 10:16, 18/10/2010 [^] [ответить] [смотреть все]  
  • +1 +/
    Расти в комментариях поправляется ... весь текст скрыт [показать]
     
  • 1.13, VoDA, 00:05, 18/10/2010 [ответить] [смотреть все]  
  • –7 +/
    Странно, что описанные выше проблемы еще существуют в этом веке на java много... весь текст скрыт [показать]
     
     
  • 2.19, 2Nike, 02:02, 18/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    Когда появился java, а когда си ... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.41, segoon, 20:21, 18/10/2010 [^] [ответить] [смотреть все]  
  • +/
    Для чего существует Java, а для чего си :)
     
  • 2.42, User294, 20:54, 18/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    Только на java нельзя написать многое из того что на сях пишется только в путь ... весь текст скрыт [показать] [показать ветку]
     
  • 2.51, Crazy Alex, 00:31, 19/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    Да хоть бы и так Чего ж не взять идею, если она хороша Главное глупости не тян... весь текст скрыт [показать] [показать ветку]
     
  • 1.16, Аноним, 01:16, 18/10/2010 [ответить] [смотреть все]  
  • +/
    "аналога архива CPAN для языка Си"

    кажется, опечатка...

     
  • 1.22, klalafuda, 07:56, 18/10/2010 [ответить] [смотреть все]  
  • +/
    Что-то как-то IMHO многовато шума для столь мелкого проекта. По крайней мере если судить по содержимому их 'репозитория'. Вот выйдет народ на какой-то более-менее вменяемый объем - ОК. Будет повод сравнивать их с тем же CPAN-ом. Пока же это даже на страничку Васи Пупкина не тянет.
     
     
  • 2.25, www2, 08:13, 18/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +1 +/
    Всегда приходится с чего-то начинать Linux начинался с эмулятора терминала, раб... весь текст скрыт [показать] [показать ветку]
     
  • 1.30, Аноним, 09:46, 18/10/2010 [ответить] [смотреть все]  
  • –1 +/
    >"наш код не должен быть уродливым"
    >Plain C

    Слегка поделили на 0.

     
     
  • 2.36, PereresusNeVlezaetBuggy, 14:40, 18/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +2 +/
    На Си можно писать изящно А можно не изящно А можно не писать Их цель достижи... весь текст скрыт [показать] [показать ветку]
     
  • 2.40, gegMOPO4, 20:14, 18/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    По сравнению с бытовавшими в то время языками -- да, Си изящный И сейчас в опре... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.44, User294, 20:59, 18/10/2010 [^] [ответить] [смотреть все]  
  • –3 +/
    Да, выписывать веб-приложение типа Ынтерпрайзной CRM на голых сях можно и подзад... весь текст скрыт [показать]
     
  • 2.43, User294, 20:56, 18/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    Только совсем слегка На сях порой попадается отличный код Простой в понимании,... весь текст скрыт [показать] [показать ветку]
     
  • 1.32, anonymous, 12:43, 18/10/2010 [ответить] [смотреть все]  
  • +/
    >Не стоит загромождать заголовочные файлы конструкциями C++ - если вдруг ваша библиотека понадобится разработчику на C++, будет не сложно такую конструкцию добавить непосредственно в код разрабатываемой пользовательской программы, непосредственно перед #include вашего заголовочного файла.

    Это он про extern "C"

     
     
  • 2.38, anonymous, 18:14, 18/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    мне кажется, это он про C++ обёртки blabla->make_zashibis(); для blabla_make_zashibis(blabla);
     
     
  • 3.53, Crazy Alex, 00:35, 19/10/2010 [^] [ответить] [смотреть все]  
  • +1 +/
    > мне кажется, это он про C++ обёртки blabla->make_zashibis(); для blabla_make_zashibis(blabla);

    А вот такие "обёртки" делаются только с горя. Как правило гораздо больше толку, если автор позаботился предоставить плюсовый API, работающий непосредственно с внутренностями библиотеки. Можете как пример на libev глянуть.

     
  • 2.52, Crazy Alex, 00:32, 19/10/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    >>Не стоит загромождать заголовочные файлы конструкциями C++ - если вдруг ваша библиотека понадобится разработчику на C++, будет не сложно такую конструкцию добавить непосредственно в код разрабатываемой пользовательской программы, непосредственно перед #include вашего заголовочного файла.
    > Это он про extern "C"

    Ну тогда логично. Я уж подумал, что он наезжает на те библиотеки, которые предоставляют ещё и плюсовый интерфейс.

     
  • 1.72, Aleksey Cheusov, 17:29, 25/10/2010 [ответить] [смотреть все]  
  • +/
    Пункт 1 легко исправляется выбором правильного инструмента для сборки проекта.

    http://sourceforge.net/projects/mk-configure/

    Один (под)проект -- один Makefile.
    Одна команда для сборки проекта -- mkcmake.
    Все.

     
     
  • 2.74, nuclight, 18:30, 02/11/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    > Пункт 1 легко исправляется выбором правильного инструмента для сборки проекта.
    > http://sourceforge.net/projects/mk-configure/
    > Один (под)проект -- один Makefile.
    > Одна команда для сборки проекта -- mkcmake.
    > Все.

    Ээ, он уже больше не на bmake? или стал таскать с собой?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor