LINUX.ORG.RU
Новости — GNU's Not Unix  

GCC 6.1

 , ,


1

5

Состоялся релиз GCC 6.1 — набора свободных компиляторов с открытым исходным кодом. Основным новшеством стало применением в компиляторе C++ по умолчанию стандарта C++14 и улучшение экспериментальной поддержки C++17. Кроме того расширены средства диагностики, заявлена полная совместимость с OpenMP 4.5 и поддержка системной библиотеки musl. Также заявлено об улучшении поддержки платформ ARM и поддержке процессоров AMD Zen, Intel Skylake, IBM z13 и IBM POWER 9.

Основные изменения:

  • Активировано по умолчанию для языка C++ использование стандарта C++14 (применяется режим -std=gnu++14 вместо -std=gnu++98). Кроме того добавлена поддержка расширения системы шаблонов C++ Concepts, активируемая опцией -fconcepts. Реализованы некоторые новые элементы будущего стандарта C++17, такие как выражения fold, символьные литералы u8, расширенный static_assert и вложенное определение пространств имён. Реализована возможность вычисления констант для всех бестиповых аргументов шаблонов. Добавлена поддержка транзакционной памяти (C++ Transactional Memory) при сборке с опцией -fgnu-tm;
  • Для runtime-библиотеки libstdc++ расширен набор специальных математических функций (ISO/IEC 29124:2010), добавлена экспериментальная поддержка стандарта C++17 (в том числе новые функции std::size, std::empty, std::data для контейнеров и массивов, std::uncaught_exceptions, std::invoke, std::shared_mutex, std::void_t и std::bool_constant), экспериментальная поддержка File System TS, экспериментальная поддержка второй версии Library Fundamentals TS, поддержка std::locale для DragonFly и FreeBSD;
  • Появилась поддержка Си-библиотеки musl, которую можно использовать на Linux-системах с архитектурой AArch64, ARM, MicroBlaze, MIPS, MIPS64, PowerPC, PowerPC64, SH, i386, x32 и x86_64. Поддержка включается опцией -mmusl или при выборе архитектуры по маске *-linux-musl*.

>>> Подробности (на английском языке)

★★★★★

Проверено: Klymedy ()
Последнее исправление: Klymedy (всего исправлений: 2)

 ← 1 2 3 4 5 →
Ответ на: комментарий от anonymous

Не знаю, как у тебя, я а у меня тупой проход по единственному массиву бывает крайне редко.

Не знаю как ты, а я для этих целей пишу свои итераторы, работающие максимально эффективно на тех данных, которые я ожидаю.

Какого ещё мейнтейнера?

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

систему сборки со встроенной подгрузкой либ

Зачем? -llibrarry_name на этапе линковки и всего делов.

Отсутствие необходимости тянуть сторонние библиотеки для тривиальных вещей типа работы с ФС

Говорю же, Qt5.

robus ★★★★★
()
Ответ на: комментарий от anonymous

Я знаю, что Клэнг - компилятор. Поэтому и <ЖЫР>

robus ★★★★★
()
Ответ на: комментарий от anonymous

Так-то и с gcc часто пакеты не компиляция при обновлении его или самих пакетов, пока код не поправишь или флаги компилера не выставишь, теоретик.

Павесь у себя на мониторе записку «Я идиот!» Ты пишешь не о косяках компилятора. Это настроечные замуты.

А Клэнг всё ещё не может скомпилировать ядро Линукса, бе-бе -бе!

anonymous
()
Ответ на: комментарий от robus

Не знаю как ты, а я для этих целей пишу свои итераторы, работающие максимально эффективно на тех данных, которые я ожидаю.

Когда нормальные люди используют уже готовые комбинаторы.

Зачем? -llibrarry_name на этапе линковки и всего делов.

А правильные версии библиотек подгонят эльфы? Или «те мейнтейнеры»? Или зоопарк из автосрани, смейка, и мейкфайлов на полмегабайта?

anonymous
()
Ответ на: комментарий от anonymous

Или «те мейнтейнеры»?

Ты не поверишь! В Readme указываем требуемые версии и мейнтейнеры разрешают зависимости.

зоопарк из автосрани, смейка, и мейкфайлов на полмегабайта

Всегда казался мне странным и противоестественным.

robus ★★★★★
()
Ответ на: комментарий от robus

а я для этих целей пишу свои итераторы

В этом и проблема. Лучше было бы иметь готовые, разве нет?

работающие максимально эффективно на тех данных, которые я ожидаю

Это тривиальные юзкейзы, там нечего оптимизировать. Они вообще делаются через индексы, но ведь было бы удобнее через range-based for. Да и простой for в C++, мягко говоря, обладает излишней гибкостью.

