| 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 [^] [^^] [^^^] [ответить]
| +/– |
Та часть, которая предсказуемо работает на всех платформах, уж очень ограниченна. Учитывая, что даже на размер переменной не заложишься - а для разных размеров нужны разные модификаторы.
| | |
|
|
|
|
| 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 [^] [^^] [^^^] [ответить]
| +/– |
Очевидное зло :-) Есть библиотеки хорошие, и есть не хорошие, а есть и корпоративные. Примут ли это к сведению корпорации, работающие на Си? Для меня большой вопрос.
| | |
|
| |
| 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... текст свёрнут, показать | | |
|
|
|
| 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, а когда си.
| | |
| 2.42, User294 (ok), 20:54, 18/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > на java многое из этого уже решено.
Только на java нельзя написать многое из того что на сях пишется только в путь.
| | |
| 2.51, Crazy Alex (??), 00:31, 19/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Да хоть бы и так. Чего ж не взять идею, если она хороша. Главное глупости не тянуть, вроде здоровенных нечитабельных XML-конфигов, сборщиков мусора и связывания рук разработчиков ;-) Но могу порадовать - CCAN эти названия каталогов содрал у перла :-) Как и название.
| | |
|
| 1.22, klalafuda (?), 07:56, 18/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Что-то как-то IMHO многовато шума для столь мелкого проекта. По крайней мере если судить по содержимому их 'репозитория'. Вот выйдет народ на какой-то более-менее вменяемый объем - ОК. Будет повод сравнивать их с тем же CPAN-ом. Пока же это даже на страничку Васи Пупкина не тянет.
| | |
| |
| 2.25, www2 (??), 08:13, 18/10/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Что-то как-то IMHO многовато шума для столь мелкого проекта. По крайней мере
> если судить по содержимому их 'репозитория'. Вот выйдет народ на какой-то
> более-менее вменяемый объем - ОК. Будет повод сравнивать их с тем
> же CPAN-ом. Пока же это даже на страничку Васи Пупкина не
> тянет.
Всегда приходится с чего-то начинать. Linux начинался с эмулятора терминала, работающего в многозадачном режиме на i386. Я лично эту инициативу приветствую.
| | |
|
| |
| 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"
Ну тогда логично. Я уж подумал, что он наезжает на те библиотеки, которые предоставляют ещё и плюсовый интерфейс.
| | |
|
|
