Comments 46
Аккуратнее с новым TLS в GCC — это не то же самое, что и старый __thread. Там есть runtime cost при каждом обращении, по крайней мере в текущей версии. Лучше использовать старую версию там, где возможно.
Вот блин! Спасибо, что сказали, я пока только собирался TLS использовать.
Пока использовал все что попроще — for, auto, lambdas, override/final, variadic в либах, atomic.
Вот хочу еще «подсесть» на thread-local и constexpr.
Пока использовал все что попроще — for, auto, lambdas, override/final, variadic в либах, atomic.
Вот хочу еще «подсесть» на thread-local и constexpr.
Вот тут подробнее про runtime cost и его причину. Там же предлагается решение, если thread_local используется как __thread:
If the programmer can be sure that no use of the variable in a non-defining TU needs to trigger dynamic initialization (either because the variable is statically initialized, or a use of the variable in the defining TU will be executed before any uses in another TU), they can avoid this overhead with the -fno-extern-tls-init option.
constexpr это как раз та вещь из C++11, которой пока нельзя полноценно пользоваться — поддержка в MSVC неполная.
Так, обновил значения поддержки Intel до 15 версии, обновил ссылки, две колонки MSVC слил в одну (мне кажется, так читать удобнее).
Просто отличная статья!
А то периодически читаешь про эти «вкусные» возможности нового стандарта и прямо строишь планы, как начнешь их использовать. А потом оказывается, что на серверах, на которых ты собираешься программы гонять, ничего из этого не работает. С таблицей хотя бы видно, на что рассчитывать можно.
А то периодически читаешь про эти «вкусные» возможности нового стандарта и прямо строишь планы, как начнешь их использовать. А потом оказывается, что на серверах, на которых ты собираешься программы гонять, ничего из этого не работает. С таблицей хотя бы видно, на что рассчитывать можно.
Спасибо, уважаемый однофамилец =)
Я вдохновлялся идеей сайта caniuse.com. Хотелось бы конечно, что-то в таком роде иметь. А еще подумываю о том, как бы эту табличку попроще поддерживать было… С другой стороны, новые релизы компиляторов не так часто выходят. Но если замахиваться на вариант с cppreference, то, конечно надо думать об автоматике.
Я вдохновлялся идеей сайта caniuse.com. Хотелось бы конечно, что-то в таком роде иметь. А еще подумываю о том, как бы эту табличку попроще поддерживать было… С другой стороны, новые релизы компиляторов не так часто выходят. Но если замахиваться на вариант с cppreference, то, конечно надо думать об автоматике.
Ну, вообще выражаясь весьма грубо — C++11 уже можно использовать на всех стабильных версиях основных компиляторов на рынке.
И, в дополнение, уже можно использовать примерно половину возможностей C++14 в случае использования тестовых и dev-веток (естественно о поддержки всех компиляторов в библиотеках, например, говорить рано).
И, в дополнение, уже можно использовать примерно половину возможностей C++14 в случае использования тестовых и dev-веток (естественно о поддержки всех компиляторов в библиотеках, например, говорить рано).
Понимаете, в чем дело. Я вот специально проверил сейчас версию gcc на разных серверах, используемых для моих вычислений (физика элементарных частиц). Там очень часто встречается gcc4.6. Соответственно, слепо использовать все подряд я никак не могу.
И, думаю, это далеко не единственный пример, когда программист сталкивается с ограничениями.
И, думаю, это далеко не единственный пример, когда программист сталкивается с ограничениями.
Ну, если Вы ориентируетесь только на ОДИН компилятор, на GCC, то лучше уж тогда не по таким таблицам вроде моей смотреть, а прямо на странице (ссылка внизу поста). Там еще и комментарии есть =)
А вообще, конечно, я с Вами и не спорил.
А вообще, конечно, я с Вами и не спорил.
А вы не можете поставить более новый компилятор сами в home? У меня в универе вообще 4.4, я поставил себе 4.9, а то многие программы и библиотеке на таком старье не компилируются.
Лично я могу. Но когда пишешь программу, которой пользуешься не только ты сам, надо как-то приспосабливаться под различные реалии. Как-то так складывается, что большинство физиков, использующих мои программы, не слишком сведущи в деталях и не возьмутся ставить компилятор и устанавливать дополнительные пакеты.
git pull и make — это почти предел
(если что, речь о вещах вроде этой: bitbucket.org/feynmanIntegrals/fiesta)
git pull и make — это почти предел
(если что, речь о вещах вроде этой: bitbucket.org/feynmanIntegrals/fiesta)
Я вас очень хорошо понимаю, самого это останавливает. Хотя для личных программ я пользуюсь новыми возможностями.
А что сложного в том, чтобы просто дать им готовый компилятор? Chromium, например, собирается clang'ом, бинарник которого он вытаскаивает и распаковывает автоматом, GCC тоже можно так подготовить.
Там с библиотеками, правда, проблемы: по хорошему нужно бы сделать libstdc++-аддон, который бы содержал в себе функции, которые есть в GCC 4.7+, а «старые» функции брал бы из libstdc++.so. Там нетривиальное количество работы, но за несколько дней, думаю, можно изобразить…
Там с библиотеками, правда, проблемы: по хорошему нужно бы сделать libstdc++-аддон, который бы содержал в себе функции, которые есть в GCC 4.7+, а «старые» функции брал бы из libstdc++.so. Там нетривиальное количество работы, но за несколько дней, думаю, можно изобразить…
Ну вот видите ) еще один повод комментировать на Хабре — Вы мне сейчас подскзали хорошее направление для развития )
Проще уж взять и поставить (собрать) clang и линковаться соответственно с libc++? Ее можно с собой как обычную библиотеку таскать и она ничего не поломает.
Она не даст вам возможности использовать ваше поделие совместно с другими библиотеками. А они встречаются у разных физиков достаточно часто.
Ссылка на С++ 14 битая.
Вот тут https://gcc.gnu.org/gcc-5/changes.html можно найти более подробное описание новшеств в GCC 5. В частности, из того что упущено в таблице, там появятся:
— feature testing macros
— typename in a template template parameter
— feature testing macros
— typename in a template template parameter
Спасибо. Я написал в статье, что МОГУТ БЫТЬ неточности. Уж не знаю как еще прозрачнее можно намекнуть, что с исправляшками — в личку. Я-то обновил, а Ваш комментарий теперь увековечен =)
Зато теперь все читатели будут знать, где посмотреть новые возможности следующей версии GCC. А их довольно много. В частности, наконец то реализация std::list будет соответствовать стандарту.
Хорошо, я тоже люблю бонусы в комментариях, но пост все же обновил этой ссылкой.
В частности, наконец то реализация std::list будет соответствовать стандарту.Что, в свою очередь, обозначает, что std::list из GCC5 несовместим с std::list из GCC4, то есть ещё долгие годы мы будем вынуждены использовать только возможности GCC 4.9.
Тоже полезная информация.
что, простите? Настолько я помню, list::size() будет теперь не за линейное время возвращать результат, а за константное. Это большая проблема для пользователей класса?
Это требует хранить размер в самом объекте списка, и следовательно, требует изменения ABI. То есть вы не сможете линковаться с библиотеками, откомпилированными старой версией компилятора (если будете передавать списки).
Какой ужас! Это же первое изменение ABI GCC в истории! Что ж мы раньше-то делали!
Нет, серьезно, как разработчик, который поддерживает gcc 3.4, 4.1 и 4.8 одновременно, я не вижу в этом большой беды.
Речь шла про «ещё долгие годы мы будем вынуждены использовать только возможности GCC 4.9.». По-моему, это сгущение.
Нет, серьезно, как разработчик, который поддерживает gcc 3.4, 4.1 и 4.8 одновременно, я не вижу в этом большой беды.
Речь шла про «ещё долгие годы мы будем вынуждены использовать только возможности GCC 4.9.». По-моему, это сгущение.
Все эти изменения ABI приносит много боли, так что Вы зря. Я не так давно столкнулся с проблемой функции memcpy в старом дистре линуха, которая требовала glibc 2.2.5. Косяк в том, что в версии 2.14 произошло несовместимое обновление этой функции, а это значит, что простейшее приложение, откомпиленное на новых библиотеках, без грязных хаков никак не будет работать на старых библиотеках.
Для этого есть LSB. Просто выберите версию LSB, которая вам нужна — и ваша программа сошлётся на те символы, которые данная версия LSB поддерживает.
Есть только одна проблема: если вам нужна только libc или какие-нибудь распространённые библиотеки типа gtk — то эта вся конструкция работает, но как только ваша программа хочет «странного» (ну там HTMLку показать или, прости господи, бибикнуть) — так и всё: ничего этого в LSB нету.
Но как proof-of-concept — оно работает.
Есть только одна проблема: если вам нужна только libc или какие-нибудь распространённые библиотеки типа gtk — то эта вся конструкция работает, но как только ваша программа хочет «странного» (ну там HTMLку показать или, прости господи, бибикнуть) — так и всё: ничего этого в LSB нету.
Но как proof-of-concept — оно работает.
LSB идет со старыми версиями gcc. Пока все нужное соберешь, вариант окажется не лучше, чем взять целевой Linux и собрать под ним. Ну или я что-то не понимаю.
Вы всё правильно понимаете. До ума это доведено, скажем, в Android'ном NDK: вы можете совершенно спокойно собирать в нём приложение используя GCC 4.9, а запускать потом… ну, например, на Android 2.3.
Но поскольку разработчикам GNU/Mess'а и в голову не приходило, что кто-то может иметь наглость выпускать библиотеки не в виде исходников, то ничего подобного в LSB сделать не удалось. LSB — это такой себе «полуSDK»: часть библиотек — обратно совместима, часть (причём чувствительная часть) — отсутствует как класс.
Как я уже говорил: скорее proof-of-concept, чем вещь, которую можно реально использовать. Но сослаться на memcpy@GLIBC_2.4 можно легко :-)
Но поскольку разработчикам GNU/Mess'а и в голову не приходило, что кто-то может иметь наглость выпускать библиотеки не в виде исходников, то ничего подобного в LSB сделать не удалось. LSB — это такой себе «полуSDK»: часть библиотек — обратно совместима, часть (причём чувствительная часть) — отсутствует как класс.
Как я уже говорил: скорее proof-of-concept, чем вещь, которую можно реально использовать. Но сослаться на memcpy@GLIBC_2.4 можно легко :-)
Это же первое изменение ABI GCC в истории!Нет, не первое. Пятое. Предыдущее случилось больше десяти лет назад, когда вышел GCC 3.4. И, надо вам сказать, это был тот ещё геморой: несколько лет приходилось выпускать всякие библиотеки в двух версиях и, соответственно, писать их приходилось так, чтобы они обязательно собирались как GCC 3.3, так и GCC 3.4+.
Нет, серьезно, как разработчик, который поддерживает gcc 3.4, 4.1 и 4.8 одновременно, я не вижу в этом большой беды.Все три названные версии — это libstdc++.so.6 с совместимостью «сверху вниз». Вы можете собрать библиотеку GCC 3.4, слинковать её с библиотекой, собранной GCC 4.9 — и всё будет работать. При должном применении напильника. Иногда бывают кой-какие шероховатости, да, но в целом — это совсем не то, что случилось при переходе с GCC 3.3 на GCC 3.4 и случится при переходе на GCC5. Тут вы даже std::string передать не сможете из одной библиотеки в другую — только через C-shim.
Речь шла про «ещё долгие годы мы будем вынуждены использовать только возможности GCC 4.9.». По-моему, это сгущение.Если бы. С++ библиотеки, собранные с GCC 4.x нельзя толком использовать с GCC 5, потому если вы захотите их использовать, то для вас «потолком» будет GCC 4.9. Потому разработчики так и тянули с переходом, откладывали как могли этот момент и только после того, как реализовали более-менее полностью C++ в GCC 4.9 решились-таки сломать совместимость.
Нет, не первое. Пятое
я знаю. /sarcasm.
Вы можете собрать библиотеку GCC 3.4, слинковать её с библиотекой, собранной GCC 4.9
Хм, я что-то не пробовал так заморачиваться. Я линкую все в пределах одной версии, не особо надеясь на совместимось. Для меня нет в этом большой головной боли (все равно на target-окружениях будут разные версии рантайма).
Я вообще может какой-то неправильный человек, который не видит вообще проблемы в том чтобы собрать под два компилятора. Или под пять. Пять сборок. Наверное, потому что я не разработчик WebKit-а, и мне не надо сутки ждать сборки. Может быть, поэтому.
Не в тему, но я еще до сих пор все проекты под Qt 4 и под Qt 5 собираю и не запариваюсь.
Не в тему, но я еще до сих пор все проекты под Qt 4 и под Qt 5 собираю и не запариваюсь.
Проблема-то не в том, что вы не можете собрать под два компилятора, а в том, что не все это будут делать. Вот захотите вы использовать вкусняшки из C++14/17 в проекте с какой-нибудь проприетарной библиотекой, а не получится: вкусняшки только с gcc 5.0, а библиотека собрана gcc 4.
Я вот просто перепрыгнул на clang+libc++ и вкусняшек стало много и работает хорошо. Но у меня нет зависимости от других библиотек, которым нужен stdlibc++. В противном случае действительно приходит боль и страдание.
Аа) ладно, всё, я понял Вас! Я просто обычно и есть тот самый «проприетарный» разработчик и от других проприетарных как-то не завишу (т.е. я могу пересобрать все что мне нужно (вплоть до ядра и компилятора)). Простите, посмотрел со своей колокольни!
Там есть некоторые нюансы, если нужна бинарная совместимость между C++98 и C++11 кодом: gcc.gnu.org/wiki/Cxx11AbiCompatibility
Можно слезть на libc++, и там изначально новое ABI и ставится она даже на совсем дремучие системы.
Там не только списки поменялись. Также изменены std::string'и и ещё много чего. Скорее всего будет libstdc++.so.7 со всеми вытекающими.
Где же выделение цетом? Очень не хватает. Просто взгляните, какая красота: blogs.msdn.com/b/vcblog/archive/2014/06/11/c-11-14-feature-tables-for-visual-studio-14-ctp1.aspx
И сразу будет наглядно, какие фичи более популярны и какие компиляторы обеспечивают поддержку большинству фичей.
И сразу будет наглядно, какие фичи более популярны и какие компиляторы обеспечивают поддержку большинству фичей.
Ещё бы они цвета правильно расставляли. Часть этого «зелёного» на самом деле «жёлтое», и это как в core language features, так и в library…
Например, попробуйте вызвать конструктор через {} в списке инициализации. Внезапно вылезет вот это.
Например, попробуйте вызвать конструктор через {} в списке инициализации. Внезапно вылезет вот это.
Интересно, может ли кто-нибудь расширить таблицу информацией по Sun/Oracle Forte C++ Compiler? Судя по анонсам на сайте производителя, продукт по-прежнему развивается.
Sign up to leave a comment.
Сводная таблица по поддержке C++ 11/14/17