Зачем?

Затем, что это более простой и гибкий подход.

-llibrarry_name на этапе линковки и всего делов.

А потом кто-то хочет законтрибьютить в твоё поделие, качает исходники и вместо того, чтобы спокойно собрать проект одной командой, начинает ставить себе нужные либы.

Говорю же, Qt5.

Окей, принято.

anonymous
()
Ответ на: комментарий от tp_for_my_bunghole

До сих пор отмыться не могу от этого паскаля.

Если до сих пор нельзя отмыться, после предположительно очень долгого периода времени, то паскаль тут ни при чём.

Какой переключатель в вашей голове позволил сделать вам такой вывод?

В случае с C++, говно и на входе, не только на выходе.

Сильный аргумент. Паскаль головного мозга.

Единственная «вменяемая» IDE для C++ это Visual Studio.

Да ладно.

На Linux только Netbeans, может быть Eclipse, у JetBrains должно быть. «Вменяемых» IDE на самом C++(кроме VS), не существует.

Даже вы признали, что хоть одна ide, но вменяемая есть. Бедные пасквилянты, жрут лазарус, давятся, но продолжают декларировать мантры.

andreyu ★★★★★
()
Ответ на: комментарий от robus

Пользователь должен знать оптимальные флаги компиляции для своего железа.

А ваша мама знает флаги компиляции приложения, которым она пользуется? :)

andreyu ★★★★★
()
Ответ на: комментарий от anonymous

А вот отправьте Клэнг в живой мир, и посмотрите как будет с реальными пакетами работать.

Все приложения для ios / tvos / os x давно собираются clang'ом. А gcc давно уже даже опцией не идет.

andreyu ★★★★★
()
Ответ на: комментарий от robus

Все студенты обычно тупые. Всё у них буквочки, отступы, begin/end
Нет. Нам подавай лямбды в слотах

Closures(замыкания) в Delphi с 2009 года. Лямбды для C++ предложены только в 2011 году. Обсуждение с инженером их реализовавший в Delphi: http://www.reddit.com/r/programming/comments/6tp3i/pascal_gets_closures_befor...

«лямбды в слотах», это наверное о слотах QT.(у меня нет hidden agenda, я не пользую ни Delphi, ни C++ в той мере что бы становиться их «нашистом»). Слоты в QT реализованы дополнительным(!) компилятором поверх C++ - MOC(Meta-Object System), как замена RTTI(run time type information, инфа о типах на стадии выполнения).

В Delphi и Free Pascal, RTTI как модуль typinfo в стандартной библиотеке. Операторы as и is проверяют тип во время исполнения. В C++ dynamic_cast бросает исключение или возвращает null pointer.

if Sender is TComponent then
tp_for_my_bunghole ★
()
Ответ на: комментарий от anonymous

Да и простой for в C++, мягко говоря, обладает излишней гибкостью.

А то, что порой мне её не хватает и я пишу свои итераторы, это диагноз, да?

Затем, что это более простой и гибкий подход.

Настолько простой, что для него городят «зоопарк из автосрани, смейка, и мейкфайлов на полмегабайта»?

А потом кто-то хочет законтрибьютить в твоё поделие, качает исходники и вместо того, чтобы спокойно собрать проект одной командой, начинает ставить себе нужные либы.

Ещё раз. Разрешение зависимостей - задача не программиста, не языка и уж тем более не конечного пользователя. Эта задача мейнтейнера.

robus ★★★★★
()
Ответ на: комментарий от tp_for_my_bunghole

Closures(замыкания) в Delphi с 2009 года.

Delphi - не существует. Что-то воротят проприетарщики в своём тоталитарном Мордоре, так и пусть воротят дальше. Мне лично до них дела нет совершенно. А вот если бы в fpc были closures, то она была бы дедушкой.

Операторы as и is проверяют тип во время исполнения. В C++ dynamic_cast бросает исключение или возвращает null pointer.

Ну так почему это 

if Sender is TComponent then
лучше чем 
if(dynamic_cast<Component*> (sender()))

robus ★★★★★
()
Ответ на: комментарий от tp_for_my_bunghole

В Delphi и Free Pascal, RTTI как модуль typinfo в стандартной библиотеке. Операторы as и is проверяют тип во время исполнения.

В C++ «include <typeinfo>» и typeid(*p).name()

В итоге возможности не очень отличаются, но include текстовая подстановка, обычно ужасно медленная (ре)компиляция, и т.д.

Из года в год.. Нормальная IDE в TurboPascal была ещё когда первые Windows только разрабатывались.

Но не надо так батхёртить, никто никого ни от чего не отговаривает, и «пересаживаться» не предлагал.

