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

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

Ok. Посмотрю.

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

И ничего, что для библиотек есть /usr/lib и /usr/include, а за всем установленным барахлом пакетный менеджер следит. Продублируем его функциональность, попутно засрав хомяк. Экселент айдиа!

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

Ну, так если мейнтейнер это сделал, получается дублирование функциональности. Итого: в лучшем случае вся эта софистицированная система бесполезна, в худшем - вредна.

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

пакетный менеджер

Причём уже даже у виндузятников есть — dism.exe.

anonymous
()

Благодаря libclang и cmake-ide вместе с rtags, Emacs стал полноценным C++ IDE. Распарсить такой анти язык может только сам компилятор в специальном режиме.

RTags на C++ компилируется долго для относительно небольшой программы. Многодекамегабайтный Lazarus на Free Pascal компилируется за 1.5 минуты первый раз.

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

И ничего, что для библиотек есть /usr/lib и /usr/include

А ещё /lib, /usr/local/lib и /opt. Срочно расстрелять этих дубляторов из FHS! Ein каталог, ein пакетный менеджер, ein ЯП!

попутно засрав хомяк

Я даже не знаю, что ответить. У тебя что, места на хомяке нет? Или ты не слышал про rm?

Продублируем его функциональность

Dry-фанатизм - это диагноз. Да и не везде пакетный менеджер есть.

в лучшем случае вся эта софистицированная система бесполезна, в худшем - вредна

В худшем случае она позволяет создать build environment на любой ОС одной командой, в лучшем - автоматически проверить наличие и версии установленных библиотек. Какая мерзкая система.

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

Ein каталог, ein пакетный менеджер, ein ЯП!

Вот именно, что не ein. Был бы единственный пакетный менеджер, можно было бы реализовывать через него. Но их много. И дистрибутивов много. И в каждом библиотеки называются по своему.

В худшем случае она позволяет создать build environment на любой ОС одной командой

В обход нативных механизмов этой ОС. Благодарные пользователи плачут от счастья (и приговаривают: «Ах ты ирод, зачем ты так?»).

Да и не везде пакетный менеджер есть.

Везде.

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

Его реализовать элементарно

Не нужно, я уже нашел. Впрочем, юзать всё равно неудобно, либо бойлерплейт вида:

for (auto t: boost::combine(v, l)) {
    int ti;
    char tc;
    boost::tie(ti, tc) = t;
    std::cout << '(' << ti << ',' << tv << ')' << '\n';
}

либо несколько меньший бойлерплейт, но на костылях:

int ti;
char tc;
BOOST_FOREACH(boost::tie(ti, tc), boost::combine(v, l))
{
    std::cout << '(' << ti << ',' << tv << ')' << '\n';
}

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

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

И в каждом библиотеки называются по своему.

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

В обход нативных механизмов этой ОС.

И чо?

Везде.

Покажи пакетный менеджер в семёрочке максимальной.

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

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

Ещё разок. От разраба нужен только make файл. Остальное дело мейнтейнера.

Покажи пакетный менеджер в семёрочке максимальной.

Ни за что не поверю, что в Debian 7 не завезли dpkg.

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

Ещё разок. От разраба нужен только make файл. Остальное дело мейнтейнера.

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

Ни за что не поверю, что в Debian 7 не завезли dpkg.

Я про оффтопик.

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

В твоем юзкейсе тебе вообще не нужен tie, не зачем выдумывать несуществующие проблемы типа того, что сделано не так как в питоне

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

не зачем выдумывать несуществующие проблемы типа того, что сделано не так как в питоне

«Сделано не как в питоне» - это не проблема. Проблема - это «сделано значительно более вербозно/менее удобно, чем питоне».

anonymous
()

Госпада! Ричард Столлман призывает всех вас заткнуться. Также, господин Столлман призывает всех вас идти лесом.

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

Госпада! Ричард Столлман призывает всех вас заткнуться. Также, господин Столлман призывает всех вас идти лесом.

Нет. Он промолчал и вообще не понял о чём здесь, потому что никто не упоминал лицензии.

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

О да, а потом выясняется, что бинари которые он там насобирал(egg в python) слинкованы с какой-то мутью, которой в системе нет. В другом же случае он начинает этот «умный пакетный менеджер» начинает это компилять, также не особо заботясь о прямых зависимостях. Соответственно «замечаельный пакетный менеджер» хорош, когда биндинги писать не надо. «Зато кросплатформенно» (По костылю на каждую платформу)

anonymous
()

Линус уже высказал свое мнение о ментальном здравии разработчиков gcc 6.1?

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

Я про оффтопик.

Кого волнуют проблемы оффтопика? Мы вообще на сайте linux.org.ru и разговоры тут о GNU/Linux в частности и Unix-подобных системах в целом.

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

Вопрос, очевидно, происходит от незнания того, почему ветки Debian называются stable и unstable.

Ветка unstable - это не потому что там софт нестабильный, глючный и вечно падающий, а потому что ветка всё время меняется, так как апдейтятся пакеты. Соответственно, ветка stable почти не меняется, приходят только обновления безопасности, поэтому софт там может быть очень старым.

Иными словами, под стабильностью в данном случае имеется в виду неизменяемость репозитория, а не качество софта в этом репозитории.

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

А для нестабильного софта есть ветка experimental.

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

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

Не меняются major-версии, сама «ветка» вполне себе меняется - новые пакеты прилетают спокойно.

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

Объяснил: «приходят только обновления безопасности».

Хватит буквоедствовать, может? По основной мысли, надеюсь, возражений нет?

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

Хватит буквоедствовать, может?

А может, нет? С херали мне не буквоедствовать на моём лоре?

По основной мысли, надеюсь, возражений нет?

А они были?

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

Линус уже высказал свое мнение о ментальном здравии разработчиков gcc 6.1?

Линусу плевать на FSF. Он прикупил парочку акций Красной_Шляпы.

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

Понятия не имею. Люди часто делают нерациональные действия, отталкиваясь от своих религиозных, социальных или иных не имеющих отношения к делу взглядов.

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

Почему же тогда Clang заменил GCC на многих дистрибутивах?

А можно поподробней, или это жирный вброс?

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

я тоже не силён в практике выпуска железа. Но любая бабка в платке уже знает, что 21м веке чёткие пацаны пишут софт задолго до появления рабочего прототипа чипа, и до всяких FPGA прототипов. Ко-верификация софта/харда.

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