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 (ok), 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 (ok), 23:38, 17/10/2010 [^] [ответить]     [к модератору]
  • +2 +/
    Цитируйте до конца Если вы сами не собираетесь тестировать код на платформе,... весь текст скрыт [показать]
     
     
  • 3.11, croster (ok), 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 (ok), 05:25, 22/10/2010 [^] [ответить]     [к модератору]  
  • +/
    э-э-э inttypes h не По крайней мере это работает для linux bsd x32 x64 Для... весь текст скрыт [показать]
     
     
  • 11.63, Морозов Алексей (?), 22:35, 22/10/2010 [^] [ответить]     [к модератору]  
  • +/
    Задание, напомню, касалось вывода целочисленных типов в поток посредством порта... весь текст скрыт [показать]
     
     
  • 12.71, kshetragia (ok), 11:29, 25/10/2010 [^] [ответить]    [к модератору]  
  • +/
    гм.. уже посмотрел..

     
  • 10.60, PereresusNeVlezaetBuggy (ok), 08:41, 22/10/2010 [^] [ответить]     [к модератору]  
  • +/
    Для size_t и ptrdiff_t в POSIX имеются варианты конверсии z и t , соответстве... весь текст скрыт [показать]
     
     
  • 11.61, PereresusNeVlezaetBuggy (ok), 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 (ok), 23:15, 22/10/2010 [^] [ответить]     [к модератору]  
  • +/
    inttypes h входит в C99 Что ещё тут сказать Да, не все компиляторы поддержив... весь текст скрыт [показать]
     
  • 12.65, PereresusNeVlezaetBuggy (ok), 23:07, 22/10/2010 [^] [ответить]     [к модератору]  
  • +/
    Всего лишь заголовочный файл Мимо ... весь текст скрыт [показать]
     
     
  • 13.67, Морозов Алексей (?), 04:43, 23/10/2010 [^] [ответить]     [к модератору]  
  • +/
    П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий in... весь текст скрыт [показать]
     
     
  • 14.68, PereresusNeVlezaetBuggy (ok), 05:04, 23/10/2010 [^] [ответить]     [к модератору]  
  • +/
    Вы это серьёзно Или вы в inttypes h ни разу не заглядывали code fprintf m... весь текст скрыт [показать]
     
     
  • 15.69, Морозов Алексей (?), 11:38, 23/10/2010 [^] [ответить]     [к модератору]  
  • +/
    Отлично Вы эти макросы в реальной жизни пробовали применять Впрочем, вижу, про... весь текст скрыт [показать]
     
     
  • 16.70, PereresusNeVlezaetBuggy (ok), 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 (ok), 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 (ok), 22:39, 17/10/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Очень здравая и ясная идея! То, что перечислено в списке, - в общем то очевидно, но наконец это все сказано в одном ключе и в слух.
     
     
  • 2.10, 310dej (?), 23:40, 17/10/2010 [^] [ответить]    [к модератору]  
  • +/
    Очевидное зло :-) Есть библиотеки хорошие, и есть не хорошие, а есть и корпоративные. Примут ли это к сведению корпорации, работающие на Си? Для меня большой вопрос.
     
     
  • 3.15, Андрей (??), 00:42, 18/10/2010 [^] [ответить]    [к модератору]  
  • +/
    если им это покажется здравым и полезным - то "ВайНо?"
     
  • 1.12, Ariel (ok), 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 (ok), 00:05, 18/10/2010 [ответить] [показать ветку] [···]     [к модератору]  
  • –7 +/
    Странно, что описанные выше проблемы еще существуют в этом веке на java много... весь текст скрыт [показать]
     
     
  • 2.19, 2Nike (ok), 02:02, 18/10/2010 [^] [ответить]     [к модератору]  
  • +/
    Когда появился java, а когда си ... весь текст скрыт [показать]
     
     
  • 3.41, segoon (ok), 20:21, 18/10/2010 [^] [ответить]    [к модератору]  
  • +/
    Для чего существует Java, а для чего си :)
     
  • 2.42, User294 (ok), 20:54, 18/10/2010 [^] [ответить]    [к модератору]  
  • +/
    > на java многое из этого уже решено.

    Только на java нельзя написать многое из того что на сях пишется только в путь.

     
  • 2.51, Crazy Alex (??), 00:31, 19/10/2010 [^] [ответить]    [к модератору]  
  • +/
    Да хоть бы и так. Чего ж не взять идею, если она хороша. Главное глупости не тянуть, вроде здоровенных нечитабельных XML-конфигов, сборщиков мусора и связывания рук разработчиков ;-) Но могу порадовать - CCAN эти названия каталогов содрал у перла :-) Как и название.
     
  • 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 +/
    > Что-то как-то IMHO многовато шума для столь мелкого проекта. По крайней мере
    > если судить по содержимому их 'репозитория'. Вот выйдет народ на какой-то
    > более-менее вменяемый объем - ОК. Будет повод сравнивать их с тем
    > же CPAN-ом. Пока же это даже на страничку Васи Пупкина не
    > тянет.

    Всегда приходится с чего-то начинать. Linux начинался с эмулятора терминала, работающего в многозадачном режиме на i386. Я лично эту инициативу приветствую.

     
  • 1.30, Аноним (-), 09:46, 18/10/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    >"наш код не должен быть уродливым"
    >Plain C

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

     
     
  • 2.36, PereresusNeVlezaetBuggy (ok), 14:40, 18/10/2010 [^] [ответить]    [к модератору]  
  • +2 +/
    >>"наш код не должен быть уродливым"
    >>Plain C
    > Слегка поделили на 0.

    На Си можно писать изящно. А можно не изящно. А можно не писать. Их цель достижима, а уж то, насколько их это ограничивает, если ограничивает, это их проблемы, а не тех, кто не видел изящного кода на Си.

    P.S.: Если какая-то задача решается одной-двумя строчками на Си против десятка на ЯВУ, то это потому что Си неизящный, да?..

     
  • 2.40, gegMOPO4 (ok), 20:14, 18/10/2010 [^] [ответить]    [к модератору]  
  • +/
    По сравнению с бытовавшими в то время языками -- да, Си изящный.

    И сейчас в определённых областях он едва ли не лучшее решение. Просто появились новые области, и приоритеты изменились.

     
     
  • 3.44, User294 (ok), 20:59, 18/10/2010 [^] [ответить]     [к модератору]  
  • –3 +/
    Да, выписывать веб-приложение типа Ынтерпрайзной CRM на голых сях можно и подзад... весь текст скрыт [показать]
     
  • 2.43, User294 (ok), 20:56, 18/10/2010 [^] [ответить]    [к модератору]  
  • +/
    >>"наш код не должен быть уродливым"
    >>Plain C
    > Слегка поделили на 0.

    Только совсем слегка. На сях порой попадается отличный код. Простой в понимании, читабельный, где грабельки успешно и изящно обрулены и прочая.

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

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

     

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


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