Сводная таблица по поддержке C++ 11/14/17

    Как любому C++ разработчику, следящему за новинками в отрасли и стандартами в частности, мне стало интересно, насколько полно вообще поддерживается стандарт C++ 11 (а также 1y и 1z) разными компиляторами? Да, существуют разные сводные таблицы, но чаще всего это сравнение двух компиляторов или двух версий одного компилятора, либо сводная таблица, но уже устаревшая, либо вообще неполный список. В общем, сел я да и сделал полную таблицу (на основе списка Clang-a и GCC) по четырем компиляторам: Clang, GNU C++, MSVC и Intel C++.
    Внимание! Данная таблица прежде всего предназначена для тех, кто пишет свой продукт. Если Вы разрабатываете библиотеку, то, естественно, лучше ознакомиться с особенностями поддержки в первоисточнике (а еще лучше на все тесты написать). Для меня она прежде всего нужда для решений вроде «О! Range-for можно уже использовать без проблем.».
    Часть стандарта C++11 Proposal Clang GCC VC Intel C++
    C++ 11
    Rvalue references N2118 2.9 4.3 10.0 — 13.0 12.0
        Rvalue references for *this N2439 2.9 4.8.1 13.0 14.0
    Initialization of class objects by rvalues N1610 2.9 4.0   11.1
    Non-static data member initializers N2756 3.0 4.7 12.0 — ? 14.0
    Variadic templates N2242 2.9 4.3 11.1 12.0
        Extending variadic template template parameters N2555 2.9 4.4 12.0 12.0
    Initializer lists N2672 3.1 4.4 11.1 — ? 13.0
    Static assertions N1720 2.9 4.3 10.0 11.0
    auto-typed variables N1984 2.9 4.4 10.0 11.0
        Multi-declarator auto N1737 2.9 4.4 10.0 12.0
        Removal of auto as a storage-class specifier N2546 2.9 4.4 10.0 11.0
        New function declarator syntax N2541 2.9 4.4 10.0 12.1
    Lambda expressions N2927 3.1 4.5 10.0 — 11.0 12.0
    Declared type of an expression N2343 2.9 4.3 10.0 — 11.0 11.0
        Incomplete return types N3276 3.1 4.8.1 12.0 12.0
    Right angle brackets N1757 2.9 4.3 10.0 11.0
    Default template arguments for function templates DR226 2.9 4.3 12.0 12.6
    Solving the SFINAE problem for expressions DR339 2.9 4.4   12.6
    Alias templates N2258 3.0 4.7 12.0 12.6
    Extern templates N1987 2.9 4.0 10.0 9.0
    Null pointer constant N2431 3.0 4.6 10.0 12.1*
    Strongly-typed enums N2347 2.9 4.4 10.0 — 11.0 12.0
    Forward declarations for enums N2764 DR1206 3.1 4.6 11.0 14.0
    Standardized attribute syntax N2761 3.3* 4.8   12.1
    Generalized constant expressions N2235 3.1 4.6 13.0 — ? 13.0
    Alignment support N2341 3.3 4.8 10.0 — 13.0 15.0
    Conditionally-support behavior N1627 2.9      
    Changing undefined behavior into diagnosable errors N1727 2.9      
    Delegating constructors N1986 3.0 4.7 12.0 14.0
    Inheriting constructors N2540 3.3 4.8 13.0 15.0
    Explicit conversion operators N2437 3.0 4.5 11.1 13.0
    New character types N2249 2.9 4.4 13.0 14.0
    Unicode string literals N2442 3.0 4.5 13.0 11.0*
    Raw string literals N2442 3.0 4.5 11.1 14.0
    Universal character names in literals N2170 3.1 4.5   12.6
    User-defined literals N2765 3.1 4.7 13.0 15.0
    Standard Layout Types N2342 3.0 4.4 11.0 14.0
    Defaulted functions N2346 3.0 4.4 12.0 12.0
    Deleted functions N2346 2.9 4.4 12.0 12.0
    Extended friend declarations N1791 2.9 4.7 10.0 11.0
    Extending sizeof N2253 DR850 3.1 4.4 13.0 14.0
    Inline namespaces N2535 2.9 4.4 13.0 14.0
    Unrestricted unions N2544 3.1 4.6 13.0 14.0*
    Local and unnamed types as template arguments N2657 2.9 4.5 10.0 12.0
    Range-based for N2930 3.0 4.6 11.0 13.0
    Explicit virtual overrides N2928 N3206 N3272 3.0 4.7 10.0 — 11.0 12.0*
    Minimal support for garbage collection
    and reachability-based leak detection
    N2670 N/A N/A 10.0 15.0*
    Allowing move constructors to throw [noexcept] N3050 3.0 4.6 13.0 14.0
    Defining move special member functions N3053 3.0 4.6   14.0
    C++ 11 — Concurrency
    Sequence points N2239 3.3 4.0 N/A 15.0
    Atomic operations N2427 3.1 4.4 11.0 13.0
    Strong Compare and Exchange N2748 3.1* 4.5 11.0 13.0
    Bidirectional Fences N2752 3.1 4.8 11.0 13.0
    Memory model N2429 3.2 4.8 N/A 15.0*
    Data-dependency ordering: atomics and memory model N2664 3.2* 4.4 11.0 — ? 15.0
    Propagating exceptions N2179 2.9 4.4 10.0 12.0
    Abandoning a process and at_quick_exit N2440   4.8 13.0 15.0*
    Allow atomics use in signal handlers N2547 3.1 4.0   15.0*
    Thread-local storage N2659 3.3 4.8 10.0 — 13.0 15.0*
    Dynamic initialization and destruction with concurrency N2660 2.9 4.3 13.0 11.0*
    C99 Features in C++11
    __func__ predefined identifier N2340 2.9 4.3 10.0 — 13.0 11.0
    C99 preprocessor N1653 2.9 4.3 10.0 — ? 11.1
    long long N1811 2.9 4.3 10.0 9.0
    Extended integral types N1988 N/A 4.0 N/A 15.0*
             
    C++14
    Tweak to certain C++ contextual conversions N3323 3.4 4.9 12.0  
    Binary literals N3472 2.9 4.9 13.0 11.0
    decltype(auto) N3638 3.3 4.8 13.0 15.0
    Return type deduction for normal functions 3.4 4.9 13.0  
    Initialized lambda captures N3648 3.4 4.9 13.0 15.0
    Generic lambdas N3649 3.4 4.9 13.0  
    Variable templates N3651 3.4 5.0    
    Relaxing requirements on constexpr functions N3652 3.4 5.0    
    Member initializers and aggregates N3653 3.3 5.0    
    Clarifying memory allocation N3664 3.4 N/A    
    [[deprecated]] attribute N3760 3.4 4.9   15.0*
    Single quotation mark as digit separator N3781 3.4 4.9 13.0  
    C++ Sized Deallocation N3778 3.4 No 13.0  
               
    C++ 1z
    static_assert with no message N3928 3.5      
    Disabling trigraph expansion by default N4086 3.5   13.0  
    typename in a template template parameter N4051 3.5 5.0    
    New auto rules for direct-list-initialization N3922 No      
    Fold expressions N4295 SVN      
    u8 character literals N4267 SVN      
    Nested namespace definition N4230 SVN      
    Attributes for namespaces and enumerators N4266 SVN      
    Allow constant evaluation for all non-type template arguments N4268 SVN      
               
    Черновики (Drafts)
    SD-6: SG10 feature test recommendations SD-6 3.4 5.0    
    SVN      
    [DRAFT TS] Array extensions (arrays of runtime bound) N3820 No 4.9    
    [DRAFT TS] Library fundamentals (invocation type traits) N3908 No      
    [DRAFT TS] Concepts N3929 No Yes**    
    Примечания.
    • В таблице могут быть неточности, ибо составлялась она, по большей части, вручную;
    • Не указана поддержка возможностей стандартной библиотеки (добавлю по настоятельной просьбе) ;
    • * означает, что есть нюансы (хотя поддержка полная). Например, опция командной строки — читайте первоисточники;
    • No — возможность ПОКА не поддерживается;
    • N/A — возможность поддержать нельзя или вообще просто не планируется;
    • Для MSVC указан диапазон в случае, когда есть две версии с Partial support и с Full support. Если Full support до сих пор не объявлен, второе значение после диапазона — знак вопроса;
    • ** GCC Concepts Lite ветка.

    Ссылки.
    1. CLang C++ 11/14/17
    2. GCC: таблица C++ 11, таблица C++ 14, список улучшений, которые добавят в GCC 5
    3. Актуальный на 2012 год список ссылок от Скотта Мейерса
    4. MSVS 2013 C++ 11, C++ 14
    5. Intel C++ 11
    6. Поздно нашел — Таблица (идентичная ей английская версия) с поддержкой множества разных компиляторов, только список неполный (40 из 80 представленных здесь).

    Дополнительная литература:
    1. Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14 (ссылка на издательство). Скотт Мейерс — Эффективный современный С++ (С++11/14)
    2. A tour of C++ — Bjarne Stroustrup


    P.S. И да, естественно, не стоит никаких делать выводов о превосходстве одного компилятора над другим. У каждого из представленных в таблице есть свои киллер-фичи и области применения. Впрочем, вряд ли для серьезного проекта будет рассматриваться компилятор только по количеству «синтаксических плюшек» (утрируя). Будьте разумны!

    UPD: Судя по результатам опроса (предсказуемо), большинство считает, что по STL информация нужна. Слегка изучив этот вопрос, я понял что составить аналогичное сравнение уйдет не час и не два. Так что я сделаю это если дойдут руки, и в таком случае просто изменю заголовок на ("… и STL"). У кого топик будет в закладках, будут знать, что информация обновлена.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 47

      +6
      Аккуратнее с новым TLS в GCC — это не то же самое, что и старый __thread. Там есть runtime cost при каждом обращении, по крайней мере в текущей версии. Лучше использовать старую версию там, где возможно.
        0
        Вот блин! Спасибо, что сказали, я пока только собирался TLS использовать.
        Пока использовал все что попроще — for, auto, lambdas, override/final, variadic в либах, atomic.
        Вот хочу еще «подсесть» на thread-local и constexpr.
          +1
          Вот тут подробнее про 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.
            0
            constexpr это как раз та вещь из C++11, которой пока нельзя полноценно пользоваться — поддержка в MSVC неполная.
          +1
          Так, обновил значения поддержки Intel до 15 версии, обновил ссылки, две колонки MSVC слил в одну (мне кажется, так читать удобнее).
            +4
            Просто отличная статья!
            А то периодически читаешь про эти «вкусные» возможности нового стандарта и прямо строишь планы, как начнешь их использовать. А потом оказывается, что на серверах, на которых ты собираешься программы гонять, ничего из этого не работает. С таблицей хотя бы видно, на что рассчитывать можно.
              +1
              Спасибо, уважаемый однофамилец =)
              Я вдохновлялся идеей сайта caniuse.com. Хотелось бы конечно, что-то в таком роде иметь. А еще подумываю о том, как бы эту табличку попроще поддерживать было… С другой стороны, новые релизы компиляторов не так часто выходят. Но если замахиваться на вариант с cppreference, то, конечно надо думать об автоматике.
                +2
                Ну, вообще выражаясь весьма грубо — C++11 уже можно использовать на всех стабильных версиях основных компиляторов на рынке.
                И, в дополнение, уже можно использовать примерно половину возможностей C++14 в случае использования тестовых и dev-веток (естественно о поддержки всех компиляторов в библиотеках, например, говорить рано).
                  +1
                  Понимаете, в чем дело. Я вот специально проверил сейчас версию gcc на разных серверах, используемых для моих вычислений (физика элементарных частиц). Там очень часто встречается gcc4.6. Соответственно, слепо использовать все подряд я никак не могу.
                  И, думаю, это далеко не единственный пример, когда программист сталкивается с ограничениями.
                    +1
                    Ну, если Вы ориентируетесь только на ОДИН компилятор, на GCC, то лучше уж тогда не по таким таблицам вроде моей смотреть, а прямо на странице (ссылка внизу поста). Там еще и комментарии есть =)
                    А вообще, конечно, я с Вами и не спорил.
                      0
                      Сорри ) Почему-то решил, что это комментарий кого-то еще с краткой сводкой и мыслью, что таблицы не нужны )
                      А так пока gcc, но кто знает, надо думать о разных вариантах…
                      0
                      А вы не можете поставить более новый компилятор сами в home? У меня в универе вообще 4.4, я поставил себе 4.9, а то многие программы и библиотеке на таком старье не компилируются.
                        0
                        Лично я могу. Но когда пишешь программу, которой пользуешься не только ты сам, надо как-то приспосабливаться под различные реалии. Как-то так складывается, что большинство физиков, использующих мои программы, не слишком сведущи в деталях и не возьмутся ставить компилятор и устанавливать дополнительные пакеты.
                        git pull и make — это почти предел

                        (если что, речь о вещах вроде этой: bitbucket.org/feynmanIntegrals/fiesta)
                          +2
                          Я вас очень хорошо понимаю, самого это останавливает. Хотя для личных программ я пользуюсь новыми возможностями.
                            +1
                            А что сложного в том, чтобы просто дать им готовый компилятор? Chromium, например, собирается clang'ом, бинарник которого он вытаскаивает и распаковывает автоматом, GCC тоже можно так подготовить.

                            Там с библиотеками, правда, проблемы: по хорошему нужно бы сделать libstdc++-аддон, который бы содержал в себе функции, которые есть в GCC 4.7+, а «старые» функции брал бы из libstdc++.so. Там нетривиальное количество работы, но за несколько дней, думаю, можно изобразить…
                              0
                              Ну вот видите ) еще один повод комментировать на Хабре — Вы мне сейчас подскзали хорошее направление для развития )
                                0
                                Проще уж взять и поставить (собрать) clang и линковаться соответственно с libc++? Ее можно с собой как обычную библиотеку таскать и она ничего не поломает.
                    +1
                    Ссылка на С++ 14 битая.
                      +1
                      Да, спасибо, при копировании aspx->asp заменилось. Поправил — но, вообще, полагается о таком в личку.
                      Заодно и для GCC поправил. (Хорошее правило, для себя, на будущее — после публикации статьи в ней все ссылки должны быть посещенные)
                      +1
                      Вот тут https://gcc.gnu.org/gcc-5/changes.html можно найти более подробное описание новшеств в GCC 5. В частности, из того что упущено в таблице, там появятся:
                      — feature testing macros
                      — typename in a template template parameter

                        0
                        Спасибо. Я написал в статье, что МОГУТ БЫТЬ неточности. Уж не знаю как еще прозрачнее можно намекнуть, что с исправляшками — в личку. Я-то обновил, а Ваш комментарий теперь увековечен =)
                          +1
                          Зато теперь все читатели будут знать, где посмотреть новые возможности следующей версии GCC. А их довольно много. В частности, наконец то реализация std::list будет соответствовать стандарту.
                            0
                            Хорошо, я тоже люблю бонусы в комментариях, но пост все же обновил этой ссылкой.
                              0
                              В частности, наконец то реализация std::list будет соответствовать стандарту.
                              Что, в свою очередь, обозначает, что std::list из GCC5 несовместим с std::list из GCC4, то есть ещё долгие годы мы будем вынуждены использовать только возможности GCC 4.9.

                              Тоже полезная информация.
                                0
                                что, простите? Настолько я помню, list::size() будет теперь не за линейное время возвращать результат, а за константное. Это большая проблема для пользователей класса?
                                  0
                                  Это требует хранить размер в самом объекте списка, и следовательно, требует изменения ABI. То есть вы не сможете линковаться с библиотеками, откомпилированными старой версией компилятора (если будете передавать списки).
                                    0
                                    Какой ужас! Это же первое изменение ABI GCC в истории! Что ж мы раньше-то делали!
                                    Нет, серьезно, как разработчик, который поддерживает gcc 3.4, 4.1 и 4.8 одновременно, я не вижу в этом большой беды.

                                    Речь шла про «ещё долгие годы мы будем вынуждены использовать только возможности GCC 4.9.». По-моему, это сгущение.
                                      0
                                      Все эти изменения ABI приносит много боли, так что Вы зря. Я не так давно столкнулся с проблемой функции memcpy в старом дистре линуха, которая требовала glibc 2.2.5. Косяк в том, что в версии 2.14 произошло несовместимое обновление этой функции, а это значит, что простейшее приложение, откомпиленное на новых библиотеках, без грязных хаков никак не будет работать на старых библиотеках.
                                        0
                                        Для этого есть LSB. Просто выберите версию LSB, которая вам нужна — и ваша программа сошлётся на те символы, которые данная версия LSB поддерживает.

                                        Есть только одна проблема: если вам нужна только libc или какие-нибудь распространённые библиотеки типа gtk — то эта вся конструкция работает, но как только ваша программа хочет «странного» (ну там HTMLку показать или, прости господи, бибикнуть) — так и всё: ничего этого в LSB нету.

                                        Но как proof-of-concept — оно работает.
                                          0
                                          LSB идет со старыми версиями gcc. Пока все нужное соберешь, вариант окажется не лучше, чем взять целевой Linux и собрать под ним. Ну или я что-то не понимаю.
                                            +1
                                            Вы всё правильно понимаете. До ума это доведено, скажем, в Android'ном NDK: вы можете совершенно спокойно собирать в нём приложение используя GCC 4.9, а запускать потом… ну, например, на Android 2.3.

                                            Но поскольку разработчикам GNU/Mess'а и в голову не приходило, что кто-то может иметь наглость выпускать библиотеки не в виде исходников, то ничего подобного в LSB сделать не удалось. LSB — это такой себе «полуSDK»: часть библиотек — обратно совместима, часть (причём чувствительная часть) — отсутствует как класс.

                                            Как я уже говорил: скорее proof-of-concept, чем вещь, которую можно реально использовать. Но сослаться на memcpy@GLIBC_2.4 можно легко :-)
                                        +3
                                        Это же первое изменение 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 решились-таки сломать совместимость.
                                          0
                                          Нет, не первое. Пятое

                                          я знаю. /sarcasm.
                                          Вы можете собрать библиотеку GCC 3.4, слинковать её с библиотекой, собранной GCC 4.9

                                          Хм, я что-то не пробовал так заморачиваться. Я линкую все в пределах одной версии, не особо надеясь на совместимось. Для меня нет в этом большой головной боли (все равно на target-окружениях будут разные версии рантайма).
                                            0
                                            Я вообще может какой-то неправильный человек, который не видит вообще проблемы в том чтобы собрать под два компилятора. Или под пять. Пять сборок. Наверное, потому что я не разработчик WebKit-а, и мне не надо сутки ждать сборки. Может быть, поэтому.

                                            Не в тему, но я еще до сих пор все проекты под Qt 4 и под Qt 5 собираю и не запариваюсь.
                                              +1
                                              Проблема-то не в том, что вы не можете собрать под два компилятора, а в том, что не все это будут делать. Вот захотите вы использовать вкусняшки из C++14/17 в проекте с какой-нибудь проприетарной библиотекой, а не получится: вкусняшки только с gcc 5.0, а библиотека собрана gcc 4.
                                                0
                                                Я вот просто перепрыгнул на clang+libc++ и вкусняшек стало много и работает хорошо. Но у меня нет зависимости от других библиотек, которым нужен stdlibc++. В противном случае действительно приходит боль и страдание.
                                                  0
                                                  Боль и страдание приходит только если вы хотите перейти на GCC 5.
                                                  0
                                                  Аа) ладно, всё, я понял Вас! Я просто обычно и есть тот самый «проприетарный» разработчик и от других проприетарных как-то не завишу (т.е. я могу пересобрать все что мне нужно (вплоть до ядра и компилятора)). Простите, посмотрел со своей колокольни!
                                                0
                                                Там есть некоторые нюансы, если нужна бинарная совместимость между C++98 и C++11 кодом: gcc.gnu.org/wiki/Cxx11AbiCompatibility
                                                  0
                                                  Можно слезть на libc++, и там изначально новое ABI и ставится она даже на совсем дремучие системы.
                                                    0
                                                    Да какая, нафиг, разница: libc++ или libstdc++.so.7? В обоих случаях у вас свой, особый std::string и std::list, которые вы больше никуда передать не сможете!
                                                +1
                                                Там не только списки поменялись. Также изменены std::string'и и ещё много чего. Скорее всего будет libstdc++.so.7 со всеми вытекающими.
                                      +1
                                      Где же выделение цетом? Очень не хватает. Просто взгляните, какая красота: blogs.msdn.com/b/vcblog/archive/2014/06/11/c-11-14-feature-tables-for-visual-studio-14-ctp1.aspx

                                      И сразу будет наглядно, какие фичи более популярны и какие компиляторы обеспечивают поддержку большинству фичей.
                                        0
                                        Ещё бы они цвета правильно расставляли. Часть этого «зелёного» на самом деле «жёлтое», и это как в core language features, так и в library…
                                        Например, попробуйте вызвать конструктор через {} в списке инициализации. Внезапно вылезет вот это.
                                        0
                                        Интересно, может ли кто-нибудь расширить таблицу информацией по Sun/Oracle Forte C++ Compiler? Судя по анонсам на сайте производителя, продукт по-прежнему развивается.

                                        Only users with full accounts can post comments. Log in, please.