tp_for_my_bunghole ★
()
Ответ на: комментарий от robus

Видимо ваша мама разработчик того приложения, которым пользуется. В противном случае вы лжете.

andreyu ★★★★★
()
Ответ на: комментарий от robus

Ну так почему это

if Sender is TComponent then

лучше чем

if(dynamic_cast<Component*> (sender()))

Это очевидно для тех кто хоть раз работал с генератором парсеров(LALR), что так же связано со сложностью кода в компиляторе. Может очевидно для многих просто визуально.

Нo эквивалент этой C++ строки в Object Pascal будет:

Sender as Component

Как и в C++, бросается исключение, которое надо ловить.

A C++ эквивалент оператора «is» кажется это:

if (typeid(*sender).name().compare("Component") != 0)

Если name() всегда возвращает std::string

tp_for_my_bunghole ★
()
Последнее исправление: tp_for_my_bunghole (всего исправлений: 1)
Ответ на: комментарий от andreyu

А кто мешает вам запилить бенч и проверить?

вот я тоже удивляюсь

KennyMinigun ★★★★★
()
Ответ на: комментарий от gag

А чего это стоило прогописателям да сопровождащим пакетов.

К сожалению, реалии таковы, что множество отличных программ/библиотек написано несопровождаемым говнокодом.

KennyMinigun ★★★★★
()
Ответ на: комментарий от robus

А то, что порой мне её не хватает и я пишу свои итераторы, это диагноз, да?

Для чего, например?

для него городят «зоопарк из автосрани, смейка, и мейкфайлов на полмегабайта»

Это у крестольщиков. У здоровых людей для этого городят пару-тройку простых файлов и специальную прогу.

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

Где я писал, что менеджер зависимостей занимается их разрешением? Он занимается их установкой / поиском в системе. Ну, и сборкой проекта.

Эта задача мейнтейнера.

Ну пусть разрешает. Я что, против?

anonymous
()
Ответ на: комментарий от andreyu

Все приложения для ios / tvos / os x давно собираются clang'ом. А gcc давно уже даже опцией не идет.

И под андроид. Но там в ndk gcc-4.9 пока опцией идёт. Но обещали уже в следующем релизе выкинуть. clang они толком не настроили: куча недоделок, но gcc уже заранее приговорили. Сомнительная компетентность сотрудников гугла, работающих над ndk.

gag ★★★★★
()
Ответ на: комментарий от gag

И под андроид. Но там в ndk gcc-4.9 пока опцией идёт. Но обещали уже в следующем релизе выкинуть. clang они толком не настроили: куча недоделок, но gcc уже заранее приговорили. Сомнительная компетентность сотрудников гугла, работающих над ndk.

Это странно, ведь совсем недавно в NDK появился тулчейн 4.9, а 4.8 был вырезан.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Это странно, ведь совсем недавно в NDK появился тулчейн 4.9, а 4.8 был вырезан.

4.9 был и в r10 (не знаю всех ли выпусков, но точно в r10e, которому вот уже почти год исполнится). А в r11, да, 4.8 удалили, а 4.9 поставили в очередь.

gag ★★★★★
()
Ответ на: комментарий от Lavos

Думаю, как и SSE5, не надо ничего покупать: фирма анонсирует тех документацию - и вперёд. Потом фирма может передумать.

gag ★★★★★
()
Ответ на: комментарий от anonymous

Но предыдущая их операционка была. А Objective-C выглядит более как Паскаль чем С++

anonymous
()
Ответ на: комментарий от tp_for_my_bunghole

Msvs уже давно написана не на c++

anonymous
()
Ответ на: комментарий от tp_for_my_bunghole

Как и в C++, бросается исключение, которое надо ловить.

Это же Qt - там везде указатели. А if(nullptr) всегда false.

Если name() всегда возвращает std::string

if (typeid(*sender).name()=="Component")

Зачем всё усложнять?

robus ★★★★★
()
Ответ на: комментарий от anonymous

Для чего, например?

Фильтровать, например. Перегруженный operator++ перебрасыват на следующий элемент, для которого выполняется условие. Да это можно реализовать на if-ах, но когда их становится слишком много и все они копипастовые..

Это у крестольщиков. У здоровых людей для этого городят пару-тройку простых файлов и специальную прогу.

Да. И прога имеет тип «пакетный менеджер».

Он занимается их установкой / поиском в системе.

А потом в системе тонны библиотек, о корых пакетный менеджер ни сном не духом. Офигенный подарочек, да.

Ну пусть разрешает. Я что, против?

Судя по всему да. Ведь прога, которая ищет в системе и, если нужно, устанавливает библиотеки либо является пакетным менеджером, либо дублирует его функциональность, работая в обход.

