Фонд свободного ПО и управляющий разработкой набора компиляторов GCC комитет принял (http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html) знаковое решение - отныне в коде GCC разрешено использование языка C++. Ранее в исходных текстах GCC было допустимо использование только языка Си. Данное решение не означает, что GCC будет переписан на C++ и не навязывает данный язык, а лишь позволяет использовать C++ в тех местах, где его использование оправдано и удобно разработчикам.
Список языковых возможностей и библиотек С++-, а также стиль кодирования, которые разрешено использовать в кодовой базе GCC, еще не до конца определены и будут формализованы в ближайшее время. В качестве отправной точки рассматривается вариант ограничения допустимых при разработке компиляторов возможностей C++, лишь стандартом C++98. Новшества, представленные в проекте стандарта C++0x (например, нестандартные шаблоны, множественные наследования и исключения), поддерживаться не будут, но они могут быть разрешены в буд...URL: http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html
Новость: http://www.opennet.me/opennews/art.shtml?num=26789
> Новшества, представленные в проекте стандарта C++0x
> (например, нестандартные шаблоны, множественные наследования и исключения),
> поддерживаться не будут, но они могут быть разрешены в будущем, при
> возникновении необходимости.Это неверный перевод оригинала, сильно искажающий смысл.
Оригинал:
> For example, I think it goes without question that at this point we are
> limiting ourselves to C++98 (plus "long long" so that we have a 64-bit
> integer type); C++0x features should not be used. Using multiple
> inheritance, templates (other than when using the C++ standard library,
> e.g. std::list<X>), or exceptions also seems overly aggressive to me.Мухи отдельно от котлет в оригинале. Новшества C++0x отдельно, а шаблоны, множественное наследование и исключения отдельно (это всё есть в C++98).
Новость одновременно и хорошая и плохая. С прямыми руками и здоровыми извилинами это может пойти лишь на пользу. С кривыми же - можно такого наворотить, что текущий код на C покажется сказкой. Посмотрим, как пойдёт..
То есть вы допускаете что к разработке GCC, который контролируются православным FSF могут допустить кривые ручки? :)
Я не то чтобы допускаю - я практически в этом уверен. Посмотрите вовнутрь текущего православного GCC. Или binutils. Местами такой мрак.. Уму не постижимо, сколько можно дров наломать обычной крестовой отверткой. А если этим ребятам дать в руки по бензопиле..?PS: Да, я тоже день изо дня использую GCC для разработки. И он меня вполне устраивает. И если не глядеть вовнутрь проекта, то никаких проблем. С сугубо потребительской точки зрения - вполне нормальный продукт, авторам зачет.
То была ирония по поводу FSF. Я знаю как gcc выглядит изнутри и даже потратил какое-то время чтобы разобраться как оно работает. Безрезультатно к сожалению.
> сколько можно дров наломать обычной крестовой отверткойБожественная фраза! Спасибо.
Всё понятно. Слава LLVM и Clang спать не даёт. Ребята поняли, что на C++ всё-таки можно писать быстрый и эффективный код без танцев с бубнами ))) Тенденция радует )
Слава? Простите, но эти проекты до сих пор в песочнице и для серьёзных задач не используются.
Уж не используются? Apple во всю LLVM использует, Adobe тоже. Далее мы разве забыли такие проекты как unladen-swallow, LLVM JIT для Mono и многие другие. GCC для новых проектов практически не используется(на памяти только порт Go для GCC и Google NaCl, да и то для последнего уже делают LLVM компилятор).
Господа из Эппла и Адоба в своих закрытых проектах могут использовать абсолютно все, что им заблагорассудится. Хоть все на LISP переписать от и до. Мне, как человеку, не имеющему к их разработкам прямого отношения, это совершенно фиолетово. Как пользователю же - тем более.
Вопрос стоял о серьезности проектов использующих GCC. Ответ был дан, что есть коммерческие компании которые его используют. От того что это закрытые или открытые проект суть не меняется.
Ну скорее не GCC а LLVM но понятно. Но тем не менее, а можно как-то развернуть эту тему? Хотя бы Адоб или Эппл используют LLVM. Иначе как-то странно получается. Вроде как лишь от одного только факта упоминания этих компаний я должен описаться кипятком и поверитьь в тру-интерпрайзность LLVM. Вот, допустим, где используется GCC я вполне себе представляю. Включая коммерческие проекты. В некоторых из которых я принимал участие. А вот по поводу LLVM - а бог то его знает. Слухи, слухи..
господам из apple и adobe нравится лицензия из llvm
А еще эти господа друг другу не нравятся :D. Пусть там попережрут друг друга и поудавливаются своей жабой. Единственное чем им GPL не нравится - делиться видите ли надо. Ну так пусть тягают свои местечковые велосипедики и дальше, некоторых история ничему не научила :)
> некоторых история ничему не научила :)Что ж ты параноик-то никак не успокоишься. Никто LLVM не будет закрывать. И как тебя понимать, что они кодом не делятся - они делятся кодом под самой либеральной лиценизей, кто хочет может делать с этим кодом все что угодно.
Вот если бы они были действительно плохими ребятами - они бы выпускали код под GPL и тогда никто кроме опенсорсных проектов не смог бы им пользоваться. Но для себя они бы использовали его под коммерческой лицензией, так как авторы кода работают в Apple и могут делать со *своим* кодом все что захотят. Вот это было бы уже совсем другая история. Так что не надо бреднями своими морочить голову.
>под GPL и тогда никто кроме опенсорсных проектов не смог
>бы им пользоватьсяПользоваться проектами под GPL можно _без_ограничения_.
Или Вы нетонко имели в виду другое "пользовать"?
"Этим" здесь не подают -- да, так и было задумано, проходите, не задерживайтесь.IHBT
>Пользоваться проектами под GPL можно _без_ограничения_.Без ограничений, ну-ну. Почему же тогда FreeBSD после перехода GCC на GPL3 не может пользоваться его последними версиями?
Наверное потому что не хотят. Вряд ли из-за лицензии. Или ссылку в студии почему нельзя собрать BSD код православным GPLv3 GCC?
Из-за лицензии на стандартную библиотеку. Новость пробегала.
> Что ж ты параноик-то никак не успокоишься. Никто LLVM не будет закрывать. И как тебя понимать, что они кодом не делятся - они делятся кодом под самой либеральной лиценизей, кто хочет может делать с этим кодом все что угодно.Закрыть LLVM будет сложно. Официальный копирайт на код принадлежат University of Illinois. И каждый разработчик (не зависимо от того, из apple он, или со стороны) подписывает специальную бумагу.
>А, вообще: http://llvm.org/docs/DeveloperPolicy.html#clpАга, "may eventually reassign the copyright". Превожу: г-да профессОры неспешно подыскивают спонсора-партнёра для обналичивания переписанных [старушкой проценщицей~] прав. Родион Раскольников, Университет Иллинойяа....
>Ага, "may eventually reassign the copyright". Превожу: г-да профессОры неспешно подыскивают спонсора-партнёра для обналичивания переписанных [старушкой проценщицей~] прав."may eventually reassign the copyright(e.g. a dedicated non-profit "LLVM Organization")"
Вот это тролль, цитаты полностью приводи пожалуйста.
e.g. -- это example gratis. Оне ж либерасты, могут и non gratis показать.
Так это не мне надо говорить а User294, у которого паранойа, что Apple закроет LLVM и покажет всем большую фигу.
> Закрыть LLVM будет сложно. Официальный копирайт на код принадлежат University of Illinois. И каждый разработчик (не зависимо от того, из apple он, или со стороны) подписывает специальную бумагу.Почему сложно? По моему как с MySQL один в один, все права на код были в одном месте и что бы закрыть достаточно продаться этому владельцу.
Типа того, только еще и все разработчики - в эппл, если толстый трололо не приврал. В случае мускуля - Монти из санок-ораклов свалил. И как-бы совсем закопать проект - не даст, видимо. А вот тут - все целиком зависит от доброй воли одной весьма жадной и стремной шарашки, если трололо не приврал.
> Никто LLVM не будет закрывать.А где гарантии? А то дарвиновское ядро эппл закрывал аж два раза - хакинтоши им видите ли помешали. Что им помешает повторить этот волшебный фокус-покус?
> они делятся кодом под самой либеральной лиценизей,
Да, особенно либерально может выйти когда и если Эппл объявит "фиг вам всем" при том что (как вы сами сказали, я вас за язык не тянул) там сторонних разработчиков аж 1 штука. При этом все кто заложился на это в такой ситуации должны слать смс на короткий номер с текстом "не лох", так? Ну вот вы и закладывайтесь на целый один эппл и их доброту и щедрость, при том что форкать в случае чего - некому. Ага. А я уж лучше на GCC буду закладываться - там в силу лицензии прихватизировать его развитие и приложить всех фэйсом об тейбл - проблематично. И да, лично мне никак и ничем лицензия GCC не мешает. Что GPL2, что GPL3.
> они бы выпускали код под GPL и тогда никто кроме опенсорсных проектов не смог
> бы им пользоватьсяОй, какой толстый трололо. Мне как, показать вам случаи применения GCC откровенными коммерсантами, вплоть до коммерческих IDE? :) Или как board support tool для embedded штук - gcc просто стандарт де-факто стал. Что хорошо - в отличие от ф@кин` блобятины, GCCом в итоге можно пользоваться не только под той системой под которую ее собрали, но еще и под той под которой лично мне удобно. И это не баг а фича, имхо. В самом хучем случае я попаду на пересборку тулчейна. Что все-таки явно лучше чем постоянно снощаться с неудобной мне операционкой.
Если взялся отвечать, то отвечай на все позиции, а не выдирай отдельные предложения и их комментируй.> А я уж лучше на GCC буду закладываться - там в силу лицензии прихватизировать его развитие и приложить всех фэйсом об тейбл - проблематично.
Еще раз повторю для тугих, даже если бы Apple выпускала LLVM под твоей православной GPL, она бы сама могла использовать LLVM под какой угодно лицензией, так как "там сторонних разработчиков аж 1 штука" - то есть все работают на Apple и могут *перелицензировать* код. И могли это сделать уже давно.
>Мне как, показать вам случаи применения GCC откровенными коммерсантами, вплоть до коммерческих IDE? :)
Максимум что они могли сделать - это использовать его в качестве компилятора. В силу убогости его архитектуры и лицензии они не могут использовать GCC в качестве анализатора кода, делать семантический анализ, автокомплит и прочие вкусности IDE.
>Еще раз повторю для тугих, даже если бы Apple выпускала LLVM под
>твоей православной GPL, она бы сама могла использовать LLVM под какой
>угодно лицензией, так как "там сторонних разработчиков аж 1 штука" -
>то есть все работают на Apple и могут *перелицензировать* код. И
>могли это сделать уже давно.Вот именно поэтому и стоит держаться от него подальше.
>Максимум что они могли сделать - это использовать его в качестве компилятора.
>В силу убогости его архитектуры и лицензии они не могут использовать
>GCC в качестве анализатора кода, делать семантический анализ, автокомплит и прочие
>вкусности IDE.gcc с автокомплитом? что это и как это работать должно? О_О
и чем лицензия мешает делать семантический анализ с помощью gcc?
>Еще раз повторю для тугих, даже если бы Apple выпускала LLVM под
>твоей православной GPL, она бы сама могла использовать LLVM под какой
>угодно лицензией,Так она и с BSDL так может. Более того - с ядром макоси именно такой фокус и был проделан, аж 2 раза, кстати. А если лицензия GPL и без оговорок про то что все права на патч отдай этой фирме - то после первого же коммита стороннего человека закрыть код становится труднее, а при большом количестве коммитов - практически гарантирует незакрываемость проекта. Что служит хорошей подстраховкой от подлян по типу "мы передумываем, вот вам жирная фига, а мы тут закрываем код, сосите". В случае bsdl - код можно закрывать сколько влезет, лишь бы автор был указан. Ну и в итоге - с BSDL возможность кидка тех кто вляпался остается всегда и всегда будет соблазн сэкономить на них, сорвать куш за их счет и все такое. Ну а поскольку лицензия позволяет - прецеденты были.
>так как "там сторонних разработчиков аж 1 штука" -
>то есть все работают на Apple и могут *перелицензировать* код. И
>могли это сделать уже давно.Ой, не притворяйтесь шлангом, у вас плохо получается. В случае с GPL по крайней мере сразу все понятно насчет намерений: если вас не просят сдать все ваши права на код для возможности смены лицензии, значит закрытие скорее всего не состоится и есть некие гарантии - чувакам придется переписать весь контрибученый код чтобы поиграть мускулами и показать всем фигу. А вот с BSDL вы сами и добровольно даете подобный по смыслу прав набор прав вон той конторе и прочим. Он достаточен для такого действа. А если вы хотите попиндеть про то что это интеллектуальная собственность эппл, им типа можно, и все такое - ну вот пусть сидят с своей собственностью и пашут на ней сами, имхо. Нефиг тогда на комьюнити расчитывать, собственно. Сам же Эппл и показал что вкалывать на него бесплатно бывает чревато, позакрывав дарвинистское ядро. После чего ессно комьюнити вокруг этого ядра мигом испарилось (да, лохов среди програмеров - немного) и теперь это ядро толком никому не нужно. Потому что все кто в нем разбирался остались только в Эппл а остальных разогнали недружественной политикой основной команды. Не вижу что помешает эпплу повторить фокус в случае давления жабой, что для них характерно.
>>Мне как, показать вам случаи применения GCC откровенными коммерсантами, вплоть до коммерческих IDE? :)
>Максимум что они могли сделать - это использовать его в качестве компилятора.А, собссно, что еще нужно делать с ... компилятором?! :) Именно это они и делали. Парочка особо наглых вообще ухитрились заворкэраундить GPL юзая GCC с поддержкой архитектуры чисто внутри себя а потому как бы в силу GPLv2 они никому сорсы и не должны. Так что остальные вообще в пролете. Ну вот теперь таким умникам будет потяжелее с их воркэраундами. Пусть у эппла тырят и прочая. И пускай лучше Эппл свой бюджет без отдачи от таких красавчиков просирает чем комьюнити даром впахивает на всяких бесполезных жлобов. Отдачи то с таких орлов ровно ноль один фиг. А значит это зря потраченные на них время, силы и/или бабки. Вот Эппл пусть и тратит свои ресурсы без отдачи, имхо.
>В силу убогости его архитектуры и лицензии они не могут использовать
>GCC в качестве анализатора кода, делать семантический анализ, автокомплит и прочие
>вкусности IDE.Кхе-кхе, а почему КОМПИЛЕР вообще должен заниматься скажем автокомплитом? Вы что курите, сэр?! oO А может, компилер еще и тапочки должен приносить? И, собственно, а что мешает IDE автокомплетить все что оно там хочет вплоть до имен переменных вообще никак не дергая по этому поводу КОМПИЛЕР, который вообще обязан только код генерячить. Желательно качественный и безглючный и чем больше архитектур он понимает - тем легче жизня(осваивать стопицот тулчейнов - больно геморно).
А можно ссылки на обстоятельства дела по поводу закрытия исходников Darwin?(Думается мне, что вся твоя казуистика, на основе которой ты выводишь далеко идущие мрачные перспективы открытым проектам, не стоит ровным счётом ничего.)
> Apple во всю LLVM использует, Adobe тожеПравильно, потому что GCC им не дает дедушка Столлман. Честь и хвала ему!
> эти проекты до сих пор в песочнице и для серьёзных задач не используютсяА мужики-то не знают...
Пропал Калабуховский дом....
Как известно с++-ники только все портят и бибикают ...R.I.P. GCC - ты был хоть и не красавец, но надёжный друг. :-(
Это - основание конца GCC.
Ви-таки имели в виду front-end или back-end псс??---И да, з Вас Фрейд ворочается....
1. I hate gcc with the burning heat of a million suns. It's not a tool, it's a political weapon wielded by the FSF and their acolytes. It's also a crummy piece of software that has been "good enough" for far too long. Its development model is a burden to work with and has been a major liability towards FreeBSD releases in the past. Its demise cannot happen soon enough.2. Due to the political bent of the GPL3 and the FSF's insistence on shoving it down everyone's throats, FreeBSD is stuck with a dead-end version of gcc. This has already been a liability in terms of addressing bugs in gcc itself, and it will only get worse as technology moves forward and gcc stands still.
3. Clang/LLVM has an active development base and a clear future. It will move forward while gcc rots. There simply is no future left in gcc unless the FreeBSD project decides to embrace the GPL3, and that's a move that has already been heavily discussed, debated, and decided on. Anecdotally, I think that FreeBSD is benefiting from shunning the GPL3; it's made it an attractive option for companies looking for an unencumbered OS for their products.
4. While Clang is immature now, it will mature in the near future, and FreeBSD will benefit from that process. FreeBSD will get built-in access to upcoming technologies like GCD+Blocks and better code editors and development tools that gcc will never support. It'll break free of the development stranglehold that exists within gcc. Clang has shown good agility in adapting to the needs of FreeBSD and the legacy of gcc, thanks in large part to the efforts of people like Roman. Gcc has been nothing but drama and headache, even with the valiant efforts of people like Alexander Kabaev.
5. If all of this turns out to not be true and Clang/LLVM fails, FreeBSD has lost nothing and can remove it from the base system. Gcc remains where it is for now, at least until it's time for the "remove gcc discussion".
The future is !gcc. Putting Clang+LLVM into a position where it can be easily embraced by FreeBSD users will greatly benefit the FreeBSD project.
Scott
Who cares? GCC "just works". А большего от ничего и не требуется. И, хотите или нет, в определённых кругах является стандартом де-факто без каких-либо реальных перспектив замены. Если же он почему-то не работает именно во FreeBSD - well..PS: И, да, почему же он у меня то всю жизнь работал в *BSD? Наверное, они у меня были какие-то неправильные :-?
> Who cares? GCC "just works".Для кого-то и виндовс works. Просто все зависит от ваших требований к софту и дальновидности. Кому-то "Hello, world!" собрать, и "больше ничего не требуется", а кто-то потратил уйму времени на ковыряние в кишках этого кошмара.
Windows как бы принадлежит одной конторе. Его клепает и развивает одна контора. И кстати у нее есть вполне конкретная цель - поиметь с вас как можно больше бабла. Кстати, У Эппла как ни странно тоже есть такая цель. И учтя что у эппла нынче талант отворачивать от себя опенсорсные комьюнити - развивать ЭТО вероятно будет эппл в одну харю в основном. Со всеми вытекающими. Типа потуг впарить вам макос, xcode, мак, ифон, ... - а все остальное как обычно будет вторым сортом. Ну, как у майкрософт, собственно.Ну да, конечно MS что-то такое втирал что под ифон толи можно, толи будет можно програмить из MSVS но как-то всем понятно что это будет грабельно, криво и вообще извращение. А Эппл ничем таким не лучше, кроме того что чуть подинамичнее и потому играет в опенсорс более правдоподобно. А на самом деле - такой же жлобский проприетарщик как и MS, просто политическая ситуация нынче не в пользу проприетари, вот и приходится изгаляться.
>
>Who cares? GCC "just works". А большего от ничего и не требуется.
>И, хотите или нет, в определённых кругах является стандартом де-факто без
>каких-либо реальных перспектив замены. Если же он почему-то не работает именно
>во FreeBSD - well..
>
>PS: И, да, почему же он у меня то всю жизнь работал
>в *BSD? Наверное, они у меня были какие-то неправильные :-?Это потому что у вас нет в голове таких могучих тараканов как у автора этого английского текста :)
>1. I hateHence you lose.
Честно говоря, если бы они объявили что будут использовать исключительно питон для разработки gcc, я бы понял. Если бы они сказали, что будут юзать джаву или си шарп я бы тоже понял. Но то что они говорят такую ересь, как смешивать Си и Си++ я понять никак не могу!
В чем же ересь?
>В чем же ересь?"Ересь" в том, что LLVM на текущей стадии развития может собрать GCC. А когда GCC перепишут на C++, то LLVM вряд ли это сможет сделать. :))
>>В чем же ересь?+1
>"Ересь" в том, что LLVM на текущей стадии развития может собрать GCC.
>А когда GCC перепишут на C++, то LLVM вряд ли это
>сможет сделать. :))А-а-а, в этом смысле. "они наши расширения Си реализовали, объявляем C++0x расширением Си gcc -- пусть потеют"? Там в чём ересь-то?? И по каконам _какой церкви+++ :-P
>Данное решение не означает, что GCC будет переписан на C++ и не навязывает
>данный язык, а лишь позволяет использовать C++ в тех местах, где его
>использование оправдано и удобно разработчикам.уж лучше бы постепенно переписывали