Проблемы с разработкой GCC

Вот вам и хваленное качество Open Source кода.

в случае close ты не знаешь за что ты платишь. Тебе от этого спокойнее?

Лично я, работая в сфере software development, лучше буду использовать open, чем closed :)

gcc с его оптимизатором всегда был не подарок, но кто нибудь видел как работает Borland C++ 3.0 или M$ C Compiler v.6 под DOS?

Поэтому всё относительно в этом мире ;-)

Gcc тоже когда-нибудь качеством должен подтянуться, только вот если бы они постоянно не переписывали оптимизаторы и парсеры бы с нуля, поганцы.

> Некоторые разработчики предлагают пропустить релиз 4.2 и обозвать его 4.3

Переводчег, переведи еще раз след. предложение:

Some have suggested that I try to solve this by closing GCC 4.3 development until 4.2.0 is done.

Должно быть так:

Некоторые (разработчики) предлагают, чтобы я решил эту проблему, закрытием разработки GCC4.3, до тех пор пока 4.2 не придёт в норму.

--седайко стюмчик

> Some have suggested that I try to solve this by closing GCC 4.3 development until 4.2.0 is done.

Читайте дальше!

> в случае close ты не знаешь за что ты платишь. Тебе от этого спокойнее?

> Лично я, работая в сфере software development, лучше буду использовать open, чем closed :)

Лично я, работая в сфере software development-а считаю что вы работаете в какой-то неправильной под-области ;) Просто сравнивая свои затраты на притирку различных мелочей, которые сам бы никогда не заметил, но на которые пал глаз сотрудников QA, с затратами аналогичными у Open Source разработок, понимаю, что они счастливые люди, им не нужно вымарывать мелочи разные %20 процентов времени, они на них просто забивают.

> Лично я, работая в сфере software development-а считаю что вы работаете в какой-то неправильной под-области ;) Просто сравнивая свои затраты на притирку различных мелочей, которые сам бы никогда не заметил, но на которые пал глаз сотрудников QA, с затратами аналогичными у Open Source разработок, понимаю, что они счастливые люди, им не нужно вымарывать мелочи разные %20 процентов времени, они на них просто забивают.

Да и по поводу общего качества - в Close Source, пусть и не всегда, обычно есть отвественное лицо, задом отвечающее за качество кода.

>Лично я, работая в сфере software development-а считаю что вы работаете в какой-то неправильной под-области ;)

Вы кажется немного его не допоняли, он имел ввиду что с открытой библиотекой гораздо спокойнее на дуще, т.к. можно всегда багу исправить, чем с закрытой. Хотя может я недопонял? :)

s/дуще/душе :)

>Высказываются также мысли о методах вознаграждения или наказания за игнорирование найденных ошибок или за появление оных,

Наказание будет осуществляться наложением проклятия Святого Игнусиуся Столлмана?

именно это я и имел ввиду.

Вышел в своё время 11-й Watcom C++. И поднялась агромаднейшая волна вопросов: а почему не работает то, почему не работает это. Со стереотипным ответом: поставь вот этот кусок от десятки. Пока не вышел через некоторое время весьма нехилый по размерам патч 11.5.

Таки да, второго примера я, пожалуй, не приведу. И тем не менее, с тех пор мифы о некоей присущей коммерческому ПО гарантии качества вызывают у меня сардоническую усмешку...

Цена сыра, к сожалению, не гарантирует от мышеловки...

Смоляное Чучелко

Уф. Плохо конечно, но лучше ведь чем ничего :) Спасибо всем кто разрабатывал, разрабатывает GCC!

(Вот когда-нибудь я стану профи и обязательно помогу им хотя бы в чем-нибудь...)

>(Вот когда-нибудь я стану профи и обязательно помогу им хотя бы в >чем-нибудь...) >php-coder **** (*) (17.04.2007 18:28:14)

Перепишешь на php?

Ага и будет аля Микрософт!!! По слухам, там тоже если в коде программера находят несколько ошибок, то программер отправляется на "курсы кройки и шитья"!

Нам всем надо просто отдохнуть, перевести дух...

>По слухам, там тоже если в коде программера находят несколько ошибок, >то программер отправляется на "курсы кройки и шитья"!

Сразу на Магадан уезжает через Аляску,чего уж мелочиться-то

anonymous> Вот вам и хваленное качество Open Source кода.

В случае Closed Source такой проект в подобной ситуации просто загнётся окончательно и бесповоротно. А так хоть другие могут указать на ошибки и исправить их.

А GCC как был лучшим так и останется в ближайшее время таковым.

>В случае Closed Source такой проект в подобной ситуации просто загнётся >окончательно и бесповоротно.

+1

Мир твоему праху MIPSPro..

>Да и по поводу общего качества - в Close Source, пусть и не всегда, обычно есть отвественное лицо, задом отвечающее за качество кода.

Если бы ....

Много приходится работать с поддержкой Close Source продуктов

Обычная реакция на баги репорты, как из того анекдота - "а если нагнутся - болит, нет? вот так и ходи, бабушка"

>Да и по поводу общего качества - в Close Source, пусть и не всегда, обычно есть отвественное лицо, задом отвечающее за качество кода.

А что - метод пинания задниц стал хорошим катализатором качества? Что-то новое.

