https://opennet.me/openforum/vsluhforumID3/105778.html Вышел (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).<br><br><br><br>Напомним, что начиная с ветки GCC 5.x в проекте внедрена новая схема нумерации выпусков: версия x.0 используется в процессе разработки, корректирующие выпуски формируются с номерами x.2.0, x.3.0 и т.д. Новые возможности развиваются в экспериментальной ветке GCC 6.0, на базе которой будет сформирован следующий значительный релиз GCC 6.1. <br><br><br><br>URL: https://gcc.gnu.org/ml/gcc/2015-12/msg00056.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=43457<br> https://opennet.me/openforum/vsluhforumID3/105778.html#46 Thu, 07 Jan 2016 10:57:41 GMT &gt; Ну берём любую расчётную программу.<br><br>Любая расчетная программа обычно при запуске принимает входные данные для расчета и запускается не один раз.<br><br>На "одноразовой" программе - данные зашиты в код и запускается один раз - согласен, возможно, но ИМХО выигрыш будет не большой, так как на стадии компиляции компилятор в любом случае полностью разбирает каждое выражение.<br> https://opennet.me/openforum/vsluhforumID3/105778.html#45 Wed, 06 Jan 2016 23:28:48 GMT &gt; Так в противном случае это произойдет в рантийме, что уж совсем не <br>&gt; хорошо. Или речь о какой-то особой ситуации?<br><br>Ну берём любую расчётную программу. Очевидно, что компиляция в native code + выполнение будут быстрее интерпретации её компилятором (вычисление на этапе компиляции).<br> https://opennet.me/openforum/vsluhforumID3/105778.html#44 Tue, 08 Dec 2015 15:07:46 GMT Ну, хорошо. Но оптимизация кода не является частью языка. Зачем захламлять синтаксис директивами оптимизатора? Для того, чтобы "сказать" что-то компилятору, есть давно известные способы, например __attribute__ или #pragma. Почему бы их просто не стандартизировать, раз уж на то пошло? И следует ли теперь ожидать в С++ появления таких ключевых слов, как always_inline, cold, hot, noreturn, deprecated и т.д. - всего того, что влезает в __attribute__((...))?<br> https://opennet.me/openforum/vsluhforumID3/105778.html#43 Tue, 08 Dec 2015 13:25:37 GMT &gt; То есть всё, что не constexpr, он теперь не будет пытаться оптимизировать, <br>&gt; что ли?<br><br>Оптимизируется все. Но если программист указал constexpr, значит для него важно, что бы этот кусок был вычислен именно в compile time и вычисления в runtime для него неприемлемы.<br> https://opennet.me/openforum/vsluhforumID3/105778.html#39 Tue, 08 Dec 2015 12:43:00 GMT То есть всё, что не constexpr, он теперь не будет пытаться оптимизировать, что ли?<br> https://opennet.me/openforum/vsluhforumID3/105778.html#38 Tue, 08 Dec 2015 12:07:22 GMT &gt;&gt; 1) Программист с constexpr точно знает, что получилось - если хотел вычисление при компиляции, но это невозможно - получай ошибку, а не вычисление в рантайме.<br>&gt; Зачем _программисту_ об этом знать? Оптимизирует - _компилятор_. Вот путь он и <br>&gt; думает, сможет он оптимизировать выражение или нет. А магическое слово constexpr <br>&gt; возможности компилятора по оптимизации никак не увеличивает.<br><br>Смысл примерно тот же что и с "const int x = 3;" вместо "int x = 3;" - программист указывает, что данный кусок должен быть вычислен в compile time и если это невозможно он хочет быть явно уведомленным об этом.<br> https://opennet.me/openforum/vsluhforumID3/105778.html#37 Tue, 08 Dec 2015 12:01:41 GMT &gt; Просто ты ни хрена не понимешь идеологию плюсов. <br><br>Проблема в том, что идеология в них заменяет здравый смысл :)<br><br>&gt; 1) Программист с constexpr точно знает, что получилось - если хотел вычисление при компиляции, но это невозможно - получай ошибку, а не вычисление в рантайме.<br><br>Зачем _программисту_ об этом знать? Оптимизирует - _компилятор_. Вот путь он и думает, сможет он оптимизировать выражение или нет. А магическое слово constexpr возможности компилятора по оптимизации никак не увеличивает.<br><br>&gt; 2) Далеко не всегда всё, что можно вычислить при компиляции, надо вычислять. Это может быть абсолютно бессмысленно и адски долго.<br><br>А опциями компилятора для указания, что надо оптимизировать, а что нет, программисты на С++ уже не пользуются?<br> https://opennet.me/openforum/vsluhforumID3/105778.html#36 Mon, 07 Dec 2015 16:42:20 GMT &gt; как будто вы это руками делаете ...<br>&gt; но если вы это таки делаете руками (отлов тараканов сборки определённых пакетов <br>&gt; не в счёт), то есть не запилили полную автоматизацию всего и <br>&gt; вся - советую заняться чем-то более совместимым с вашим IQ например <br>&gt; вышиванием крестиком.<br><br>В виде примера чего-то более совместимого с IQ человека, собирабщего всю систему руками ожидал увидеть скорее чего-то типа проектирования космических кораблей или тому подобного...<br> https://opennet.me/openforum/vsluhforumID3/105778.html#35 Mon, 07 Dec 2015 16:18:56 GMT &gt; 2) Далеко не всегда всё, что можно вычислить при компиляции, надо вычислять. <br>&gt; Это может быть абсолютно бессмысленно и адски долго.<br><br>Так в противном случае это произойдет в рантийме, что уж совсем не хорошо. Или речь о какой-то особой ситуации?<br>