Расти Рассел (http://en.wikipedia.org/wiki/Rusty_Russell) (Paul "Rusty" Russel), являющийся разработчиком таких систем как netfilter/iptables и lguest, в своем блоге (http://rusty.ozlabs.org/?p=140) поделился идеями по разработке библиотек на языке Си, в контексте развития своего нового проекта CCAN (http://ccan.ozlabs.org/index.html) - аналога архива CPAN для языка Си, в котором представлены (http://ccan.ozlabs.org/list.html) небольшие модули с реализацией определенных функций.
Поводом для написания статьи послужил анализ исходных текстов библиотеки для обработки динамических массивов разреженных данных по хеш-индексу Judy (http://judy.sourceforge.net/) и свободного аудио-кодека codec2 (http://codec2.org/):- Подготовка существующего кода для пакетирования в библиотеку нарушает наглядность, в основном, из-за большого объема инфраструктуры пакетной информации, требуемой для autoconf, и, даже если исходные тексты, как это часто делается, поместить в src/, порядка не добави...
URL: http://rusty.ozlabs.org/?p=140
Новость: http://www.opennet.me/opennews/art.shtml?num=28305
Не согласен с пунктом 12 "На стадии разработки не стоит утруждаться вопросами портирования кода на другие платформы."
Если разработчик не потрудился проверить работу на нескольких платформах, то он может завязать свою разработку на специфических функциях, работающих лишь на одной платформе. И портирование может превратиться в непростую задачу. Зачем усложнять другим жизнь, когда можно сразу сделать всё по-нормальному?
это у нас так принято, а для человека пологающегося интуитивно на анси С (да и С++) - это естественно.
под портированием под платформу они как раз подразумевают специфичные функции.
но, повторяю, когда источником является мсдн, то... ну трухина вы видели.
А разработчику (этого кода) оно точно нужно? Боюсь многие в таком случае просто забьют на идею поделиться.
Цитируйте до конца ;)
"Если вы сами не собираетесь тестировать код на платформе, отличной от той, где велась разработка, оставьте это на потом."И это как раз ключевой момент. Пусть код работает только на некоторых платформах, но делает это хорошо ;) Если код написан грамотно, а это как раз и оговаривается в остальных пунктах и в их лозунге, то его не составит труда портировать тому, кому это надо.
Код может быть написан грамотно, но прибит гвоздями к Windows (Linux). Потом может кому и захочется на Linux (Windows) портировать, но затраты будут достаточно велики (а возможно и написать с нуля будет гораздо проще).
это уже не грамотный код.
с точки срения стандартов.
к примеру fprintf есть в стандарте C, cin/cout есть в стандарте С++, а WWriteFile есть в стандарте только винапи.
первые доступны на любой платформе, последняя только на винде (вайны не в счет)так вот, когда нормальные люди пишут подобные документы, то им даже в голову не приходит, что кто-то по умолчанию за стандарты берет стандарты мс (или других вендоров).
а когда нормальные люди говорят о портировании, то предполагают что кому-то на винде (и только на винде) когда-нибудь потом,по какой-либо существенной причине захочется вместо fprintf вызывать WriteFile.
мысль, что намертво прибитый код может быть грамотным - даже в голову не придет.
> к примеру fprintf есть в стандарте CЕсть-то он есть, да кто ж его ест. В смысле, для того, чтобы правильно и _портабельно_ воспользоваться fprintf в нетривиальных случаях (с нетривиальными модификаторами/типоуказанием), надо не полениться заглянуть в man на фряхе, инфо на линуксе и MSDN на винде.
_портабельно_ - это как указанно в ANSI C стандарте. А он на всех платформах един ...
Та часть, которая предсказуемо работает на всех платформах, уж очень ограниченна. Учитывая, что даже на размер переменной не заложишься - а для разных размеров нужны разные модификаторы.
приведите пример "ограниченности".
пока только сферически-нетривиальные кони в вакууме.это во-первых.
а во-вторых, портирование под платформу (а эти кони именно так и называются) никто не отменял. просто заморачиваться этим не стоит на первом этапе.зы:
про размеры переменных - это несчастный инт что ли?
1. его, инта, не та уж много. 2. а нахрена на размер закладываться? достаточно того, что его в любой момент можно подсчитать. 3. не пользуйтесь интом.
> приведите пример "ограниченности".
> пока только сферически-нетривиальные кони в вакууме.Нет, практический опыт написания низкоуровневых приложений (а иначе нахрена C ?)
> это во-первых.
> а во-вторых, портирование под платформу (а эти кони именно так и называются)
> никто не отменял. просто заморачиваться этим не стоит на первом этапе.И, в результате "портирования" выясняется, что дешевле НЕ пользоваться всем из себя таким _портабельным_ , "ANSI-Сишным" и бла-бла fprintf и иже с ними, а нагородить свой велосипедик разной степени убогости, и в следующем проекте использовать именно его.
> зы:
> про размеры переменных - это несчастный инт что ли?
> 1. его, инта, не та уж много.
> 2. а нахрена на размер закладываться? достаточно того, что его в любой момент можно
> подсчитать.
> 3. не пользуйтесь интом.Ох... В C им и так почти не пользуются. А пользуются, например, типом size_t. Или off_t. Или ещё какой int16_t. Итак, Вы, кажется, знаете, как "портабельно" напечатать в поток эти
чудесные типы данных? На всём многообразии платформ, для которых есть компиляторы C, хоть сколько-нибудь претендующие на "ANSI-Сишность". Рецепт, что называется, в студию!
> Ох... В C им и так почти не пользуются. А пользуются, например, типом size_t. Или off_t. Или
> ещё какой int16_t. Итак, Вы, кажется, знаете, как "портабельно" напечатать в поток эти
> чудесные типы данных?э-э-э... inttypes.h не?
По крайней мере это работает для linux/bsd x32/x64. Для винды похоже придется писать свой.
>> Ох... В C им и так почти не пользуются. А пользуются, например, типом size_t. Или off_t. Или
>> ещё какой int16_t. Итак, Вы, кажется, знаете, как "портабельно" напечатать в поток эти
>> чудесные типы данных?
> э-э-э... inttypes.h не?
> По крайней мере это работает для linux/bsd x32/x64. Для винды похоже придется
> писать свой.Задание, напомню, касалось вывода целочисленных типов в поток посредством "портабельного и ANSI-Сишного" fprintf & Co. inttypes.h не при делах, см. соседние сообщения
гм.. уже посмотрел..
> Ох... В C им и так почти не пользуются. А пользуются, например,
> типом size_t. Или off_t. Или ещё какой int16_t. Итак, Вы, кажется,
> знаете, как "портабельно" напечатать в поток эти
> чудесные типы данных? На всём многообразии платформ, для которых есть компиляторы C,
> хоть сколько-нибудь претендующие на "ANSI-Сишность". Рецепт, что называется, в студию!Для size_t и ptrdiff_t в POSIX имеются варианты конверсии "z" и "t", соответственно. Для работы с целочисленными же типами есть inttypes.h; На тех платформах, где его нет изначально (Windows), можно взять готовый и адаптировать. Это будет заметно меньше работы, чем полностью городить свой огород, равно как и его поддерживать.
>> Ох... В C им и так почти не пользуются. А пользуются, например,
>> типом size_t. Или off_t. Или ещё какой int16_t. Итак, Вы, кажется,
>> знаете, как "портабельно" напечатать в поток эти
>> чудесные типы данных? На всём многообразии платформ, для которых есть компиляторы C,
>> хоть сколько-нибудь претендующие на "ANSI-Сишность". Рецепт, что называется, в студию!
> Для size_t и ptrdiff_t в POSIX имеются варианты конверсии "z" и "t",
> соответственно. Для работы с целочисленными же типами есть inttypes.h; На тех
> платформах, где его нет изначально (Windows), можно взять готовый и адаптировать.
> Это будет заметно меньше работы, чем полностью городить свой огород, равно
> как и его поддерживать.А если собирать не посредством VC++, то и таких проблем не возникнет.
> Для size_t и ptrdiff_t в POSIX имеются варианты конверсии "z" и "t",Спасибо, Капитан.
> соответственно. Для работы с целочисленными же типами есть inttypes.h; На тех
> платформах, где его нет изначально (Windows), можно взять готовый и адаптировать.
> Это будет заметно меньше работы, чем полностью городить свой огород, равно
> как и его поддерживать.Вы хотите предложить таскать мне за собой гнутый рантайм (или сравнительно свежий BSD'шный). Что ж, это решение, покуда у вас есть "настоящая платформа". Как только дело начнёт касаться всяких аппаратно-программных недоразумений - тут внезапно и выяснится, что переносимость, а, главное, применимость гнутого рантайма - сильно преувеличена. Поспрашайте людей, пишущих под телефоны и прочие "имбеддеды".
>> Для size_t и ptrdiff_t в POSIX имеются варианты конверсии "z" и "t",
> Спасибо, Капитан.Ну и да, выше упоминается off_t, а не ptrdiff_t. Который, как известно, нынче скорее 64'битный "на линуксах", но, во-первых, и там необязательно и достигается дифайном при компиляции, и, во-вторых, кое-где - по-прежнему 32-х битный. Специального модификатора для него в POSIX'овом printf'е нет.
P.S. Замечу, от ANSI C-шного стандарта мы как-то тихой сапой уползли в POSIX. Что, замечу, существенно сокращает и выбор рантаймов, и выбор компиляторов для них.
>>> Для size_t и ptrdiff_t в POSIX имеются варианты конверсии "z" и "t",
>> Спасибо, Капитан.
> Ну и да, выше упоминается off_t, а не ptrdiff_t. Который, как известно,
> нынче скорее 64'битный "на линуксах", но, во-первых, и там необязательно и
> достигается дифайном при компиляции, и, во-вторых, кое-где - по-прежнему 32-х битный.
> Специального модификатора для него в POSIX'овом printf'е нет.
> P.S. Замечу, от ANSI C-шного стандарта мы как-то тихой сапой уползли в
> POSIX. Что, замечу, существенно сокращает и выбор рантаймов, и выбор компиляторов
> для них.<inttypes.h> входит в C99. Что ещё тут сказать? Да, не все компиляторы поддерживают C99. Если у кого-то нет inttypes.h в наборе разработчика, может взять из BSD-шного и, если возникнет такая необходимость, доработать.
>> соответственно. Для работы с целочисленными же типами есть inttypes.h; На тех
>> платформах, где его нет изначально (Windows), можно взять готовый и адаптировать.
>> Это будет заметно меньше работы, чем полностью городить свой огород, равно
>> как и его поддерживать.
> Вы хотите предложить таскать мне за собой гнутый рантайм (или сравнительно свежий
> BSD'шный).Всего лишь заголовочный файл.
> Что ж, это решение, покуда у вас есть "настоящая платформа".
> Как только дело начнёт касаться всяких аппаратно-программных недоразумений - тут внезапно
> и выяснится, что переносимость, а, главное, применимость гнутого рантайма - сильно
> преувеличена. Поспрашайте людей, пишущих под телефоны и прочие "имбеддеды".Мимо. :)
> Всего лишь заголовочный файл.П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий inttypes.h в вопросе форматирования сообщения fprintf'ом? Кое-кто здорово заменил исходную задачу той, с которой ему удобно сражаться, и понеслось...
> Мимо. :)
Это точно, точнее не скажешь.
Итого, подведём промежуточные итоги. Исходным тезисом являлось утверждение о том, что (ANSI-) C'шный рантайм обладает достаточной портабельностью и универсальностью, чтобы можно было не задумываясь применять его в широкопортабельных проектах (порты с Ubuntu/32 на Debian/64 не в счёт). В качестве примера такой универсальной функции приводился классический fprintf.
В результате 4 (четырёх) попыток ответа на вопрос, как отформатировать fprintf'ом вывод типов size_t, off_t и int16_t, я дождался от Вас только предложения форматировать size_t при помощи модификатора z (непортабельного в заметной степени), ненужных мне, в общем, сведений о том, как форматировать ptrdiff_t и предложения таскать за собой _реализацию_ fprintf'а из glibc (или *BSD libc или любой другой открытой реализации С-шного рантайма, непринципиально). Ещё Вы порадовали меня предложением не использовать MSVC++.
Мне кажется, Вы уже исчерпали допустимый лимит неправильных ответов на такой простой, не правда ли, вопрос?
>> Всего лишь заголовочный файл.
> П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий inttypes.h
> в вопросе форматирования сообщения fprintf'ом? Кое-кто здорово заменил исходную задачу
> той, с которой ему удобно сражаться, и понеслось...Вы это серьёзно? Или вы в inttypes.h ни разу не заглядывали?
/* fprintf macros for signed integers */
#define PRId8 "d" /* int8_t */
#define PRId16 "d" /* int16_t */
#define PRId32 "d" /* int32_t */
#define PRId64 "lld" /* int64_t */
И т.д.>[оверквотинг удален]
> классический fprintf.
> В результате 4 (четырёх) попыток ответа на вопрос, как отформатировать fprintf'ом вывод
> типов size_t, off_t и int16_t, я дождался от Вас только предложения
> форматировать size_t при помощи модификатора z (непортабельного в заметной степени), ненужных
> мне, в общем, сведений о том, как форматировать ptrdiff_t и предложения
> таскать за собой _реализацию_ fprintf'а из glibc (или *BSD libc или
> любой другой открытой реализации С-шного рантайма, непринципиально).Вам что, очевидные вещи разжёвывать надо? Так за этим вы не по адресу, это к Марьиванне из детского сада. Или сделать
printf("%" PRIdLEAST64, some_value)религия не позволяет? Или скажете, что это не даст гарантированно искомое?> Ещё Вы порадовали меня предложением не использовать MSVC++.
Как самый простой способ не связываться с кастратом под названием msvcrt. Впрочем, в нём есть свои фишки, спорить не буду. Поэтому это было лишь предложение, для _поставленной_ задачи.
> Мне кажется, Вы уже исчерпали допустимый лимит неправильных ответов на такой простой,
> не правда ли, вопрос?Да ну? А вы-то что умеете, кроме как задавать вопросы и напускать на себя важный вид?
(что-то я опять язвительный сверх меры... пойду-ка посплю)
> #define PRId8 "d" /* int8_t */
> #define PRId16 "d" /* int16_t */
> #define PRId32 "d" /* int32_t */
> #define PRId64 "lld" /* int64_t */Отлично. Вы эти макросы в реальной жизни пробовали применять? Впрочем, вижу, пробовали:
>
printf("%" PRIdLEAST64, some_value)религия не позволяет?увы, религия не позволяет. Потому что:
1. такой способ записи подходит только в лабораторных условиях. _Читать_ (а наглядность - главное достоинство printf-like форматирования) подобный код - задача не для слабонервных. Попробуйте туда засунуть ещё пару целочисленных значений, да с какими-нибудь модификаторами для разнообразия, и результат показать здесь. А потом оценить количество людей, которым понравится портабельность _такой_ ценой.
2. от того, что я придумаю макрос PRIdLEAST64 там, где его нет, "стандартная для платформы" реализация printf не научится волшебным образом понимать эти самые 64битные значения.
3. в исходной задаче говорилось про size_t, off_t и int16_t. Случай int16_t разобрали выше. Для size_t и off_t, по факту, требуется {configure/compile}-time проверки с выбором между этими типами, и "обычными" int/long/etc там, где рантайм не в курсе POSIX'овых умностей. Опять же, см. пп.1 и 2.
4. Впереди ещё форматирование многобайтных строчек и непрямое (через *) указание аргументов.
>>> Всего лишь заголовочный файл.
>> П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий inttypes.h
>> в вопросе форматирования сообщения fprintf'ом? Кое-кто здорово заменил исходную задачу
>> той, с которой ему удобно сражаться, и понеслось...
> Вы это серьёзно? Или вы в inttypes.h ни разу не заглядывали?Ну, макросов этих не помню, но, честно, они не помогают, см. возражения выше.
> (что-то я опять язвительный сверх меры... пойду-ка посплю)
Давайте. Авось, язвительность ненужная поутихнет.
P.S. буквально в среду разглядывал реализации такого форматирования сначала в сысоевском коде, а потом в ещё одном проекте, претендующем на переносимость. И чего это люди не горят использовать стандартные механизмы в своих проектах ;)
>[оверквотинг удален]
>> #define PRId32 "d" /* int32_t */
>> #define PRId64 "lld" /* int64_t */
> Отлично. Вы эти макросы в реальной жизни пробовали применять? Впрочем, вижу, пробовали:
>>printf("%" PRIdLEAST64, some_value)религия не позволяет?
> увы, религия не позволяет. Потому что:
> 1. такой способ записи подходит только в лабораторных условиях. _Читать_ (а наглядность
> - главное достоинство printf-like форматирования) подобный код - задача не для
> слабонервных. Попробуйте туда засунуть ещё пару целочисленных значений, да с какими-нибудь
> модификаторами для разнообразия, и результат показать здесь. А потом оценить количество
> людей, которым понравится портабельность _такой_ ценой.Этот вопрос не ставился. Был вопрос о реальности портабельности «родными» средствами языка. Это не говоря о том, что описываемые вами ситуации в рамках нормальной программы — редкость. Часто повторяющиеся *printf() выносятся в отдельные функции, и т.д. Впрочем, я могу не представлять себе какого-то проблемного класса программ — продемонстрируете?
> 2. от того, что я придумаю макрос PRIdLEAST64 там, где его нет,
> "стандартная для платформы" реализация printf не научится волшебным образом понимать эти
> самые 64битные значения.Если «стандартная для платформы» реализация *printf не умеет понимать 64-битные значения (что, вообще говоря, нонсенс; пусть операции с 64-битными числами не будут атомарными, но они будут; впрочем, я не слишком большой спец в embedded-разработках), то и в программе не будет встречаться int64_t и иже с ним, так? Иначе ведь она всё равно на данной платформе даже не скомпилируется.
А если не будут встречаться 64-битные числа, то тогда используем макрос PRIdLEAST32... Ну и т.д.
> 3. в исходной задаче говорилось про size_t, off_t и int16_t. Случай int16_t
> разобрали выше. Для size_t и off_t, по факту, требуется {configure/compile}-time проверки
> с выбором между этими типами, и "обычными" int/long/etc там, где рантайм
> не в курсе POSIX'овых умностей. Опять же, см. пп.1 и 2.Эм-м-м... Рантайм, он вообще, не в курсе size_t, off_t и так далее. Это чисто компиляторные заморочки. Оператор sizeof() ещё никто не отменял. Зачем делать выбор между типами size_t/off_t/etc. и int/long/etc., когда достаточно просто объявить size_t/off_t/etc. в случае их отсутствия (во время того же конфигурирования, или компиляции, например)?
> 4. Впереди ещё форматирование многобайтных строчек
А какое отношение имеют многобайтные строчки к размеру переменных? Для начала, какие у вас вообще строчки? char*? wchar_t*? А то вы всё пугаете, пугаете...
Стандартная библиотека предоставляет средства для форматирования строк в некоторых форматах. Если вам нужна экзотика — you're on your own, как в любой другой среде. Собственно, давно есть (портабельные, хе-хе) библиотеки для работы со специфическими кодировками, так что велосипед, опять же, изобретать не требуется...
> и непрямое (через *) указание аргументов.
И в чём здесь проблема? Не все платформы поддерживают? Ну простите... Возьмите тогда заодно точно так же BSD-шную реализацию *printf и таскайте с собой для таких случаев, в чём проблема-то? Не вижу серьёзных причин для того, чтобы всё с нуля переписывать.
>>>> Всего лишь заголовочный файл.
>>> П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий inttypes.h
>>> в вопросе форматирования сообщения fprintf'ом? Кое-кто здорово заменил исходную задачу
>>> той, с которой ему удобно сражаться, и понеслось...
>> Вы это серьёзно? Или вы в inttypes.h ни разу не заглядывали?
> Ну, макросов этих не помню, но, честно, они не помогают, см. возражения
> выше.Они помогают, а единственное возражение было — «плохо читается». Хотя в общем случае я с этим аргументом согласен (удобочитаемость кода очень важна), всё же позволю себе заметить, что использование альтернативной системы для форматирования строк повышает сложность программы, что тоже не есть гуд.
> P.S. буквально в среду разглядывал реализации такого форматирования сначала в сысоевском
> коде, а потом в ещё одном проекте, претендующем на переносимость. И
> чего это люди не горят использовать стандартные механизмы в своих проектах
> ;)Это их выбор, я их не спрашивал, вы, по всей видимости, тоже (иначе бы не вопрос задавали, а давали факты). Люди ещё пишут тысячи однотипных CMS на PHP, и эти CMS от своего количества лучше не становятся.
Да, готовьтесь к тому, что во второй части нашей увлекательной викторины "а умеешь ли ты программировать на C" мы коснёмся таких интересных возможностей, как fprintf и многобайтные строки, возможность непрямого указания аргументов и других вроде бы стандартизованных возможностей *printf
Нет слов... :(
VM... POSIX?..
Ничего не говорят?
ИМХО, код на Си, НЕ ЗАДУМАННЫЙ СРАЗУ, как мультиплатформенный - дебилизм.
п.1 меня ваще вводит в оторопь.
Расти Рассел откровенно страдает фимозом головного мозга.
Если думать обо всём и сразу, то есть риск вообще не сдвинуться с места, погрязнув во второстепенных вопросах. В Free Software принят подход Release Early, Realease Often. Выпускай раньше, выпускай чаще. Пусть код будет работать уже сейчас хотя бы на части платформ, чем теоретически будет работать на всех платформах, но через неопределённое время. То, что уже выпущено - это не окончательный вариант, а материал для дальнейшей работы.
код на анси С сам по себе кроссплатформеннее некуда.
и анси С полностью соответсвует посиккс.
собственно посикс для программиста на С - это и есть сишная библа аля глибси.вот оно наше образование.
Пункт 1, как раз - чуть ли не единственный разумный пункт. autotools это вообще дикость. Вместо того, чтобы держать в среде информацию о ней же и модифицировать при изменениях среды, идёт длиннющая и неудобочитаемая последовательность эвристик, тупо повторяющаяся для каждого пакета.
А за предложение делать примитивные интерфейсы вместо простого API, основанного на сложном, автору надо что-нибудь оторвать. Как и за идею отказаться от вменяемой диагностики и обработки ошибок и тупо завершать программу. Да и рекомендация свалить проблемы плюсовиков на них самих, мягко говоря, не идеальна.А вообще говоря - лучше бы сразу закладывались на плюсы в варианте "С с классами". Как минимум, глупостей вроде mylib_myfunction можно было бы избежать, используя нормальные пространства имён.
В общем, по поводу фимоза - согласен.
>Вместо того, чтобы держать в среде информацию о ней же и модифицировать при изменениях среды,остаётся только заставить все целевые платформы следовать этому, не побоюсь сказать, благородному порыву.
ну а пока они не следуют, приходится по старинке, но ~100% рабочим способом.
>А за предложение делать примитивные интерфейсы вместо простого API,вы уверены в понимании аббревиатуры API?
в общем, автор статьи как-то больше импонирует, чем ваш комментарий.
Ничего страшного. К pkg-config приучается же народ понемногу. А если на паре-тройке основных платформ будет, то и остальные потянутся. А пока можно просто смотреть - если что-то определено - брать инфу, если нет - автотулзы, по старинке. В общем, вопрос маркетинга в основном.
> Пункт 1, как раз - чуть ли не единственный разумный пункт. autotools
> это вообще дикость.http://sourceforge.net/projects/mk-configure/
http://mova.org/~cheusov/pub/mk-configure/mkc-presentation.pdf> Вместо того, чтобы держать в среде информацию о
> ней же и модифицировать при изменениях среды, идёт длиннющая и неудобочитаемая
> последовательность эвристик, тупо повторяющаяся для каждого пакета.Состояния среды можно держать в mkc-mk/sys.mk,
но в конкретно imake даже хуже на практике.> Как и за идею отказаться от вменяемой
> диагностики и обработки ошибок и тупо завершать программу. Да и рекомендация
> свалить проблемы плюсовиков на них самих, мягко говоря, не идеальна.+2
> Если разработчик не потрудился проверить работу на нескольких платформах, то он может завязать свою разработку на специфических функциях, работающих лишь на одной платформе.Проблема в том, что разработчик не всегда имеет одинаковый скилл на всех платформах. И портирование может занять продолжительное время, которое разработчик может потратить на добавление новых возможностей, исправление ошибок. А вот если кому то _реально_ нужен будет этот софт, он его допилит для своей платформы. Я так понял, то имелось в виду.
>Если разработчик не потрудился проверить работу на нескольких платформах
>Зачем усложнять другим жизнь, когда можно сразу сделать всё по-нормальному?какие сложности - бери да пиши всё с нуля
Как минимум надо переходить от Си на С++, кодом гораздо проще управлять.А вообще давно пора искать альтернативы лексическому программированию - это получается не математика, а литературный жанр. Писано миллионы и миллиарды строк кода, которые приходится всё время переписывать и дописывать - изъян в самой системе кодирования. Надо смотреть в сторону UML и FSM. Один раз решённые задачи не придется никогда пересматривать и решение будет математически точным и конечным, исключающим бесконечное "улучшение кода", "рефакторинг" либо использование кода непредусмотренным образом вирусами.
Прошло полвека с рождения фортрана и Си, нужен качественный скачок. Индустрия в застое, бурно растущие базы кода непомерно дороги и недолговечны в использовании, содержат массу ошибок и дыр. Надо менять систему. Тогда не надо будет долго ломать голову над названием очередной главы писательского труда - MyLibForCoolHacker() или mylib_fch() :), можно будет просто написать ряд "математических формул", строго задающих поведение системы.
http://www2.research.att.com/~fsmtools/fsm/
Очень здравая и ясная идея! То, что перечислено в списке, - в общем то очевидно, но наконец это все сказано в одном ключе и в слух.
Очевидное зло :-) Есть библиотеки хорошие, и есть не хорошие, а есть и корпоративные. Примут ли это к сведению корпорации, работающие на Си? Для меня большой вопрос.
если им это покажется здравым и полезным - то "ВайНо?"
>mylib_free()Так нужно:
MyContextFree(MyContext *con)
Там же ясно написано, что в Plain C не принято использовать CamelCase.
> Там же ясно написано, что в Plain C не принято использовать CamelCase.Простите - кем написано? Расти Раселом? Пардон, но при всем уважении к его творениям он явно далек от позиции чтобы диктовать, что в языке C принято а что - нет. Это у него - не принято. И бога ради. Это его личная позиция. Но - не более того.
Это не его личная позиция, это общепринятая практика. Посмотрите на стандартные библиотеки ANSI C, посмотрите на POSIX API, не используется там CamelCase. Есть два типа имён - макросы пишутся полностью ЗАГЛАВНЫМИ_БУКВАМИ, и всё остальное, пишется строчными_буквами. Названия типов данных дополняются суффиксом _t. Использование CamelCase в Plain C может быть скорее вашей личной позицией, но не более того.
> Это не его личная позиция, это общепринятая практика. Посмотрите на стандартные библиотеки ANSI C, посмотрите на POSIX API, не используется там CamelCase. Есть два типа имён - макросы пишутся полностью ЗАГЛАВНЫМИ_БУКВАМИ, и всё остальное, пишется строчными_буквами. Названия типов данных дополняются суффиксом _t. Использование CamelCase в Plain C может быть скорее вашей личной позицией, но не более того.При всем уважении к стандартам ANSI C и POSIX, описываемое ими API и принятая в нем стилистика - это лишь мизерная часть от того, что было так или иначе разработано с использованием языка C в глобальном масштабе. Предвидя аргумент a'la 'А вот в ядре Linux/BSD/etc..' - да, и ядро Linux/BSD/etc это так же очень небольшая часть от.
Есть огромное количество самых разнообразных проектов, которые используют язык C. И открытых и закрытых и ещё бог знает каких. И вот так вот с легкой руки ровнять всех под одну гребенку и заявлять что мол 'в языке C что-то принято или не принято' - это мягко говоря несколько самоуверенно. Слишком самоуверенно. На грани фолта.
>> При всем уважении к стандартам ANSI C и POSIX, описываемое ими API
> и принятая в нем стилистика - это лишь мизерная часть от
> того, что было так или иначе разработано с использованием языка C
> в глобальном масштабе. Предвидя аргумент a'la 'А вот в ядре Linux/BSD/etc..'
> - да, и ядро Linux/BSD/etc это так же очень небольшая часть
> от.Такой стиль был принят:
- создателеми языка (Д. Ричи),
- всей группой разработчиков Unix (К. Томпсон, Б. Керниган и т.д.), для разработки которой и был изначально придуман Си,
- в стандарте ANSI C,
- в стандартах POSIX API.Если этого авторитета вам не достаточно, то разговаривать с вами дальше не имеет смысла.
> Есть огромное количество самых разнообразных проектов, которые используют язык C. И открытых
> и закрытых и ещё бог знает каких. И вот так вот
> с легкой руки ровнять всех под одну гребенку и заявлять что
> мол 'в языке C что-то принято или не принято' - это
> мягко говоря несколько самоуверенно. Слишком самоуверенно. На грани фолта.Вы точно не путаете Plain C и C++?
И вообще, что-то вы не похожи на klalafuda, он был более сдержан в высказываниях и всегда подписывался. И "На грани фолта." он бы не сказал, он грамотный.
> Такой стиль был принят:
> -создателеми языка (Д. Ричи),
> -всей группой разработчиков 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, он был более сдержан в высказываниях и всегда подписывался. И "На грани фолта." он бы не сказал, он грамотный.
Все течет, все меняется.
> Но факт остается фактом: проектов на C существует
> огромное количество равно как и подходов к их стилистическому оформлению. И
> нельзя однозначно утверждать, что мол 'в C принято так то и
> так то и никак иначе'.Вообще-то, именно так и принято. Хотя я конечно не говорю, что всё остальное запрещено. Крупные самостоятельные проекты могут пользоваться своим стилем.
>> И вообще, что-то вы не похожи на klalafuda, он был более сдержан в высказываниях и всегда подписывался. И "На грани фолта." он бы не сказал, он грамотный.
> Все течет, все меняется.Культурного, образованного и разумного человека сложно так быстро испортить.
>Вспомнить хотя бы WinAPIВот уж что точно не надо вспоминать! Все эти ужасные BOOL и BYTE, всяческие hViewInstance, какие-то велосипеды и костыли на каждом шагу. Буэээ...
Ещё ни разу не слышал чтобы стиль WInAPI хоть кому-то нравился.
Ну, их в основном за длину названий и венгерскую нотацию ругают. Кстати, венгерская нотация в сях, с их слабой типизированностью, иногда даже смысл имеет. Хотя очень редко :-)
Вы будете удивлены, но в плюсах точно так же принято функции стандартной библиотеки и буста писать через подчёркивания. Это даёт возможность чётко видеть, что стандартно, а что - пользовательские функции, написанные в camelCase. И это удобно.
Расти в комментариях поправляется:> 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?
Странно, что описанные выше "проблемы" еще существуют в этом веке. на java многое из этого уже решено. А оставшееся - учить разработчиков как писать адекватный код.сложилось впечатление что CCAN это аналог подсистемы maven отвечающей за сбор проекта.
PS совпадение src и test считаем просто совпадением ;)
> Странно, что описанные выше "проблемы" еще существуют в этом веке. на java
> многое из этого уже решено. А оставшееся - учить разработчиков как
> писать адекватный код.Когда появился java, а когда си.
Для чего существует Java, а для чего си :)
> на java многое из этого уже решено.Только на java нельзя написать многое из того что на сях пишется только в путь.
Да хоть бы и так. Чего ж не взять идею, если она хороша. Главное глупости не тянуть, вроде здоровенных нечитабельных XML-конфигов, сборщиков мусора и связывания рук разработчиков ;-) Но могу порадовать - CCAN эти названия каталогов содрал у перла :-) Как и название.
"аналога архива CPAN для языка Си"кажется, опечатка...
Что-то как-то IMHO многовато шума для столь мелкого проекта. По крайней мере если судить по содержимому их 'репозитория'. Вот выйдет народ на какой-то более-менее вменяемый объем - ОК. Будет повод сравнивать их с тем же CPAN-ом. Пока же это даже на страничку Васи Пупкина не тянет.
> Что-то как-то IMHO многовато шума для столь мелкого проекта. По крайней мере
> если судить по содержимому их 'репозитория'. Вот выйдет народ на какой-то
> более-менее вменяемый объем - ОК. Будет повод сравнивать их с тем
> же CPAN-ом. Пока же это даже на страничку Васи Пупкина не
> тянет.Всегда приходится с чего-то начинать. Linux начинался с эмулятора терминала, работающего в многозадачном режиме на i386. Я лично эту инициативу приветствую.
>"наш код не должен быть уродливым"
>Plain CСлегка поделили на 0.
>>"наш код не должен быть уродливым"
>>Plain C
> Слегка поделили на 0.На Си можно писать изящно. А можно не изящно. А можно не писать. Их цель достижима, а уж то, насколько их это ограничивает, если ограничивает, это их проблемы, а не тех, кто не видел изящного кода на Си.
P.S.: Если какая-то задача решается одной-двумя строчками на Си против десятка на ЯВУ, то это потому что Си неизящный, да?..
По сравнению с бытовавшими в то время языками -- да, Си изящный.И сейчас в определённых областях он едва ли не лучшее решение. Просто появились новые области, и приоритеты изменились.
> появились новые области,Да, выписывать веб-приложение типа Ынтерпрайзной CRM на голых сях можно и подзадолбаться. Впрочем удобный для такого [быдло]кодинга пых половина местных почему-то обсирает :).
>>"наш код не должен быть уродливым"
>>Plain C
> Слегка поделили на 0.Только совсем слегка. На сях порой попадается отличный код. Простой в понимании, читабельный, где грабельки успешно и изящно обрулены и прочая.
>Не стоит загромождать заголовочные файлы конструкциями C++ - если вдруг ваша библиотека понадобится разработчику на C++, будет не сложно такую конструкцию добавить непосредственно в код разрабатываемой пользовательской программы, непосредственно перед #include вашего заголовочного файла.Это он про extern "C"
мне кажется, это он про C++ обёртки blabla->make_zashibis(); для blabla_make_zashibis(blabla);
> мне кажется, это он про C++ обёртки blabla->make_zashibis(); для blabla_make_zashibis(blabla);А вот такие "обёртки" делаются только с горя. Как правило гораздо больше толку, если автор позаботился предоставить плюсовый API, работающий непосредственно с внутренностями библиотеки. Можете как пример на libev глянуть.
>>Не стоит загромождать заголовочные файлы конструкциями C++ - если вдруг ваша библиотека понадобится разработчику на C++, будет не сложно такую конструкцию добавить непосредственно в код разрабатываемой пользовательской программы, непосредственно перед #include вашего заголовочного файла.
> Это он про extern "C"Ну тогда логично. Я уж подумал, что он наезжает на те библиотеки, которые предоставляют ещё и плюсовый интерфейс.
Пункт 1 легко исправляется выбором правильного инструмента для сборки проекта.http://sourceforge.net/projects/mk-configure/
Один (под)проект -- один Makefile.
Одна команда для сборки проекта -- mkcmake.
Все.
> Пункт 1 легко исправляется выбором правильного инструмента для сборки проекта.
> http://sourceforge.net/projects/mk-configure/
> Один (под)проект -- один Makefile.
> Одна команда для сборки проекта -- mkcmake.
> Все.Ээ, он уже больше не на bmake? или стал таскать с собой?