gcc по книге Артура Гриффитс

доброго времени суток, узнав о возможностях С/С++ в linuxe мне захотелось сразу начать прогать из под Linux(a)=) но мои знания в этих языах были малы и я начал изучать их из под винды , но майкрософт искажает некоторые стандарты( теперь когда я набрал нужный уровень понимания языка я решил перейти на Linux. вот только столкнулся с проблемой установки gcc, !? вернее с незнанием Linuxa...
пытался поставить как это описано в книге Артура Гриффитса компилятор GNU но не смог разобраться(
кто может помочь установить gcc-3.1 или выше ? У меня стоит Ubuntu 10.04/ заранее спасибо !)

0

Там, откуда ты запускал gcc.

0

Астик, на твоем нынешнем уровне владения как языком разработки так и "средой разработки", порекомендовал бы тебе все же юзать что-то вроде этого. там линукс и gcc-4.6.2.

0

Сообщение от ksandro Интересно что за стандарты искажает gcc? В gcc как и в ms vc есть расширения, но ни как не искажения, вроде gcc как и современные версии микросовтовского компилятора достаточно хорошо поддерживают стандарт.

Потому "искажает" было взято в кавычки.

Ну а по части Си++ если смотреть изменения, которые были за последние 10 лет в gcc, то можно увидеть, что у них постоянно идёт приближение к стандарту. И это уже никакие не расширения, а в чистом виде ошибки реализации (g++ допускал слишком много конструкций, которые по стандарту Си++ запрещены)

Сообщение от Астик стандарты поддерживаются большей степенью Linux- ом =)

Слабо себе представляю, как это операционная система может поддерживать стандарты языка программирования

Сообщение от NoMasters Между прочим, gcc 3.1, как и вся третья ветка, давно протух

А в чём выражается протухшесть третьей ветки gcc?

Добавлено через 46 секунд

Сообщение от Астик главное понять принцип работы с gcc

https://www.cyberforum.ru/faq/thread61845.html

1

Сообщение от Evg А в чём выражается протухшесть третьей ветки gcc?

В том, что уже вышел gcc 4.6?

0

Сообщение от NoMasters В том, что уже вышел gcc 4.6?

И из какого места теперь следует, что компилятор 3-й ветки протух? Что конкретно там протухло? Что там перестало работать из-за появления компилятора версии 4.6?

0

Там никогда не работало часть из того, что может новая версия. Просто потому, что в том время этого ещё не было реализовано. С 2006 года прошло уже достаточно много времени, какой смысл использовать старую версию, когда есть свежая, заведомо более фичастая?

0

Сообщение от NoMasters Просто потому, что в том время этого ещё не было реализовано. С 2006 года прошло уже достаточно много времени, какой смысл использовать старую версию, когда есть свежая, заведомо более фичастая?

новые фичи есть новые баги, очевидно же

0

Сообщение от NoMasters Там никогда не работало часть из того, что может новая версия

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

Сообщение от NoMasters какой смысл использовать старую версию, когда есть свежая, заведомо более фичастая?

В мире дохренища всякого софта, который вылизан и стабильно работает. А при замене версии компилятора имеется риск того, что софт перестанет работать. Причина риска может быть обоюдная: ошибки в софте (которые не проявлялись на одной версии компилятора, но могут проявиться на другой) и ошибки в компиляторе (потому что любая новая версия программного продукта помимо исправления старых ошибок содержит ещё и новые ошибки). И разработчики подобного софта 100 раз всё обдумают и взвесят, прежде, чем переходить на новую версию компилятора. Разумеется, речь тут НЕ идёт обо всяком опенсорсном гов...е типа Ubuntu, разработчики (сборщики) которого с лёгкой руки перейдут на новую "фичастую" версию компилятора, переложив отладку своих деяний на плечи пользователей

В своё время компания Oracle очень долго сидела на устаревшей версии Intel'овского компилятора, да ещё и постоянно напрягали Intel на предмет исправления ошибок в этой версии. Потому что переход на новую версию компилятора по их оценке мог бы выйти очень дорогим

0

То есть С++11 не нужен?) А относительное количество багов на строку кода для развивающихся проектов — вещь почти константная.

0

Сообщение от Астик во первых с++ изначально был написан для Unixa и вряд ли там их больше...

ну да, ни линукса, ни виндовса тогда не было

Сообщение от Астик на лекция по VS в бауманке преподы то и дело говорили

те инфа 100%

0

Сообщение от NoMasters То есть С++11 не нужен?

Для поддержки и развития старого софта - в большинстве случаев нахрен не нужен

0

Сообщение от NoMasters То есть С++11 не нужен?)

в ближайшие >2 лет - не нужен

