Re: libpthreads,libmpeg3 -> windows
- From
- Valentin Nechayev ()
- To
- Boris Rudakov ()
- Date
- 2003-06-11T10:38:58Z
- Area
- CARBON.COPY
* Forwarded from area 'RU.UNIX.PROG'
From: Valentin Nechayev <netch@segfault.kiev.ua>
Ответ на 4 письма скопом.
>>> Boris Rudakov wrote:
IS>> Видишь ли, в чём дело. 99% линуксовых программ доступны в исходниках.
IS>> И, наверное, у 95% виндовых программ исходники недоступны. Сколько они
IS>> выдают предупреждений при сборке - ты не знаешь и судить о их кривости
IS>> можно только по их глюкавости. Сравни количество линуксоидного и
IS>> чужого виндового кода, который тебе пришлось собирать.
BR> Думаю что соотношение будет более чем 10:1 в пользу коммерческого (или
BR> демонстрационного) Виндозного кода. В одной из предыдущих мессаг я перечислял
BR> до сотни мегабайт подвиндозного кода. Только то, что опубликовано Борландом и
BR> Мелкософтом потянет на 50 метров МИНИМУМ. Да, они - гранды, им сам Бог велел
BR> писать хорошо (хотя-бы стараться, хотя-бы вид делать). Но и другого
BR> подвиндозного кода наберется еще на полсотни метров.
Признак корректности кода в виде отсутствия warning'ов - это, конечно,
неплохо, но не может служить абсолютным признаком. Я не могу забыть
пример из MS SDK на findfirst+findnext - где они повторили кусок кода
просто потому, что не хотели перестроить код так, чтобы он не дублировался.
Не знаю, что здесь хуже. Вероятно, для Unix мира такое дублирование кода
будет хуже, чем, например, warning по тому, что какая-то функция в каком-то
режиме компиляции не используется - потому что при дублированном коде
patch гарантированно ошибётся в месте правки ;))
BR> Так что соотношение компиленных мной вин32/линукс сырцов соотносится не менее
BR> чем 10:1 в пользу вин32. И если в вин32 пакетах косяки компилляции - не просто
BR> исключение из правил, а нечто из ряда вон выходящее, то в линуксе увы К
BR> СОЖАЛЕНИЮ все наоборот - если пакет собирается сразуже с пол-пинка и не
BR> заваливает тебя парой сотен варнингов - это приятная неожиданность :(
Основной источник трудности здесь - многоплатформенность. Ну и некоммерческость
большинства разработок. Легко сделать нечто, что под одной платформой собирается
без warning'ов. А если этих платформ надо учитывать 20?
BR> Я бы на месте приверженцев unix-community (сам-то я виндузник:) начал бы в
BR> своих рядах кампанию по внедрению правил "хорошего тона". Почему бы вам, чей
BR> профессиональный уровень весьма высок, не начать внедрять в качестве правила
BR> мысль, что варнинги в опубликованных пакетах, нихера не работающие мэйк-файлы и
BR> взбрыки всех этих autoconf, по забывчивости не включенные в "дистрибутив"
BR> модули - это такой же дурной тон, как, прошу пардону, пернуть в общественном
BR> месте ? :):):):):):)
А и так известно, что это дурной тон. Вопрос в том, что нет ресурсов на то,
чтобы всё переделывать и править. В своих разработках я держу уровень.
Должен ли я править, например, код bash? Или это должны делать его авторы?
А что они с этого будут иметь?
Поднять общественное мнение, конечно, можно. Постепенно. По капле.
Быстро это никак не будет.
BR> Ведь число профессионалов, чья основная платформа - юникс, ну никак не меньше
BR> числа профессионалов-виндузников ! Линуксоидная кривизна - это ведь не
BR> следствие платформы/архитектуры !
Это следствие того, что ставилась задача сделать хоть на тяп-ляп, но чтобы
было и в общем работало. А сейчас столько ужасов в результате, что исправлять
будут ещё лет 20.
Кстати, вспомнил фишку. В начале файла принято писать что-то вида
static const char rcsid[] = "$Id$";
которое не используется нигде, но должно попасть в выходной файл.
Естественно, оно вызывает warning, если не обходить это специально.
BR> Почему бы не включить правила хорошего оформления программ в общий свод правил
BR> "как надо" ? :) Тем более что мне кажется что юниксоиды-то как-раз более
BR> склонны к выработке и соблюдению разнообразных соглашений и правил, нежели мы у
BR> нас...
BR> Мне кажется что эта проблема не просто уже давно назрела, а она уже стала очень
BR> серьезной...
Да, проблема созрела. Но переход к массовой профессиональной разработке
open source софта ещё не наступил. И ещё K лет не наступит.
>>> Boris Rudakov wrote:
BR> 5. Netscape (ДО того как проектом занялись в багзилле хрЕновой) - блестяще
BR> организованный и написанный, красивый код. Ни единого варнинга.
bugzilla - это другое ;)
AP>> Видел я примеры коммерческого кода -- внутренние вещи american
AP>> airlines. Блин. Такое ощущение, что программировать не умеет никто. В
AP>> качестве примера, выделялся буфер, заданный дефайном как 1мб. Но в
AP>> вызове маллок добавляли ещё 100к, "поскольку программа почему-то
AP>> падает".
BR> Ну уроды они, и ?
BR> Давай одну вещь заметим: контора НЕ СОФТВЕРНАЯ. Там сидят волосатые недоучки
BR> (судя по тому что ты говоришь) и чего-то как-то корябают. Это - НЕ
BR> профессиональное программирование. Это - кустарный непрофильный отдел
BR> корпорации, которая почему-то не хочет платить за заказной софт
BR> профессиональным разработчикам. Ну как у нас в начале-середине девяностых в
BR> практичсеки каждой шарашке был отдел безумных фоксописателей. Это - НЕ
BR> профессиональные разработчики. Это - ремесленники.
BR> Чего на них ориентироваться ?
Ну тогда переопределись: не просто "коммерческий код", но "коммерческий
код на продажу". Или вообще "коммерческий код для зарабатывания денег продажей
продуктов на нём".
Кстати, это сразу исключит большинство opensource поделок из рассмотрения
и разрешит любые количества warning'ов в них: оно ведь не на продажу ;)))
BR> В Борланде я пишу #pragma argsused, а в Инвижуале -
BR> #pragma warning(disable:4355)
BR> #pragma warning(disable:4068) // unknown pragma
BR> и прочее по мере необходимости.
gcc не умеет такого, AFAIR.
>>> Boris Rudakov wrote:
BR> По поводу терминалов, в качестве реализации которых в оригинальной
BR> мелкософтовской POSIX Subsystem ты сомневался:
Это не IS был, а я ;))
>>> Boris Rudakov wrote:
AP>> if( i < MIN_VALUE || i > MAX_VALUE )
AP>> error();
AP>> не задумываясь о том, равно MIN_VALUE 0 или не равно.
BR> Ээээээ, но ведь для этого есть временное включение/выключение варнинга !
В gcc нету.
Кстати, то, что оно есть в BC и VC, не означает ли подпорку для кривописателей?
;)))
Ведь можно любую ересь таким образом одобрить. А разбираться в мегах кода,
где тут правильный disable, а где нет, вряд ли кто-то будет.
Зато, видите ли, результат - warning'ов нет...
BR> Да, это загромождает код. НО, это напрягает голову в сторону поиска изящных
BR> ходов, которые бы и код не загромождали, и варнинги бы не плодили.
Или в сторону выключения warning'ов, опять же.
BR> Кста, вообще говоря, хорошим тоном является ведение ДЛЯ ВСЕГО прокета одного
BR> Главного Инклуда (для каждого проекта, включая проекты либ, должен быть свой
BR> Главный Инклуд). Борланд с Мелкософтом к этому еще и хорошо подталкивают
BR> ведением precompiled headers, которые для каждого модуля
В unix мире с закосом на реальную переносимость, а не просто в соответствии
с Posix - не получится.
Например, на ряде старых платформ <time.h> и <sys/time.h> нельзя одновременно
включать. А они могут потребоваться оба.
Да, можно вынести такие непереносимые части в отдельные мелкие модули.
Кузяво ли?
BR> Так вот, очень удачно что Борланд с Мелкософтом (и эмулирующим последнего
BR> Интелом) вбивают очень хорошее правило: не писать в модулях проекта
BR> индивидуальной помойки из инклудов.
Чему причина - время компиляции включения виндовых хедеров.
Идеологическую подоплёку у них это вряд ли несёт.
BR> Заметь: генеральные инклуды имеют РЯД важнейших преимуществ перед
BR> неупорядоченным включением чего попало и как попало в каждый модуль в
BR> индивидуальном порядке.
BR> * Строгий контроль чего ты юзаешь
Делается простым скриптом. Вот когда нет возможности сделать простой скрипт
ради этого - вот тогда начинается стремление централизовать точку контроля.
BR> * Более легкий порт между платформами (в генеральном инклуде пишутся секции,
BR> отвечающие за каждую платформу, вводятся project-wide дефайны и ты пы)
И зачем для этого требовать единственный include?
BR> * Генеральный контроль за видами билдов: варианты дебагов, релизов, глобальная
BR> подмена функций project-wide дефайнами и ты-пы.
Аналогично.
BR> Мне было приятно что на это обратили особое внимание, но осталось и сожаление
BR> что такое программирование не является нормой и люди ему приятно удивляются.
BR> Уверен что нужно вносить аккуратность программирования в фундаментальные
BR> постулаты "религии", а для коммерческого кода качество должно быть просто
BR> неукоснительным свойством.
Пожуём - увидим, как быстро придёт к этому.
У нас тут компилятор только-только стабилизировался...
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)