Вышел (https://gcc.gnu.org/ml/gcc/2015-12/msg00056.html) корректирующий релиз набора компиляторов GCC 5.3 (https://gcc.gnu.org/gcc-5/), в котором проведена работа по исправлению ошибок, регрессивных изменений и проблем с совместимостью. По сравнению с версией GCC 5.2 в GCC 5.3 отмечено 143 исправления (https://gcc.gnu.org/gcc-5/changes.html).Напомним, что начиная с ветки GCC 5.x в проекте внедрена новая схема нумерации выпусков: версия x.0 используется в процессе разработки, корректирующие выпуски формируются с номерами x.2.0, x.3.0 и т.д. Новые возможности развиваются в экспериментальной ветке GCC 6.0, на базе которой будет сформирован следующий значительный релиз GCC 6.1.
URL: https://gcc.gnu.org/ml/gcc/2015-12/msg00056.html
Новость: http://www.opennet.me/opennews/art.shtml?num=43457
В последнее время очень чётко прослеживается тенденция к ускорению инкремента циферок в релизах. Всякие Chrome 201, Firefox 189, SystemShi^WD 228. Ждём GCC 42.
А зачем нужно много чисел в версиях для проектов с релизами по расписанию (таких, как Firefox, Linux)? Двух вполне достаточно. А еще логичнее, чтобы в таком случае первое число обозначало дату релиза.
К сабжу это, естественно, не относится.
Ну, три числа всегда были в некотором роде "традицией". Мажорный номер версии менялся только тогда, когда нарушалась обратная совместимость, первый минорный -- когда добавлялся новый функционал, не влияющий на обратную совместимость, а третье -- для багфиксов.Что теперь все эти цыфири означают, я не знаю. Каждый придумывает свою нумерацию, и хрен поймёшь, что там и как меняется.
> когда добавлялся новый функционал, не влияющий на обратную совместимостьпрактически всегда каждый новый функционал влияет на обратную совместимость (в лучшем случае -- чуточку ухудшая её.. в худшем -- сильно ухудшая её).
вопрос вообщем в количестве этого влияния.
>> когда добавлялся новый функционал, не влияющий на обратную совместимость
> практически всегда каждый новый функционал влияет на обратную совместимость (в лучшем случае
> -- чуточку ухудшая её.. в худшем -- сильно ухудшая её).Нонсенс или плохой подход к разработке.
Так было не всегда ... (С)Один старый ребе :)
теоретик из макдональдса?
>Мажорный номер версии менялся только тогда, когда нарушалась обратная совместимостьНу не везде и не всегда так было. Вот, помнмится, GCC 3.4 в части C++ ABI нарушил совместимость с остальными версиями 3-ей ветки.
> А еще логичнее, чтобы в таком случае первое число обозначало дату релиза.В секундах от Р.Х.?
Если вам так удобно, может хоть в наносекундах от сотворения вселенной ;)
Я обычно упакованные срезы именую так: palemoon-151201.tar.xz
Что-то короткая у тебя история, нужно palemoon-20151201.tar.xz
Зачем? Я и до 20990101 скорее всего не доживу, а исходники проектов столетней давности могут быть интересны разве что историкам.
Просто люди мечутся из "крайности в крайность". В начале века в хакерско-линуксоидской среде было модно использовать версии в стиле 0.x.y, например вполне годный мессенджер Psi, которому 15 лет уже, до сих пор имеет версию 0.15.
Большинство изменений в g++ связано с обеспечением поддержки с++14
В общем, новые возможности добавляются всегда!
Убил пример:
>[оверквотинг удален]
> G++ now supports C++14 extended constexpr
> constexpr int f (int i)
> {
> int j = 0;
> for (; i > 0; --i)
> ++j;
> return j;
> }
>
> constexpr int i = f(42); // i is 42
Здоровья у тебя мало. Что тут особенного? Результат можно посчитать во время компиляции - можно, вот и работает.
Для статических переменных?
> Для статических переменных?Прочитал про constexpr, но пример все равно забавный.
В коде иногда нужно задать какие-то табличные данные, часто рассчитываемые. И вместо конструкций с #define можно и нужно использовать constexpr - теперь улучшенный и расширенный.
эдак, глядишь, допилят, потом шаблоны нормальные сделают, потом нормальное метапрограммирование — и получится D.
A Common Lisp, CL, когда получится?? ну ладно согласен на компилируемый в натив Clojure
Если результат можно посчитать во время компиляции, то почему бы компилятору его просто не соптимизировать, как это было всегда? Зачем нужна лишняя сущность? И что будет, если результат нельзя посчитать во время компиляции? Просто в тексте будет бесполезное слово constexpr?По-моему, С++ сейчас развивается по такому принципу: если какой-то костыль плохо выполняет свою функцию, нужно добавить ещё один костыль, который тоже будет плохо выполнять ту же функцию - но зато теперь у нас два костыля, плохо выполняющих одну и ту же функцию!
Просто ты ни хрена не понимешь идеологию плюсов.
1) Программист с constexpr точно знает, что получилось - если хотел вычисление при компиляции, но это невозможно - получай ошибку, а не вычисление в рантайме.
2) Далеко не всегда всё, что можно вычислить при компиляции, надо вычислять. Это может быть абсолютно бессмысленно и адски долго.
> 2) Далеко не всегда всё, что можно вычислить при компиляции, надо вычислять.
> Это может быть абсолютно бессмысленно и адски долго.Так в противном случае это произойдет в рантийме, что уж совсем не хорошо. Или речь о какой-то особой ситуации?
> Так в противном случае это произойдет в рантийме, что уж совсем не
> хорошо. Или речь о какой-то особой ситуации?Ну берём любую расчётную программу. Очевидно, что компиляция в native code + выполнение будут быстрее интерпретации её компилятором (вычисление на этапе компиляции).
> Ну берём любую расчётную программу.Любая расчетная программа обычно при запуске принимает входные данные для расчета и запускается не один раз.
На "одноразовой" программе - данные зашиты в код и запускается один раз - согласен, возможно, но ИМХО выигрыш будет не большой, так как на стадии компиляции компилятор в любом случае полностью разбирает каждое выражение.
> Просто ты ни хрена не понимешь идеологию плюсов.Проблема в том, что идеология в них заменяет здравый смысл :)
> 1) Программист с constexpr точно знает, что получилось - если хотел вычисление при компиляции, но это невозможно - получай ошибку, а не вычисление в рантайме.
Зачем _программисту_ об этом знать? Оптимизирует - _компилятор_. Вот путь он и думает, сможет он оптимизировать выражение или нет. А магическое слово constexpr возможности компилятора по оптимизации никак не увеличивает.
> 2) Далеко не всегда всё, что можно вычислить при компиляции, надо вычислять. Это может быть абсолютно бессмысленно и адски долго.
А опциями компилятора для указания, что надо оптимизировать, а что нет, программисты на С++ уже не пользуются?
>> 1) Программист с constexpr точно знает, что получилось - если хотел вычисление при компиляции, но это невозможно - получай ошибку, а не вычисление в рантайме.
> Зачем _программисту_ об этом знать? Оптимизирует - _компилятор_. Вот путь он и
> думает, сможет он оптимизировать выражение или нет. А магическое слово constexpr
> возможности компилятора по оптимизации никак не увеличивает.Смысл примерно тот же что и с "const int x = 3;" вместо "int x = 3;" - программист указывает, что данный кусок должен быть вычислен в compile time и если это невозможно он хочет быть явно уведомленным об этом.
То есть всё, что не constexpr, он теперь не будет пытаться оптимизировать, что ли?
> То есть всё, что не constexpr, он теперь не будет пытаться оптимизировать,
> что ли?Оптимизируется все. Но если программист указал constexpr, значит для него важно, что бы этот кусок был вычислен именно в compile time и вычисления в runtime для него неприемлемы.
Ну, хорошо. Но оптимизация кода не является частью языка. Зачем захламлять синтаксис директивами оптимизатора? Для того, чтобы "сказать" что-то компилятору, есть давно известные способы, например __attribute__ или #pragma. Почему бы их просто не стандартизировать, раз уж на то пошло? И следует ли теперь ожидать в С++ появления таких ключевых слов, как always_inline, cold, hot, noreturn, deprecated и т.д. - всего того, что влезает в __attribute__((...))?
Это ж теперь всю систему почти пересобирать.
> Это ж теперь всю систему почти пересобирать.Кому систему, а кому репозиторий...
как будто вы это руками делаете ...
но если вы это таки делаете руками (отлов тараканов сборки определённых пакетов не в счёт), то есть не запилили полную автоматизацию всего и вся - советую заняться чем-то более совместимым с вашим IQ например вышиванием крестиком.
> как будто вы это руками делаете ...Головой. Вы руками, видимо.
Он просто этого не делает, и пользует ваши труды.
Работать негр, солнце еще высоко.
> как будто вы это руками делаете ...
> но если вы это таки делаете руками (отлов тараканов сборки определённых пакетов
> не в счёт), то есть не запилили полную автоматизацию всего и
> вся - советую заняться чем-то более совместимым с вашим IQ например
> вышиванием крестиком.В виде примера чего-то более совместимого с IQ человека, собирабщего всю систему руками ожидал увидеть скорее чего-то типа проектирования космических кораблей или тому подобного...
А кто-нибудь читал сообщение с описанием новой схемы нумерации версий gcc? Можете объяснить? Я правильно понимаю, что схема следующая?1. каждый год увеличивается мажорная версия,
2. первый релиз с новой мажорной версией имеет минорный номер 1 (то есть не 5.0.0, а 5.1.0),
3. третье число версии всегда ноль (никаких 5.1.1 или 5.2.4, только 5.1.0 и 5.2.0).
> А кто-нибудь читал сообщение с описанием новой схемы нумерации версий gcc?а смысл? зараза «кроличьих релизов» и до них добралась, так что без разницы уже.
> А кто-нибудь читал сообщение с описанием новой схемы нумерации версий gcc? Можете
> объяснить? Я правильно понимаю, что схема следующая?Я к этому отношусь примерно как к сборнику анекдотов физики шутят: они исключительно головастые ребята, но юмор их тяжеловат. Ну, не понимаю - и ладно. И раньше я не понимал их стейджей, теперь и нумерации с трансцедентными нулями не буду понимать. Невелика потеря.
- - - Ну и хрен с ним, с плащом.
"идея" аналогично тому как "обзвать 4.x" Линусу про ядро - пришла ~ примерно.