Сообщение от NoMasters А относительное количество багов на строку кода для развивающихся проектов — вещь почти константная.

gcc более чем зрелый продукт
вообще сложно так смело говорить о показателях качества (к коим относятся баги) продукта

0

микрософткомпилер на самом деле плохо поддерживает стандарт 2003 и еще хуже 2011.
подобные темы есть на многих форумах.
к тому же, gcc реально догнал и иногда опережает микрософткомпилер по качеству генерируемого кода. и как следствие - по скорости выполнения полученного бинаря.

Добавлено через 1 минуту
к тому же, в тестах используется и gcc-3.4.2. сравните его показатели с gcc-4.6.3

Добавлено через 2 минуты
к чему споры? gcc даже intel иногда обгоняет

Добавлено через 4 минуты
так что молва о том что gcc генерит плохой код - теперь миф, дань истории

0

Сообщение от niXman так что молва о том что gcc генерит плохой код - теперь миф, дань истории

У нас на работе люди занимаются всякой gnu'той хренью (ядро, binutils, glibc, всякое по мелочи). И у них в среднем вырисовывается мнение, что все эти многлоплатформенные продукты в последние лет 5-6-7 начинают иметь очень сильный перекос в сторону Intel'а. Т.е. больше усилий начинают тратить на вылизывание Intel'овских кодов и всё чаще по остаточному принципу делаются коды под остальные платформы. Например, самолично ковырялся с тем, что gcc для sparc'а ошибочно работает с программными соглашениями ABI64 (что, на мой взгляд, является вообще недопустимой ситуацией со стороны компилятора). Не помню точно, но вроде бы glibc-2.7 (а может и более поздние версии тоже) из официальных исходников под sparc вообще не собираются (из-за ошибок) и требуется патч. Так что это не миф, и не дань, а просто перекос из одного в другое

0

на самом то деле, Intel архитектура самая популярная. может быть по этому приоритет ставится на Intel?

Добавлено через 7 минут
к тому же, gcc - открытый проект. ты всегда можешь помочь, и предложить свои патчи для лучшей кодогенерации под SPARC

Добавлено через 51 секунду
или на крайняк, слать баги.

0

Сообщение от niXman на самом то деле, Intel архитектура самая популярная. может быть по этому приоритет ставится на Intel?

Ну логично, что именно по этой причине перекос ушёл в сторону Intel'а (а не какой-нибудь другой архитектуры). Но причина возникновения перекоса скорее всего другая. Когда всё это хозяйство только появилось (где-то в 80-х годах), аппаратных платформ было много, но они работали либо на общих принципах, либо хорошо описывались в одних и тех же терминах. А современные платформы по аппаратным фичам начинают уже очень сильно отличаться. И поэтому всё сложнее и сложнее становится писать общую архитектурно-независимую часть. У gcc, например, вплоть до версии 2.95 был аппаратно-независимый кодогенератор (т.е. один и тот же кодогенератор использовался для генерации и планирования кода под все платформы). Именно поэтому у gcc было очень низкое качество кода. Начиная с 3-й ветки они кодогенератор сделали аппаратно-зависимым. Именно с этого момента качество и стабильность кода начали расти, но взамен вместо одного компилятора с кучей мелких аппаратно-зависимых настроек, gcc превратился в кучу компиляторов на кучу платформ (с точки зрения построения исходников gcc). Т.е. такая конструкция требует гораздо больше временнЫх и человеческих ресурсов для разработки и тестирования. Ну и поэтому "прочим" платформам уделяется всё меньше и меньше времени

0

ну ясно...

0

Сообщение от niXman к тому же, gcc - открытый проект. ты всегда можешь помочь, и предложить свои патчи для лучшей кодогенерации под SPARC

Да проблема же не в ошибке, а в реализации программных соглашений. Т.е. после исправления этой хрени коды из-под старого и нового компилятора будут несовместимыми. И с этой точки зрения совместимость, скорее всего, является более важным критерием, чем ошибка в реализации ABI. Просто при реализации ABI изначально надо было подходить правильно. У них уже в этом месте была однажды революция - они сделали такие несовместимые исправления ошибки в gcc-3.4.0. Пойдут ли они на это ещё раз - хз. Может в gcc-4 и пошли. Но gcc-4 для sparc'а у нас никто не использовал - боязно как-то, и без того геморрою достаточно

0

Сообщение от Evg проблема же не в ошибке, а в реализации программных соглашений. Т.е. после исправления этой хрени коды из-под старого и нового компилятора будут несовместимыми.

ааа, вот ты о чем. (не понял изначально)

0

В плане платформонезависимости интересен LLVM, свежие версии gcc умеют его использовать в качестве бэкенда.

0