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
Тип: Обобщение
Короткая ссылка: https://opennet.ru/28305-gcc
Ключевые слова: gcc, module, lib
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (69) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | 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). Потом может кому и захочется на Linux (Windows) портировать, но затраты будут достаточно велики (а возможно и написать с нуля будет гораздо проще).
     
     
  • 4.35, ананим (?), 14:35, 18/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    это уже не грамотный код.
    с точки срения стандартов.
    к примеру fprintf есть в стандарте C, cin/cout есть в стандарте С++, а WWriteFile есть в стандарте только винапи.
    первые доступны на любой платформе, последняя только на винде (вайны не в счет)

    так вот, когда нормальные люди пишут подобные документы, то им даже в голову не приходит, что кто-то по умолчанию за стандарты берет стандарты мс (или других вендоров).
    а когда нормальные люди говорят о портировании, то предполагают что кому-то на винде (и только на винде) когда-нибудь потом,по какой-либо существенной причине захочется вместо fprintf вызывать WriteFile.
    мысль, что намертво прибитый код может быть грамотным - даже в голову не придет.

     
     
  • 5.39, Морозов Алексей (?), 20:00, 18/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > к примеру fprintf есть в стандарте C

    Есть-то он есть, да кто ж его ест. В смысле, для того, чтобы правильно и _портабельно_ воспользоваться fprintf в нетривиальных случаях (с нетривиальными модификаторами/типоуказанием), надо не полениться заглянуть в man на фряхе, инфо на линуксе и MSDN на винде.

     
     
  • 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?..
    Ничего не говорят?
    ИМХО, код на Си, НЕ ЗАДУМАННЫЙ СРАЗУ, как мультиплатформенный - дебилизм.
    п.1 меня ваще вводит в оторопь.
    Расти Рассел откровенно страдает фимозом головного мозга.

     
     
  • 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 это вообще дикость. Вместо того, чтобы держать в среде информацию о ней же и модифицировать при изменениях среды, идёт длиннющая и неудобочитаемая последовательность эвристик, тупо повторяющаяся для каждого пакета.
    А за предложение делать примитивные интерфейсы вместо простого API, основанного на сложном, автору надо что-нибудь оторвать. Как и за идею отказаться от вменяемой диагностики и обработки ошибок и тупо завершать программу. Да и рекомендация свалить проблемы плюсовиков на них самих, мягко говоря, не идеальна.

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

    В общем, по поводу фимоза - согласен.

     
     
  • 5.56, ананим (?), 04:16, 20/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Вместо того, чтобы держать в среде информацию о ней же и модифицировать при изменениях среды,

    остаётся только заставить все целевые платформы следовать этому, не побоюсь сказать, благородному порыву.
    ну а пока они не следуют, приходится по старинке, но ~100% рабочим способом.
    >А за предложение делать примитивные интерфейсы вместо простого API,

    вы уверены в понимании аббревиатуры API?
    в общем, автор статьи как-то больше импонирует, чем ваш комментарий.

     
     
  • 6.75, Crazy Alex (??), 05:59, 03/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего страшного. К pkg-config приучается же народ понемногу. А если на паре-тройке основных платформ будет, то и остальные потянутся. А пока можно просто смотреть - если что-то определено - брать инфу, если нет - автотулзы, по старинке. В общем, вопрос маркетинга в основном.
     
  • 5.73, Aleksey Cheusov (?), 17:45, 25/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Пункт 1, как раз - чуть ли не единственный разумный пункт. autotools
    > это вообще дикость.

    http://sourceforge.net/projects/mk-configure/
    http://mova.org/~cheusov/pub/mk-configure/mkc-presentation.pdf

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

    Состояния среды можно держать в mkc-mk/sys.mk,
    но в конкретно imake даже хуже на практике.

    > Как и за идею отказаться от вменяемой
    > диагностики и обработки ошибок и тупо завершать программу. Да и рекомендация
    > свалить проблемы плюсовиков на них самих, мягко говоря, не идеальна.

    +2

     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Как минимум надо переходить от Си на С++, кодом гораздо проще управлять.

    А вообще давно пора искать альтернативы лексическому программированию - это получается не математика, а литературный жанр. Писано миллионы и миллиарды строк кода, которые приходится всё время переписывать и дописывать - изъян в самой системе кодирования. Надо смотреть в сторону UML и FSM. Один раз решённые задачи не придется никогда пересматривать и решение будет математически точным и конечным, исключающим бесконечное "улучшение кода", "рефакторинг" либо использование кода непредусмотренным образом вирусами.

    Прошло полвека с рождения фортрана и Си, нужен качественный скачок. Индустрия в застое, бурно растущие базы кода непомерно дороги и недолговечны в использовании, содержат массу ошибок и дыр. Надо менять систему. Тогда не надо будет долго ломать голову над названием очередной главы писательского труда - MyLibForCoolHacker() или mylib_fch() :), можно будет просто написать ряд "математических формул", строго задающих поведение системы.

    http://www2.research.att.com/~fsmtools/fsm/

     

  • 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 +/
    > Там же ясно написано, что в Plain C не принято использовать CamelCase.

    Простите - кем написано? Расти Раселом? Пардон, но при всем уважении к его творениям он явно далек от позиции чтобы диктовать, что в языке C принято а что - нет. Это у него - не принято. И бога ради. Это его личная позиция. Но - не более того.

     
     
  • 4.24, www2 (??), 08:11, 18/10/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это не его личная позиция, это общепринятая практика. Посмотрите на стандартные библиотеки ANSI C, посмотрите на POSIX API, не используется там CamelCase. Есть два типа имён - макросы пишутся полностью ЗАГЛАВНЫМИ_БУКВАМИ, и всё остальное, пишется строчными_буквами. Названия типов данных дополняются суффиксом _t. Использование CamelCase в Plain C может быть скорее вашей личной позицией, но не более того.
     
     
  • 5.26, klalafuda (?), 08:17, 18/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Это не его личная позиция, это общепринятая практика. Посмотрите на стандартные библиотеки ANSI C, посмотрите на POSIX API, не используется там CamelCase. Есть два типа имён - макросы пишутся полностью ЗАГЛАВНЫМИ_БУКВАМИ, и всё остальное, пишется строчными_буквами. Названия типов данных дополняются суффиксом _t. Использование CamelCase в Plain C может быть скорее вашей личной позицией, но не более того.

    При всем уважении к стандартам ANSI C и POSIX, описываемое ими API и принятая в нем стилистика - это лишь мизерная часть от того, что было так или иначе разработано с использованием языка C в глобальном масштабе. Предвидя аргумент a'la 'А вот в ядре Linux/BSD/etc..' - да, и ядро Linux/BSD/etc это так же очень небольшая часть от.

    Есть огромное количество самых разнообразных проектов, которые используют язык C. И открытых и закрытых и ещё бог знает каких. И вот так вот с легкой руки ровнять всех под одну гребенку и заявлять что мол 'в языке C что-то принято или не принято' - это мягко говоря несколько самоуверенно. Слишком самоуверенно. На грани фолта.

     
     
  • 6.27, www2 (??), 08:26, 18/10/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> При всем уважении к стандартам ANSI C и POSIX, описываемое ими API
    > и принятая в нем стилистика - это лишь мизерная часть от
    > того, что было так или иначе разработано с использованием языка C
    > в глобальном масштабе. Предвидя аргумент a'la 'А вот в ядре Linux/BSD/etc..'
    > - да, и ядро Linux/BSD/etc это так же очень небольшая часть
    > от.

    Такой стиль был принят:
    - создателеми языка (Д. Ричи),
    - всей группой разработчиков Unix (К. Томпсон, Б. Керниган и т.д.), для разработки которой и был изначально придуман Си,
    - в стандарте ANSI C,
    - в стандартах POSIX API.

    Если этого авторитета вам не достаточно, то разговаривать с вами дальше не имеет смысла.

    > Есть огромное количество самых разнообразных проектов, которые используют язык C. И открытых
    > и закрытых и ещё бог знает каких. И вот так вот
    > с легкой руки ровнять всех под одну гребенку и заявлять что
    > мол 'в языке C что-то принято или не принято' - это
    > мягко говоря несколько самоуверенно. Слишком самоуверенно. На грани фолта.

    Вы точно не путаете Plain C и C++?

    И вообще, что-то вы не похожи на klalafuda, он был более сдержан в высказываниях и всегда подписывался. И "На грани фолта." он бы не сказал, он грамотный.

     
     
  • 7.28, klalafuda (?), 08:58, 18/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Такой стиль был принят:
    > -создателеми языка (Д. Ричи),
    > -всей группой разработчиков Unix (К. Томпсон, Б. Керниган и т.д.), для разработки > которой и был изначально придуман Си,
    > -в стандарте ANSI C,
    > -в стандартах POSIX API.
    > Если этого авторитета вам не достаточно, то разговаривать с вами дальше не имеет смысла.

    Вообще то 'мир C' распространяется существенно дальше K&R, ANSI C, POSIX etc и мягко говоря ими не ограничен. Думаю, с этим фактом никто спорить не будет? Вспомнить хотя бы WinAPI и прикинуть, сколько на его базе было написано самого разнообразного софта. И принятый в нем стиль имеет ни чуть не меньшее право на существование, чем скажем стиль POSIX. А сколько ещё существует стилистических подходов к оформлению кода на C? Масса.

    Замечу, я сейчас не расставляю оценок какой из подходов лучше а какой хуже. WinAPI vs POSIX, CamelCase vs other etc. Оставим это бессмысленное занятие кому-нибудь другому. Но факт остается фактом: проектов на C существует огромное количество равно как и подходов к их стилистическому оформлению. И нельзя однозначно утверждать, что мол 'в C принято так то и так то и никак иначе'. Популярность и реальная применимость языка в тех или иных живых проектах давно уже шагнула бесконечно дальше чем те рамки и проекты, в которых он изначально разрабатывался.

    > И вообще, что-то вы не похожи на klalafuda, он был более сдержан в высказываниях и всегда подписывался. И "На грани фолта." он бы не сказал, он грамотный.

    Все течет, все меняется.

     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Вы будете удивлены, но в плюсах точно так же принято функции стандартной библиотеки и буста писать через подчёркивания. Это даёт возможность чётко видеть, что стандартно, а что - пользовательские функции, написанные в camelCase. И это удобно.
     
  • 4.31, Аноним (-), 10:16, 18/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Расти в комментариях поправляется:

    > Author comment by rusty | October 15, 2010 at 8:48 pm
    > I assume you’re being sarcastic? But just in case…
    > “standard” meaning “normal practice”. And also “as used by the standard”, since anyone familiar with the C standard library will be aware how prevalent this practice is (and also how weird exceptions like “FILE *” look).
    > I don’t think there’s a point in the standard saying “thou shalt not use BumpyCaps”; there are so many more effective ways to write ugly code which can’t be banned even if you wanted to. But if you use the standard libraries, your code won’t be consistently BumpyCaps anyway, so why start?

     

  • 1.13, VoDA (ok), 00:05, 18/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Странно, что описанные выше "проблемы" еще существуют в этом веке. на java многое из этого уже решено. А оставшееся - учить разработчиков как писать адекватный код.

    сложилось впечатление что CCAN это аналог подсистемы maven отвечающей за сбор проекта.

    PS совпадение src и test считаем просто совпадением ;)

     
     
  • 2.19, 2Nike (ok), 02:02, 18/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Странно, что описанные выше "проблемы" еще существуют в этом веке. на java
    > многое из этого уже решено. А оставшееся - учить разработчиков как
    > писать адекватный код.

    Когда появился 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:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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