robus ★★★★★
()
Ответ на: комментарий от Stahl

Есть такая архитектура, называется msp430. Так вот пишу я под нее один проект, и так получилось что стало не хватать производительности. Взял я и замерил за сколько времени у меня отрабатывает одна итерация логики:
родной компилятор TI: 40мкс
gcc 5.1 : 31мкс
триал версия IAR: 17мкс
уже думал придется мучатся с IAR, но решил ради интереса проверить clang. там поддержка msp совсем эксперементальная, даже линкера нет, нужно генерить ассемблер и компилить его gcc. Но результат получился 15мкс. а это 2x прирост в произоводительности относительно gcc. даже IAR медленнее.
Потом я сравнил код и нашел что gcc вставляет везде лишние zero extend, на багзиле уже два года висит этот баг и никто не собирается его фиксить и в коде разработчик оставил коментарий что сам не знает откуда они там берутся. вот и вся суть gcc. сейчас готовлю патч в clang, потому что добавить в него нужную мне фичу оказалось проще чем найти непонятный баг в gcc.

pftBest ★★★★
()
Ответ на: комментарий от mashina

Я всё же предпочитаю 

dynamic_cast<Component*>(sender())
ведь если идёт отбор на то, является ли sender компонентом, то и использоваться он будет не как QObject, а как компонент. Т.е. 
Component *comp = dynamic_cast<Component*>(sender());
if(comp)
  {
     //Делаем что-то с компонентом comp
  }
Но теперь я знаю, что если уж впёрся зачем-то typeid, то

Использовать name() для сравнения типа нельзя.

robus ★★★★★
()
Последнее исправление: robus (всего исправлений: 1)
Ответ на: комментарий от robus

Это же Qt - там везде указатели. А if(nullptr) всегда false.

dynamic_cast может бросать исключение std::bad_cast.

Зачем всё усложнять?

Хороший вопрос для QT, где дополнительный копилятор MOC поверх C++.

tp_for_my_bunghole ★
()
Ответ на: комментарий от tp_for_my_bunghole

dynamic_cast может бросать исключение std::bad_cast

Только на ссылках. На указателях просто nullptr выдаёт.

копилятор MOC

Он не компилятор, а генератор кода.

robus ★★★★★
()
Ответ на: комментарий от mashina

Использовать name() для сравнения типа нельзя, можно только так

typeid(*sender) == typeid(Component)

Да, потому что std::type_info::name() implementation defined, везде по своему.

Но typeid() бросает исключение std::bad_typeid если аргумент в виде *t, a t нулевой указатель. Но аргумент может быть без оператора *, просто t, и в этом случае бросать исключение или нет, различается в компиляторах. Implementation defined.

dynamic_cast может бросать исключение std::bad_cast в зависимости от вида аргумента.

В Java стандарте есть checked exceptions, компилятор видит где бросаются исключения(throws) и требует добавлять обработчики для этого.

В Object Pascal оператор as не бросает исключение если object нулевой указатель: 

object as SomeClass
object as SomeInterface

Eсли типы несовместимы(Object не находится в иерархии Class или приводимый тип ниже в иерархии чем object), то бросает исключение EInvalidCast. Потому рекомендуется использовать проверку перед этим: 

if Object is SomeClass then

tp_for_my_bunghole ★
()
Последнее исправление: tp_for_my_bunghole (всего исправлений: 1)
Ответ на: комментарий от tp_for_my_bunghole

Но аргумент может быть без оператора *, просто t, и в этом случае бросать исключение или нет, различается в компиляторах. Implementation defined.

typeid() хочет glvalue и обязан вернуть ссылку на type_info, а ссылка в плюсах не может быть на несуществующий объект. Собственно по этой причине typeid(*ptr_with_null) может кинуть исключение. Без указателей исключений быть не должно.

dynamic_cast может бросать исключение std::bad_cast в зависимости от вида аргумента.

Тоже самое касается и dynamic_cast, т.е.если идёт каст ссылки, то исключение может быть, но если указателя - нет. Обычно как раз пользуются кастом указателей и никакие исключения ловить не нужно.

mashina ★★★★★
()
Ответ на: комментарий от robus

Фильтровать, например.

Посмотри boost::range.

в системе тонны библиотек, о корых пакетный менеджер ни сном не духом

Нет. Они качаются либо в хомяк в специальный каталог, либо юзаются установленные тобой.

прога, которая ищет в системе и, если нужно устанавливает библиотеки

Нет. Она устанавливает, если ты ей это скажешь. Ничего не мешает мэйнтейнеру самому установить либы и собирать с ними.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 →
GNU's Not Unix