Следил я полтора года где-то за gcc mail list, компилировал свою поделку раз в неделю свежескаченым gcc из основной ветки. Все ожидал супер чуда от новых фишек, bb-reordering, оптимизацию между функциями, автовекторизатора и прочих как мне казалось необходимых вещах. Фигня все это. Главное чтобы код правильный генерился. Все равно почти все современные процессоры его под себя переделывают, толку от оптимизации мало.

В принципе ничего нового в новости нет, так было всегда и Mitchell частенько сетовал что все рвутся добавлять супермодные фишки, а копаться в чужом древнем коде и исправлять что то не так прикольно. GCC изначально был написанне совсем хорошим образом, то есть не было общего процессорнонезависимого дерева на котором бы проходила оптимизация ( версии после 4.XX ), все проходы были на RTL, так что это каторжный труд все переносить на новый лад, переделывать. Распределение регистров до сих пор все ругают, но тут другая история - задача оказалась очень сложной.

Насколько я понял поводом для таких громких заявлений было то что RadHat прокатила 4.2, очевидно он должен был быть в FC7. Команда GCC разом лишилась огромной кучи тестеров, а тут еще известный и неприятный баг с alisaing-ом который невозможно пофиксить в 4.1 так как требуется слишком много изменений. Вот и хотел он переименовать и выпустить 4.3 как 4.2 и вообще забыть про 4.2. Народ возмутился и так далее.

Нормальная рабочая ситуация. Наверняка Google Summer проектов куча, к осени будет вам gcc как конфетка.

Нет-нет, в Майкрософт отвечают за качество кода! Если ворд 97 намертво валился от слов "Таким образом, переданная информация..." и т.д., то ворд 2003 валится от "Правоспособность - это способность лица..." и т.д. Изменения в коде - налицо!

>А GCC как был лучшим так и останется в ближайшее время таковым.

Intel C++ Compiler 9 - намного лучше, но и намного дороже :(

>Intel C++ Compiler 9 - намного лучше, но и намного дороже :(

И я даже дагадаюсь щас под какое железо :)

> Intel C++ Compiler 9 - намного лучше, но и намного дороже :(

$400 однако. Для любой конторы -- мелочь, а для личного использования вполне можно обойтись и gcc.

Intel C++ Compiler 9 не портирован под столько платформ, как GCC. А для некоторых коммерческих систем GCC является единственным штатным средством разработки. Например Mac OS X 10.4.

> Да и по поводу общего качества - в Close Source, пусть и не всегда, обычно есть отвественное лицо, задом отвечающее за качество кода.

Наверное имеется в виду главпредседатель конторы, что включает кодерскую артель, и ж*па его толстая и мягкая, а волос - пышный и шелковистый, ага?

>Например Mac OS X 10.4.

Нифига себе басню сократили! Читай про Xcode:

http://www.apple.com/macosx/features/xcode/

>Intel C++ Compiler 9 - намного лучше, но и намного дороже :(

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

>At the heart of Xcode 2.0 is Apple’s version of gcc 4.0, the next generation of the industry-standard gcc compiler.

Тот же gcc 4.0... у меня опыта общения с данным продуктом всего-то 1 день, но за этот день я не нашел сколько нибудь важных отличий (в консоли галемый gcc, я окошки не грузил, не знал как...), вот только _main не нашел в SDL проекте... да frameworkи какие-то требует с cocoa... жуть

А чего там такого на 700 мегов-то напихали?

> Intel C++ Compiler 9 - намного лучше, но и намного дороже :( Я бы так не сказал. Восьмой Intel садился на инфраструктуру конкретного gcc (со всеми проблемами, которые из этого проистекали). Сломался на плюсовом коде у меня раза три, а когда уговорил его --- сотворил неправильный код. Мне это не очень понравилось --- гадать будут ли у меня проблемы за 2% выигрыша в скорости, если очень повезёт.

Xcode - это всего-лишь ГУЙная морда для компилятора ... Сам же компилятор - GCC .

Да, де-факто что-то там совсем народ обленился. Мой bugreport+trivialfix уже больше месяца "спит" в багзилле.

Ну как там в микрософтах я не знаю. Но во вменяемых конторах девелоперу при сдаче кода необходимо провести инспекцию кода. На которой гнобят даже за использование табуляции в неположеном месте, по умолчанию действует установка "не бывает кода без ошибок"

.zuk

> >По слухам, там тоже если в коде программера находят несколько ошибок, >то программер отправляется на "курсы кройки и шитья"!

> Сразу на Магадан уезжает через Аляску,чего уж мелочиться-то

В самый северный штат Индии? :-)

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

Так-то оно так, но есть иные проблемы, например зажатые сроки. Коммерческая контора в первую очередь думает о прибыли. И если есть вариант сделать хорошо, или сделать кое-как и срубить бабла, то выбирается второе. И пофиг как оно работает.

Сам программирую за деньги, потому предпочитаю использовать OpenSource, и другим советую.

АК

Интел С хорош конечно. Но если не будет gcc, ядро чем компилировать будем ? И glibc ?

К тому же не забываем что gcc - Gnu Copmiler Collection а не Gnu C Compiler.

Проблемы разумеется существуют. Но тем не менее такие вещи как СММ очень сильно помогают качеству продукта. И сделать "кое как" совсем не так просто. Что разумеется не избавляет от проблем вообще. В любом случае в нормальном цикле разработки тестирование куда как серьезнее чем на опенсорц проектах.

.zuk