1.2, hatelinux (?), 20:17, 29/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
а что толку? все одно нужно gcc ставить что бы дополнительный софт собрать где большая часть на c++ написана
| |
|
2.3, Аноним (-), 21:26, 29/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Ну здрасьте"
apache, sendmail, postfix, exim, postgresql, mysql и т.д. все на ANSI C написаны, очень редко когда что-то на С++
| |
|
1.4, Аноним (-), 22:06, 29/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Еще бы его собрать под Win32! Да и еще бы кросс-компиляцию освоить!
А потом если он и правду не так сильно велик, то появиться AVR-PCC,
PIC-PCC и т.п. А потом уже глядишь и на каком-нить наладоннике ядро
можно будет писать программки...
| |
|
2.5, Ariel (??), 22:11, 29/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
может лучше юзать его в качестве front-end llvm? он уже доведён до ума
| |
|
3.22, User294 (ok), 11:01, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
И что, генерит код под AVRовское ядро? И даже не сильно похабный? Пруфлинк?
| |
|
2.20, User294 (ok), 10:59, 30/12/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Еще бы его собрать под Win32! Да и еще бы кросс-компиляцию освоить!
По-моему, в список еще губозакатывательную машинку надо включить.
> А потом если он и правду не так сильно велик, то появиться AVR-PCC,
Долго ждать придется. Посмотрите через сколько лет существования gcc появился avr-gcc. В итоге пока оно станет юзабельно (если вообще станет) т.е. будет генерить более-менее непохабный код без кучи глюков - наверное пора будет на пенсию собираться, а AVRки останутся только в музее политехники как ископаемые.
И чем плох avr-gcc? Тем что под GPL? А, гм, мне это никаким боком не мешает, его лицензия позволяет собирать им все что угодно, вплоть до защищенной от копирования фирмвари. И он уже есть. Ну и логично что народ его и допиливает. Да и еще под кучу архитектур есть. А прогресс не стоит на месте - появляются новые процессорные ядра и архитектуры, etc. И хорошо бы чтобы современное ядро поддерживалось сейчас. А не через 10 лет, когда оно уже никому не надо. GCC уже стал стандартным тулкитом который уже считается хорошим тоном предоставить к своим процессорам/uC в комплект. Ну и чудненько, нафиг нужно изучать зоопарки компилеров.Проще изучить GCC и юзать его везде.Благо програмера он никак не ограничивает.
| |
|
1.8, Voviandr (??), 22:25, 29/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
зачем нужен РСС ? чтоб с его помощью собрать из исходников новейшую версию GCC и юзать уже её.
| |
|
2.9, анонимус (??), 23:05, 29/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Учитывая, что не так давно в gcc такого наворотили, что Линус долго плевался, а разработчики компилятора исправлять отказались, PCC нужен.
| |
|
3.10, Seytar (?), 23:42, 29/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
имхо давно просился компилер на замену gcc. В крайнем релизе огромные косяки с многопоточностью.
| |
|
4.13, ixrws (??), 23:49, 29/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>имхо давно просился компилер на замену gcc. В крайнем релизе огромные косяки
>с многопоточностью.
Возможно и нужен, ещё конечно вопрос нужен ли, потому что всегда можно взять и исправить косяки, любые. Но даже если представить что нужен, то надо чтобы набор компиляторов поддерживал такое же количество архитектур, языков и имел более высокое качество. Пока таких нет, и даже не намечается.
Единственный претендент - это clang с llvm, но до поддержки языков уровня gcc ему очень далеко. А сабжу и вообще как до луны.
| |
4.29, anonymous (??), 15:56, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>... В крайнем релизе огромные косяки с многопоточностью.
Ммм, поясните, плз, что вы имеете в виду?
| |
|
3.11, аноним (?), 23:44, 29/12/2009 [^] [^^] [^^^] [ответить]
| +3 +/– |
Ой ой выравнивание стека сделали как всем нужно, а не только писателям ядра. Страшное чудовищное преступление.
| |
3.12, ixrws (??), 23:45, 29/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Давайте конкретнее уже. Если говорить серьзно, то слушать можно не Линуса, а сообщество debian. Вот когда в нём станут использовать что-то другое. Или когда это будут делать в gentoo, тогда можно рассматривать подобные сабжи по ближе.
Полудохлые проекты с со слабыми результатами никому и никогда не были нужны. Хорошие замены или альтернативы - нужны, но не полудохлые, лишь оттягивающие на себя незаслуженное внимание.
| |
|
4.16, Я (??), 00:50, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
> Давайте конкретнее уже. Если говорить серьзно, то слушать можно не Линуса, а сообщество
> debian. Вот когда в нём станут использовать что-то другое. Или когда это будут делать в
> gentoo, тогда можно рассматривать подобные сабжи по ближе.
> Полудохлые проекты с со слабыми результатами никому и никогда не были нужны. Хорошие
> замены или альтернативы - нужны, но не полудохлые, лишь оттягивающие на себя
> незаслуженное внимание.
Нужен нормальный (людский) компилятор с минимально программируемыми стадиями, чтобы sparse-подобные (или просто свой простейший ворнинг добавить) вещи надо быль не с нуля писать. В этом смысле gcc ужасен.
| |
|
5.30, Aleksey (??), 19:51, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
ТОчно. И компиляция в 2-3 раза медленнее gcc. Или вам и скорость и гибкость и губозакатывательную машину одновременно?
| |
|
4.17, northbear (??), 04:11, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Когда Debian перейдет на использование другого это уже все, продукт практически умер.
Использование PCC в Gentoo это будет весьма серьезный аргумент в пользу оного. Но боюсь, что зависимость gentoo от gcc такова, что он умрет вместе с gcc.
Компиляция с помощью pcc это тема отдельного форка. Будет какой-нибудь Pentoo.
| |
|
5.28, ixrws (??), 14:26, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Зависимость Gentoo от gcc? Это шутка или как? Б'ольшинство системных пакетов дженту не компилируются gcc, потому что написаны сами знаете на чём. А если вы про компиляцию софта, так это в той же степени касается и debian, и freebsd и всех прочих свободных юниксподобных систем, на которых софт собирается с помощью gcc.
Включение альтернативного компилятора возможно в gentoo уже сейчас, и уже давно зависимость от gcc снижена, прежде всего из-за проблем со сборкой софта одной новыми версиями gcc, чтобы держать в системе сразу несколько версий.
В общем то всё уже давно готово, чтобы заюзать новый и крутой компилятор в gentoo, debian и freebsd. Да только где он, этот рыцарь на белом коне.
Кстати по поводу PCC, был ведь супертурбированный и очень простой tinycc, которым можно было легко собрать большинство программ на С, заточенных под gcc. Ну и что от этого изменилось? Да ничего. Потому что для большинства случаев простой компилятор С никому не нужен, разве что разработчикам openbsd, у которых свой, особенный взгляд на мир.
| |
|
6.38, northbear (??), 12:38, 01/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
Все познается в сравнении. При любом раскладе дистр с бинарной пакетной системой проще будет перевести на другой компилятор в силу принципиально иной степени зависимости от компилятора.
При том, что отвязывание от конкретной версии компилятора gcc не означает полную независимость. Увы...
А наличие выбора нужно всем. Было время когда об альтернативе gcc никто и подумать не мог. А теперь gcc не кажется безальтернативным. Все в этом мире появляется растет и умирает. Придет время и GCC. Причем, есть основания полагать, что еще при нашей жизни...
| |
|
7.41, ixrws (??), 19:06, 01/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Все познается в сравнении. При любом раскладе дистр с бинарной пакетной системой
>проще будет перевести на другой компилятор в силу принципиально иной степени
>зависимости от компилятора.
>При том, что отвязывание от конкретной версии компилятора gcc не означает полную
>независимость. Увы...
Мне правда сложно понять в чём разница.И в том и в том случае нужно иметь универсальную архитектуру сборки, работающую на разных компиляторах. Разница лишь в том, что в случае gentoo её нужно иметь локально. Если бы бинарные пакеты брались откуда-нибудь с луны, тогда да. Но они тоже собираются. и тоже их желательно собирать автоматически, иначе поддержка пакетов будет адским делом.
>А наличие выбора нужно всем. Было время когда об альтернативе gcc никто
>и подумать не мог. А теперь gcc не кажется безальтернативным. Все
>в этом мире появляется растет и умирает. Придет время и GCC.
>Причем, есть основания полагать, что еще при нашей жизни...
Удивляют меня мысли о том, что что-то обязательно должно умереть, вот прямо обязательно. Даже у ms есть шанс полностью перестроить свой бизнес и продолжать здравствовать как крупная организация.
А у gcc этих шансов намного больше. Ничто принципиально не мешает перекроить архитектуру компилятора версии этак в 5й или в 6й. Вопрос только в том кто и зачем это делать будет, и на какие шиши. В случае допустим llvm, всё тот же вопрос. Кто и на какие шиши запилит там поддержку всех архитектур и языков. Если с clang, и даже с поддержкой c++, архитектурами arm, intel ещё понятно - ибо apple в этом заинтересована кровно. То со всем остальным не совсем понятно, будет ли на таком же уровне.
Все эти разговоры примерно также забавны, как разговоры о смерти linux в связи прихода микроядер и других, подобных тем. Они не учитывают возможности измениться, а это просто недальновидно. Вон Евросоюз живёт и здравствует, кто бы мог подумать это лет этак 90 назад.
| |
|
|
9.50, JL2001 (ok), 00:36, 04/01/2010 [^] [^^] [^^^] [ответить] | +/– | можно ссылку на причины и разбор или кодовое слово для поиска желательно на ру... текст свёрнут, показать | |
|
|
|
6.39, northbear (??), 12:49, 01/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Кстати по поводу PCC, был ведь супертурбированный и очень простой tinycc, которым
>можно было легко собрать большинство программ на С, заточенных под gcc.
>Ну и что от этого изменилось? Да ничего. Потому что для
>большинства случаев простой компилятор С никому не нужен, разве что разработчикам
>openbsd, у которых свой, особенный взгляд на мир.
Для подавляющего большинства случаев именно сложный компилятор С никому не нужен.
Проблема tcc как я понимаю, в том, что он изначально ориентирован на x86 платформу. Для разработчиков ядра, это плохая идея. А разработчики приложений совершенно резонно выбрали gcc. Ведь приложения тоже должны нормально работать на всех тех платформах, которые поддерживаются ядром.
| |
|
7.40, ixrws (??), 18:57, 01/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
tcc поддерживает не только x86, но и x86_64, arm, CIL, и даже TMS320C67xx.
Конечно поддержка там в разной степени завершённости, но завершить её не так уж и сложно.
Да, есть один существенный косяк - полное отсутсвие глобальной оптимизации, как следствие однопроходной архитектуры tcc. Но как простой и быстрый компилятор - он таки почти эталон.
| |
|
|
|
|
|
|
1.14, Vitaly_loki (ok), 00:05, 30/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Дак ведь в статье речь вроде как о языке Си идет и о том, что команда OpenBSD хотела бы иметь маленький лаконичный компилятор языке Си и ничего более, а не комбайн типа GCC. Так что пусть "ему как до Луны", ему это впринципе то и не нужно поддерживать столько языков... Типа, unix-way (Write programs that do one thing and do it well)
И да, LLVM тож очень хороший кандидат, имхо конечно
| |
|
2.25, Пожалуйста (?), 11:27, 30/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Тока вот казус, сам LLVM исполюзует C++ внутри.
И чтобы в этом случае запустить PCC с бэкендом на LLVM придется установить GCC.
| |
|
1.24, ssnet (?), 11:22, 30/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Все идет к миграции от С в строну С++. Думаю, что последний аплот С скоро будет только ядро и старые утилиты. PCC с поддержкой плюсов они точно не осилят. т.ч. либо PCC делать на уровне линковки совместимым с GCC, либо в категорию народных подделок.
| |
|
2.27, xxx (??), 13:44, 30/12/2009 [^] [^^] [^^^] [ответить]
| +2 +/– |
>Все идет к миграции от С в строну С++.
О, как, а ты не мог бы уточнить, что означает "ВСЁ" в твоём посте? А то пока во многих областях даже и не пахнет миграцией с С на С++.
| |
2.32, anonymous (??), 23:07, 30/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Все идет к миграции от C++ к связке одного из мультипарадигменных языков (Python/Ruby/Perl) и C (для критичных к скорости выполнения частях). А C++ со своим дурным синтаксисом и убогой реализацией метапрограммирования идет туда же, куда и COBOL.
| |
2.33, аноним (?), 23:20, 30/12/2009 [^] [^^] [^^^] [ответить] | +1 +/– | С в том или ином виде существует уже более 20 лет Если кто-то и хотел мигриро... большой текст свёрнут, показать | |
|
1.36, _Bulgarin (?), 11:38, 31/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>C Compiler), последние улучшения в котором позволили осуществить полный цикл сборки
>загрузочного ядра OpenBSD для архитектуры x86, а также большинства утилит и
>библиотек базового окружения. Поддержка сборки для платформы AMD64 в настоящий момент
>находится в состоянии активной разработки и будет доведена до рабочего состояния
>в ближайшее время.
>
Задача: Нуно легковесный, компактный с-компилятор для сборки *BSD-системы, которая написана на с. В системный комплект. И все.
Дебиан-шнобиан, генту-швенту - это сбоку припека.
Развели базар, целую философию мирообразования... :)
| |
1.48, Кодир (?), 21:38, 03/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну довели и довели! Толку-то... Си умер лет 15 назад, но "никто не заметил запаха и праздник продолжался". Сборщик мусора, развитая рантайм-инфа, обобщённое программирование, ООП, приколы из ФЯ - всё это громадой навалилось на современных прогеров и писать на атавизме типа Си - это заранее хоронить проект.
Было бы здорово, если бы учёные мужи уделили внимания языку D. Он внешне похож на Си, чем вызывает зевоту у ламеров, типа "ещё один клон". Однако, даже беглый взгляд по фичам Ди вызывает удивление (или того хуже: "А что это за фича?") у бывалых прогеров.
Конечно, переписать позорное поделие Торвальдса вряд ли смогут даже тысячи опенсорсников, но заменять прикладные свистелки уже вполне можно - пусть не используя всей мощности Ди, но хотя бы портируя в компилябельный вариант. Это даст и практику, и улетучатся такие раздражающие приколы Сей а-ля "null pointer" или "stack execution".
| |
|
2.53, Vitaly_loki (ok), 01:55, 04/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Ну довели и довели! Толку-то... Си умер лет 15 назад
Разработчикам ядер ОС, драйверов и т.п. расскажи, а то пишут бедняги на нем
Все эти ООП, сборщик мусора и т.д. миф, созданный компилятором. Можно написать класс с наследованием, получающий доступ к закрытым членам-методам другого класса на Си, просто писать это дольше, чем на С++
> Это даст и практику, и улетучатся такие раздражающие приколы Сей а-ля "null pointer" или "stack execution".
Дак писать надо грамотно, а не надеяться на то, что часть работы за тебя язык сделает
| |
|
3.54, demimurych (?), 17:28, 04/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Дак писать надо грамотно, а не надеяться на то, что часть работы за тебя язык сделает
Вы конечно правы, но боюсь упускаете что нет еще ни одного человека который бы писал без ашипак
потому и стремятся создавать инструменты, работая с которыми, минимизировать возможность их(ошибок) возникновения.
| |
|
|
|