company_banner

Ещё один шажок к C++20. Встреча в Альбукерке

    Из центральной части Канады — на юго-запад США! Альбукерке расположен в штате Нью-Мексико:



    На встрече международного комитета по стандартизации C++, которая прошла в этом городе, приняли одно очень большое нововведение в С++20 и несколько маленьких.

    operator <=>


    В черновик C++20 был добавлен оператор spaceship, с помощью которого можно за одну операцию определять отношение элементов. В простых случаях это значит, что можно определить оператор spaceship и ваш класс научится сравниваться любыми способами: <, >, <=, >=, == и !=. Пример:
    Без оператора spaceship С оператором spaceship
    struct point3d {
        int x;
        int y;
        int z;
    };
    
    using p_ref = const point3d&;
    
    bool operator==(p_ref a, p_ref b) {
        return a.x == b.x
            && a.y == b.y
            && a.z == b.z
        ;
    }
    bool operator< (p_ref a, p_ref b) {
        return a.x < b.x
            || (a.x == b.x && a.y < b.y)
            || (a.x == b.x && a.y == b.y
                && a.z < b.z)
        ;
    }
    
    bool operator!=(p_ref a, p_ref b) {
        return !(a == b);
    }
    bool operator<=(p_ref a, p_ref b) {
        return !(b < a);
    }
    bool operator> (p_ref a, p_ref b) {
        return b < a;
    }
    bool operator>=(p_ref a, p_ref b) {
        return !(a < b);
    }
    

    struct point3d {
        int x;
        int y;
        int z;
    
        auto operator<=>(const point3d&)
            const = default;
    };
    
    Поведение оператора можно настраивать типом возвращаемого значения:

    class weak_equality;
    class strong_equality;
    class partial_ordering;
    class weak_ordering;
    class strong_ordering;

    Кроме того, можно писать тело самого оператора, если вам необходимо какое-то особое поведение:

    #include <compare> // weak_ordering, is_neq
    
    struct point3d {
        int x;
        int y;
        int z;
    
        std::weak_ordering operator<=>(const point3d& p) const {
            using std::abs;
            if (auto cmp = abs(z) <=> abs(p.z); std::is_neq(cmp)) return cmp;
            if (auto cmp = abs(x) <=> abs(p.x); std::is_neq(cmp)) return cmp;
            return abs(y) <=> abs(p.y);
        }
    };

    Описание поведения оператора и примеры использования можно найти в этом документе. Интеграция spaceship со стандартной библиотекой описана здесь*.

    Особенно приятно видеть, что добавили следующий алгоритм:

    lexicographical_compare_3way(InputIterator1 b1, InputIterator1 e1, InputIterator2 b2, InputIterator2 e2);

    Теперь можно эффективно, в один проход, сравнивать диапазоны данных.

    osyncstream


    Многие из читателей наверняка писали в std::cout/std::cerr из нескольких потоков одновременно и видели странный вывод:

    #include <iostream>
    #include <thread>
    #include <string_view>
    
    void say_hello(std::string_view username) {
        std::cerr << "Hello " << username;
    }
    
    void beware_of(std::string_view something) {
        std::cerr << something << " is dangerous";
    }
    
    int main() {
        std::thread t1([]{
            say_hello("Rachel");
        });
    
        std::thread t2([]{
            beware_of("darkness");
        });
    
        std::cerr << '\n';
     
        t2.join();
        t1.join();
    
        /* Possible output:
                Hello darkness
                Rachel is dangerous
        */
    }
    

    Так вот, в C++20 добавили классы, которые позволяют легко и без лишних накладных расходов избежать перемешивания выводов:

    #include <iostream>
    #include <thread>
    #include <string_view>
    
    void say_hello(std::string_view username) {
        std::osyncstream{std::cerr} << "Hello " << username;
    }
    
    void beware_of(std::string_view something) {
        std::osyncstream(std::cerr) << something << " is dangerous";
    }
    
    int main() {
        std::thread t1([]{
            say_hello("Rachel");
        });
    
        std::thread t2([]{
            beware_of("darkness");
        });
    
        std::cerr << '\n';
     
        t2.join();
        t1.join();
    }
    

    Подробности — в этой бумаге*.

    Заслуги РГ21


    Мы, как всегда, ездили на заседание с несколькими предложениями:

    • P0539R2 — integers, размер (количество байт) которых задаётся на этапе компиляции. В интерфейсе решили использовать биты, посоветовали разбить бумагу на несколько бумаг поменьше, обсуждали исключения и причие мелочи. Нужно обновлять proposal.
    • P0415R0* — constexpr для std::complex. Приняли в C++20 и прямо на месте пометили ещё пару функций как constexpr.
    • P0202R2* — constexpr для большинства алгоритмов в <algorithm>. Бумагу разделили на две части и приняли в C++20 ту часть, в которой идёт речь об алгоритмах алгоритмы, не использующих std::swap. Оставшуюся часть примут на следующих заседаниях, будет отдельный proposal.
    • P0275R2 — shared_library или классы, необходимые для динамической загрузки библиотек. Рассмотрели в группе Evolution, решили, что бумага затрагивает только стандартную библиотеку и допустимо оставить поведение плагинов не специфицированным. Дальнейшая работа будет происходить в группе Library Evolution на следующих заседаниях.
    • P0858R0 (ещё не выложили в открытый доступ) — эту бумагу написали прямо во время встречи в Альбукерке. Бумага позволяет работать с итераторами std::basic_string_view и std::array в constexpr контекстах. На следующем заседании собираются принять в C++20.

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

    • P0457R1 — starts_with и ends_with для строк. Приняли в C++20. Шикарная штука!
    • P0458R0 — функция contains(key) member для классов [unordered_]map/set/multimap/multiset. Отправили в LWG, на следующем заседании, возможно, примут в C++20.

    Прочие новинки


    • range based for теперь может иметь следующий инициализатор:

      for (T thing = f(); auto& x : thing.items())
    • Отныне можно конструировать лямбды без состояния:

      using greater_t = decltype([](auto x, auto y) { return x > y; });
      std::map<std::string, int, greater_t> map;
      constexpr greater_t comparator{}; // OK
    • std::is_pod и std::is_pod_v помечены как deprecated.
    • Добавили новый type trait std::remove_cvref.
    • Атрибут [[nodiscard]] добавили к функциям async(), new, allocate(), empty() и launder().
    • std::memory_order* теперь доступны в виде scoped enum.
    • Добавили атомарные умные указатели:

      template <class T> struct atomic<shared_ptr<T>>;
      template <class T> struct atomic<weak_ptr<T>>;
    • Добавили поддержку чисел с плавающей точкой в std::atomic.
    • Множество мелких улучшений и багфиксов.

    Параллельно кипела работа по подготовке к Modules TS и были добавлены множественные небольшие улучшения для Networking TS.

    Вместо итогов


    У вас есть идеи для C++20? Нашли проблемы в C++17, 14 или 11? Просто хотите подстегнуть разработку той или иной фичи C++? Заходите на сайт рабочей группы: stdcpp.ru. Добро пожаловать!

    Есть желание помочь с написанием предложений и внести своё имя в историю? Мы подготовили мини-инструкцию по написанию предложений.

    27 ноября состоится встреча РГ21, где будет телемост с Гербом Саттером и несколько выступлений. Приходите — вот ссылка на регистрацию. Наконец, готовится встреча C++ User Group в Нижнем Новгороде.


    * Во всех этих случаях в стандарт приняли несколько обновлённые версии.
    Яндекс
    385.42
    Как мы делаем Яндекс
    Share post

    Similar posts

    Comments 260

      0
      Что насчёт resumable functions?
        0
        Есть в виде TS, почитать можно вот тут.

        Как обкатают, станут частью стандарта.
          0
          Это то я знаю. Но войдёт ли в C++20 или надо ждать ещё дольше?
          И когда им научатся компиляторы отличные от MSVC? (многие фичи начинают поддерживаться раньше выхода стандарта, а тут никто кроме MSVC не торопится)
            –1
            Это то я знаю. Но войдёт ли в C++20 или надо ждать ещё дольше?
            Этого вам никто не скажет до выхода стандарта. Истории с std::async хватило.
            И когда им научатся компиляторы отличные от MSVC? (многие фичи начинают поддерживаться раньше выхода стандарта, а тут никто кроме MSVC не торопится)
            Вот именно в этом — и проблема: на платформах, отличных от Windows, это никому не интересно (по разным причинам). А Windows-only технологию вряд ли удастся пропихнуть в стандарт.

            С другой стороны альтернативное предложение (которое мне лично нравится гораздо больше) вроде как заглохло, так что может быть и примут… но не факт, что в C++20.
              0
              > Истории с std::async хватило.

              Можете либо уточнить, что имели в виду, а ещё лучше, предоставить сслыку, если там какой-то разбор фатального недостатка, пожалуйста?
              Или всё довольно банально и `std::async` просто откладывался несколько раз?
                +1
                Можете либо уточнить, что имели в виду, а ещё лучше, предоставить сслыку, если там какой-то разбор фатального недостатка, пожалуйста?
                Вот тут есть большая статья с дополнительными ссылками.

                Или всё довольно банально и `std::async` просто откладывался несколько раз?
                Наоборот — его «по-быстрому» включили в стандарт… теперь расхлёбывают…

                Если коротко, то оказалось что std::async в том виде, в каком он стандартизован использовать практически невозможно — хотя можно использовать вариации реально реализованные разными вендорами опираясь на вещи не описанные в стандарте.

                Когда Microsoft выкатил своё предложение, то оказалась, что там — та же фигня: реализация ровно того, что они предложили не позволяет писать работающие программы, а то, что реально реализовано в MSVC — опирается на некоторые вещи, которые в стандарте не упоминаются.

                Кому и зачем такой стандарт нужен? C++ — это ж не OOXML, который был нужен Microsoft'у, чтобы продавать офис в некоторых странах, расширения, которые нельзя использовать без учёта специфики конкретной реализации, вполне себе могут жить и вне стандартарте без формального «окропления водой» комитетом по стандартизации.

                Посему было решено подождать пока будет ещё хотя бы одна реализация… но только оказалось, что это никому, кроме Microsoft'а не интересно — а в таком случае… зачем спешить?
        +2
        Модули успевают к C++20?
          0
          Пока только готовятся к выходу в виде TS. Непонятно как оно пойдёт дальше. Concepts прожили два года в виде TS, прежде чем их втянули в C++20.
        • UFO just landed and posted this here
            +2
            То, как HR пишут вакансии, к самому языку никак не относится.

            В язык обычно что-то добавляют. Удаляют очень и очень редко. В комитете стараются тщательно следить за обратной совместимостью.
              +5
              Хр упоротые курицы, не обращайте внимания на их писанину. Просто ищут зеакомые буквы, все.
              А вот потрындеть о состоянии языка на собеседовании — милое дело. Сразу видно, что у человека болит и, соответственно, чем он на самом деле плотно пользовался.
                +1
                На самом деле, единственное принципиальное изменение произошло в C++11 — move semantics. Всё остальное — синтаксический сахар, который изучается напрямую на практике.
                  +1
                  Новую модель памяти я бы никак синтаксическим сахаром не назвал.
                    0
                    Я что-то упустил? Поясните, что за новая модель памяти имеется в виду. Или вы стандартизацию multi-threading имеете в виду? Так это не новая модель памяти, а именно стандартизация того, что компиляторы де-факто и так делали.
                      0
                      Да, связанные с порядком операций, например
                      §6.7 [stmt.dcl] p4

                      If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.

                      и всякое другое.

                      «Де-факто» и «де-юре» в данном случае играет роль, т.к. в первом варианте вам вообще никто ничего не гарантирует и нужно это учитывать.
                        +1
                        Я все равно не считаю принципиальным изменением переход от «де-факто» к «де-юре».

                        А вот введение move-семантики затронуло сами принципы написания С++ кода.
                          +1

                          Без афинных типов это хороший способ прострелить себе ногу.

                      +1
                      Сомневаюсь, что фишки новой модели памяти люди применяют в повседневном программировании.
                        +2
                        Например, возможность создать потокобезопасный синглтон простым static-полем без double-check locking, не?
                          0
                          Это отдельная фишка. На неё была отдельная бумага www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2148.html
                            0
                            Ни разу не было необходимости этого делать.
                            Кстати, почему обычное статическое поле вы называете синглтоном?
                              +1
                              Есть так называемый «синглтон Майерса»:
                              T &instance() {
                                  static T instance;
                                  return instance;
                              }
                              

                              Он пишется меньшим количеством кода и сам заботится о потокобезопасности.
                                0
                                Если этот объект что-то инжектить в себя из других разделяемых библиотек с с static T instance есть большой шанс прострела ноги
                                0
                                Если у вас ни разу не было в этом необходимости, то это не значит, что ваш опыт релевантен абсолютно для всех :)
                                Обычное статическое поле — это не синглтон. Статическое поле может использоваться как хранилище для инстанса в простой потокобезопасной реализации синглтон-класса на C++11, в старых версиях стандарта же для этого нужна блокировка с двойной проверкой и барьерами памяти.
                                  0
                                  Если у вас ни разу не было в этом необходимости, то это не значит, что ваш опыт релевантен абсолютно для всех :)

                                  Так и есть. У меня, например, подобные статические поля являются ещё и thread_local.

                                +2
                                Double-check locking с точки зрения стандарта тоже ничего не гарантировал, кстати. Была забавная статья Александреску на эту тему.
                                  –1
                                  Вопрос не в статьях Александреску, а в MSVC.

                                  На практике-то double-check locking — работал. А инициализация глобалов — не работала. Теперь — работает и в теории и на практике. Хорошо же.
                            +2
                            constexpr-функции тоже не совсем сахар.

                            Да и лямбды разные бывают, одно дело — передать какой-нибудь компаратор в STL-ный алгоритм, другое — нагородить дженерик лямбд, возвращающих лямбды, распаковывающих туплы и передающих лямбды дальше. Писать по старинке это очень сильно замучаешься.
                              –1
                              Вообще провести границу между «сахаром» и «несахаром» тяжело. Какие-нибудь variadic template'ы — вроде как сахар, а без него многие вещи оччччено тяжко делаются.

                              А уж квантовые переменные с «Редукцией фон Неймана» — это вообще непонятно куда отнести. Вроде как сахар, а реально — на этом можно такие вещи построить, которые без них вообще фиг сделаешь. С Boost.Hana поиграйтесь — очень весело…
                                +1
                                Какие-нибудь variadic template'ы — вроде как сахар, а без него многие вещи оччччено тяжко делаются.

                                Ну, всякие вещи от boost.variant до наркомании в MPL/Fusion вполне в довариадиковые времена успешно делались. С вариадиками и всякими boost.hana приятнее, конечно.

                                Вроде как сахар, а реально — на этом можно такие вещи построить, которые без них вообще фиг сделаешь. С Boost.Hana поиграйтесь — очень весело…

                                Я с ханой не сильно много игрался, но довольно много чего делал сам, и там variable templates экономили максимум что пару скобочек, фигурных али круглых. Хотя с ними красивше выглядит, конечно.
                                  –1
                                  Я с ханой не сильно много игрался, но довольно много чего делал сам, и там variable templates экономили максимум что пару скобочек, фигурных али круглых.
                                  Вы с variadic templates не путаете? Попробуйте без них написать функцию, которая принимает произвольный список типов и для каждого типа — свой обработчик.

                                  Вот что-то подобное:
                                  #include <boost/hana.hpp>
                                  #include <boost/hana/ext/std/tuple.hpp>
                                  
                                  namespace hana = boost::hana;
                                  
                                  auto handlers = hana::make_map(
                                    hana::make_pair(hana::type_c<int>,
                                                    [](int i){ printf("0x%04x\n", i);}),
                                    hana::make_pair(hana::type_c<double>,
                                                    [](double g){printf("%10.2g\n", g);})
                                  );
                                  
                                  template<typename Tuple, typename Handlers>
                                  void handle(Tuple tuple, Handlers handlers) {
                                    hana::for_each(tuple, [handlers](auto o){
                                      handlers[hana::type_c<decltype(o)>](o);
                                    });
                                  }
                                  
                                  int main() {
                                    auto tuple = std::make_tuple(1, 2.0);
                                    handle(tuple, handlers);
                                  }
                                    +1
                                    Вы про hana::type_c<int>? Ну напишу вместо этого hana::type<int> {}, проблем-то.

                                    У каждой variable template есть тип, и в неэзотерическом коде он вряд ли будет невыговариваемым.
                                      –1
                                      Вы про hana::type_c<int>?
                                      Я про то, что вы можете передать hana::type_c<int>туда, куда нужно передавать переменную. В частности — можете сопоставить тип и что-то вычисляемое (массив какой-нибудь).

                                      Ну напишу вместо этого hana::type<int> {}, проблем-то.
                                      Проблемы таки возникнут. Потому что: The actual representation of hana::type is implementation-defined. In particular, hana::type may be a dependent type, so one should not attempt to do pattern matching on it.

                                      У каждой variable template есть тип, и в неэзотерическом коде он вряд ли будет невыговариваемым.
                                      Вопрос не в «выговариваемости». Вопрос, как я уже сказал, в «корпускулярно-волновом дуализме». Variable template — это всё-таки variable. Она одна (пусть и неизвестно какой у неё тип). Её можно менять как угодно, передавать куда угодно и вообще — работать с ней как с переменной. hana::type<int> {} же — это один из обьектов с определёнными свойствами. Что очень и очень усложняет работу с ними.

                                      P.S. Так-то вообще всё, что вы делаете можно в brainfuck отобразить. И сказать, что ни в одном языке программирования ничего, кроме «сахара» для brainfuck'а-то и нету.
                                        0
                                        Я про то, что вы можете передать hana::type_c<int>туда, куда нужно передавать переменную.

                                        Так можно же передать и hana::type<int> {}

                                        Проблемы таки возникнут.

                                        Это связано с конкретной реализацией и с тем, что в API торчит variable template, дабы у автора была некоторая свобода манёвра. Давайте эту сегодняшнюю реализацию зафиксируем и будем её рассматривать.

                                        Она одна (пусть и неизвестно какой у неё тип).

                                        Это не гарантирует отсутствия других экземпляров того же типа. Да и операторы сравнения всё равно писать придётся для типа, если вы захотите в какой-нибудь контейнер её класть. Либо не придётся, но это всего лишь значит, что вы сравнение кодируете в типе, и вам снова variable templates не сказать чтоб нужны.

                                        Её можно менять как угодно

                                        Вы про это?

                                        #include <iostream>
                                        
                                        template<typename T>
                                        T smth = 10;
                                        
                                        int main()
                                        {
                                            std::cout << smth<int> << std::endl;
                                            std::cout << smth<double> << std::endl;
                                            
                                            smth<int> = 20;
                                            smth<double> = 30;
                                            
                                            std::cout << smth<int> << std::endl;
                                            std::cout << smth<double> << std::endl;
                                        }
                                        


                                        Нууу… Можно сделать и обычной шаблонной функцией, возвращающей ссылку на локальный static-объект нужного типа. Собственно, как и hana::type_c. Как и вообще оно зачастую делалось до появления variable templates. Да, требует пары лишних скобочек в точке вызова и пары лишних строк кода в точке определения, но я бы не сказал, что их экономия — это настолько существенное нововведение.

                                        Что очень и очень усложняет работу с ними.

                                        До сих пор не вижу, как.

                                        P.S. Так-то вообще всё, что вы делаете можно в brainfuck отобразить. И сказать, что ни в одном языке программирования ничего, кроме «сахара» для brainfuck'а-то и нету.

                                        Это верно. Сахарность точным объективным образом не измеришь.
                              0
                              std::thread
                              +1

                              А на собеседовании всё равно спростя про стоимость виртуального вызова и что такое виртуальное наследование. На это всё закончится.

                                0
                                Зависит. Из последнего меня просили, например, написать аналог std::any с такими-то требованиями к конвертации типов вверх-вниз-вбок по иерархии, или наваять парсер JSON-подобного языка (в итоге получилось что-то комбинатороподобное на манер attoparsec).

                                Потом за системы типов и раст поболтали.
                              0
                              auto operator<=>(const point3d&)
                                  const = default;
                              

                              зачем такая ужасная конструкция в языке? а default = const будет работать?
                                +6
                                В одну строчку просто не поместилось в табличке:
                                auto operator<=>(const point3d&) const = default;
                                  +2
                                  Кроме того, можно писать тело самого оператора, если вам необходимо какое-то особое поведение:

                                  #include <compare> // weak_ordering, is_neq
                                  
                                  struct point3d {
                                      int x;
                                      int y;
                                      int z;
                                  
                                      std::weak_ordering operator<=>(const point3d& p) const {
                                          using std::abs;
                                          if (auto cmp = abs(z) <=> abs(p.z); std::is_neq(cmp)) return cmp;
                                          if (auto cmp = abs(x) <=> abs(p.x); std::is_neq(cmp)) return cmp;
                                          return abs(x) <=> abs(p.x);
                                      }
                                  };

                                  В вашем 'особом' поведении закралась бага.


                                  antoshkka лучше скажи, когда откроете сорцы libgeobase, я бы переписал на Rust.

                                    0
                                    Спасибо, пример немного подправил.

                                    А насчёт geobase — это не ко мне :)
                                    –2
                                    у меня такое ощущение, что std пишут на терминалах в 40 строк, а вместо большинства клавиш там "_". есть еще мнение, что std пишут роботы
                                  +11
                                  C++20 — учить 20 лет, перед тем как приступить к программированию ))
                                    0
                                    По хорошему C#, Java и PHP нужно учить столько же, прежде чем приступать к программированию :)
                                      –4
                                      По всей видимости, вы на самом деле никогда не программировали на C++, если пытаетесь так наивно сравнивать.
                                      +3
                                      А что в этом такого ужасного? Какого-нибудь архитектора учат несколько лет — причём большая часть этого посвящена умению оформлять чертежи. Для того, чтобы врачу разрешили оперировать — нужно тоже учиться несколько лет и потом ещё практиковаться под руководством опытных наставников. И опять-таки: латынь и умение грамотно оформлять всё — большая часть процесса…

                                      И только в IT считается, что двухмесячных курсов должно быть достаточно для того, чтобы претендовать на зарплату, которая будет выше, чем у начинающего архитектора или терапевта.
                                        –3
                                        Представь, что в 2017 ты начинаешь учить С++17, через 3 года с гордостью заканчиваешь его. И бац! С++20. Опять надо учить, опять ты никому не нужен.

                                        В IT все меняется с каждым годом все быстрее. Поэтому пора изобретать принципиально новые подходы к программированию и его обучению. Да, за 2 месяца С++ не выучить, но зато можно выучить другой какой-то язык. Мне кажется, не за горами тот год, когда мы начнем писать программы на своем естественном языке с нормальным уровнем абстракции без этих spaceship default const.
                                          +1
                                          И бац! С++20. Опять надо учить, опять ты никому не нужен.

                                          Чай, не джаваскрипт) Вряд ли кому-то откажет работодатель по причине того, что кандидат не в совершенстве освоил новый стандарт. Тем более, что первые пару лет еще придется поискать конторы, которые начнут его применять.
                                          Как тут уже верно замечали, действительно концептуальное изменение было одно — семантика перемещения в C++11 (спустя 7 лет от предыдущего стандарта), всё остальное — сахар, который усваивается прямо по ходу дела.
                                        0
                                        Мне очень понравилась одна речь дяди Боба на тему разработки ПО (правда сама лекция была о SOLID).
                                        > Кол-во разработчиков увеличивается вдвое каждые 5 лет. Соответственно половина разработчиков ПО имеют < 5 лет опыта в бою.

                                        Еще в другой речи о будущем программирования он освещает тему важности качественно написанного кода. От некоторых программ зависят жизни миллионов человек. И 20 лет опыта вполне нормальная цифра при такой ответственности.
                                          +1
                                          Неужели это правда, что количество разработчиков за 5 лет в 2 раза увеличивается? Где почитать статистику?
                                            0
                                            Не проверял, к сожалению, слова Боба Мартина, но вот видео с выступлением (время стоит как раз но том моменте, о котором я упоминал)
                                              0
                                              Самому стало интересно и нашел таки более подробную статистику http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html

                                              Спасибо, что подогрели мой интерес :)
                                                0
                                                По ссылке интересная статья, но едва ли по ней можно сказать что и сегодня количество удваивается каждые 5 лет. Он берёт количество программистов в 1974, потом сравнивает с 2014, для целей его статьи это нормально. Но предполагать что скорость роста остаётся неизменной и сегодня, только на основании этих данных, было бы неверным. Для того чтобы знать, что происходит сегодня, надо посмотреть статистику последних лет.
                                          –6
                                          В наш любимый С++ стали добавлять, возможно, крутые фичи, но на мой взгляд они совершенно ему не нужны(за исключение возможно <=>). С++, на мой субъективный взгляд, один из самых интересных и сложных языков, поэтому не следует его так сильно загружать. Я бы добавил возможности связанные с графикой, что бы начинающим (и не только) стало легче и интереснее работать с этим языком
                                            +4
                                            Какие фичи на Ваш взгляд никому не нужны?

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

                                            Рассматривается потихоньку пропозал насчёт графики.
                                              +1
                                              Никто не мешает Вам как разработчику на С++ использовать только какое-то подмножество языка и не изучать все его тонкости и дебри. Это совершенно ни к чему.

                                              1. Подходит на 100% в случае разработки приложения в одиночку с использованием только стандартной библиотеки.
                                              2. В команде уже начинаются сложности, но в целом их можно преодолеть разработав собственные инструкции, которых все должны строго придерживаться. Но это уже потенциальная проблема от простого недовольства до принципиального отказа работать в команде.
                                              3. Но как насчёт сторонних библиотек? Как заставить их авторов придерживаться ваших правил?

                                              Поэтому на мой взгляд просто взять и проигнорировать всё, что не нравится или непонятно, при работе в команде над серьёзным приложением не получится.
                                              +3
                                              Концепты. Концепты, очень надеюсь, добавят. Помимо уже тысячу раз обсуждённых профитов, ad-hoc requirement clause'ы в сочетании с constexpr if позволяют просто чудеса творить: вместо условного
                                              template<typename T>
                                              using Detector = decltype(std::declval<T>().MakeFieldName(QString {}));
                                              
                                              template<typename T>
                                              QString MakeFieldName(const QString& str)
                                              {
                                                  if constexpr (std::is_detected_v<Detector, T>)
                                                      return T::MakeFieldName (str);
                                                  else
                                                      return str;
                                              }
                                              


                                              можно писать что-то вроде
                                              template<typename T>
                                              QString MakeFieldName(const QString& str)
                                              {
                                                  if constexpr (requires (T t) { t.MakeFieldName(QString {}); })
                                                      return T::MakeFieldName(str);
                                                  else
                                                      return str;
                                              }
                                              

                                              что полезно, когда у вас достаточно много таких if constexpr, и писать детекторы «где-то там», вдобавок засоряя глобальное пространство имён, не очень удобно.

                                              А, пользуясь случаем, нужны constexpr ternary operators, вот.
                                                0
                                                Такие сомнения высказываются с момента рождения c++. Но по мне так после десятилетий застоя уж шибко резво рванул развиваться, я не поспеваю )
                                                  +5
                                                  Я бы добавил возможности связанные с графикой, что бы начинающим (и не только) стало легче и интереснее работать с этим языком
                                                  Вы хотите сказать «сложнее и попобольнее», как я понял.

                                                  Я не видел ни одной библиотеки для работы с графикой, ни на одном языке программирования, которая была бы уместна и в программе на iOS и в программе для Windows и в программе под Android. Есть всякие кроссплатформенные вещи (типа той же Ауры), но опять-таки — игры на них делать не будешь.

                                                  Пока что почти вся стандартная библиотека C++ устроена так, что её можно использовать в любом проекте под любую платформу. Графические вещи с этим же свойством — я представить себе не могу.

                                                  P.S. Речь не идёт о том используются они или нет. Если проект достаточно старый — там и строки могут быть QT'шные (или свои собственные) и callback'и и прочее. Но в новом проекте — вполне можно использовать то, что входит в стандарт. И люди регулярно отказываются от своих «велосипедов». Представить себе графическую библиотеку с подобным свойством, я, увы, не могу.
                                                    +4
                                                    Кутешные строки в гуи-приложении всё-таки куда удобнее STL'ных, к слову. Даже с новыми startsWith/endsWith.

                                                    А к гуям ещё локализация притащится, кстати, тоже веселуха будет. Не, не место GUI-либе в стандарте.
                                                      0
                                                      строки Qt cow и utf16. Это не всегда уместно
                                                        +4
                                                        Я бы сказал сильнее: это вообще почти никогда не уместно. COW на современных системах только замедляет работу и почти не экономит память, а UTF-16… смысл в нём есть только, если вам вам нужно работать с legacy-кодом, который оказался таким из-за того, что кто-то когда-то решил, что всем хватит 640K все буквы поместятся в int16.

                                                        Нет, я не спорю: QString — хорошая вещь… для того времени, когда она была написана… Но сегодня… лучше иметь библиотеку поверх std::string. Эх, если б только разработчики ICU не страдали фигнёй…
                                                          0
                                                          Есть наброски: github.com/sitev/core/blob/master/src/strings.cpp
                                                          правда сам писал)
                                                            0
                                                            Иксы до сих пор не особо многопоточные, отрисовывать всё равно только из одного треда можно. Да и вообще в GUI-коде, вероятно, удобство API куда важнее производительности строк. Вы же не перелопачиваете гигабайты данных прям в гуях?

                                                            UTF-16 действительно глупое решение, да.

                                                            В принципе, есть ещё всякие boost.format, boost.algorithms, и так далее, но почему-то эту часть буста я патологически не переношу.
                                                              0
                                                              Иксы до сих пор не особо многопоточные, отрисовывать всё равно только из одного треда можно.
                                                              И именно поэтому COW — глупое решение. Читаем. Черно-зелёным написано: Qt, however, uses atomic reference counting to ensure the integrity of the shared data, avoiding potential corruption of the reference counter.

                                                              Вы знаете сколько стоят атомики на современных многоядерных CPU?

                                                              Да и вообще в GUI-коде, вероятно, удобство API куда важнее производительности строк.
                                                              Ага. А в других местах — давайте использовать другие строки. Как Windows — разведём зоопарк и будем в них путаться потом.

                                                              Вы же не перелопачиваете гигабайты данных прям в гуях?
                                                              Не перелопачиваю. И тем страннее выглядит решение получить копеешную экономию памяти (да и то не факт: на практике за счёт того, что std::string для коротких строк память не выделяет потребление памяти может оказаться меньше, чем с QString'ами) за счёт существенного замедления простых операций.

                                                              В принципе, есть ещё всякие boost.format, boost.algorithms, и так далее, но почему-то эту часть буста я патологически не переношу.
                                                              Там тоже много странного, да. Сделать хорошие строки — весьма непросто, как показывает практики. Во всех языках и библиотеках — с ними те или иные проблемы. std::string с utf8 содержимым — не самый худший вариант, а с учётом того, что это, фактически, стандарт — стараюсь им и пользоваться.
                                                        +1

                                                        Что там в STL работает на платформах без поддержки исключений, пара алгоритмов, std::is_* да std::array?

                                                          +1
                                                          Всё, но это не совсем C++.

                                                          Поищите замечательные доклады от SG14 (game dev, low latency). Они пытаются уйти от исключений в сторону более быстрых механизмов сообщений об ошибках… И не могут найти механизмы, которые работали бы быстрее, в случае отсутствия ошибки.

                                                          Читайте современные исследования, не используйте исключения для «не ошибок» и всё будет хорошо.
                                                            0
                                                            Это замечательно но смысл не в перфомансе, есть платформы(микроконтроллеры, uefi, драйвера) где есть этот не совсем c++ т.е просто поддержка исключений в libstdc++ нет любой вызов throw приведет к ub(в терминах хост платформы). И тут мы приходим к выводу что либо запилите исключения ручками для рантайма сами, либо не трогайте STL либо откажитесь от всего синтаксического сахара и пишите на C.
                                                              0
                                                              Что конкретно вы предлагаете исправить в стандарте? Вызывать std::terminate при throw на платформе без поддержки исключений?
                                                                +1
                                                                Это сложный вопрос, ясно что stl уже не переписать, да и error_code методы будет нужно поддерживать, возможно когда какой-нибудь noexcept-like stl реализуют в boost можно будет говорить, а сейчас яcно это нужно 1.5 людям, у которых уже есть свои решения. Но в принципе std::terminate с backtraceом на таких платформах который вроде был в каком-то из предложений тоже бы не помешал)
                                                                  0
                                                                  backtrace/stackrace на подходе, скоро закинем в комитет предложение.
                                                                0
                                                                STL — он же большой. Какие проблемы при отсутствии исключений вы ожидаете при использовании, скажем, std::find, std::count_if, std::transform, std::copy и др.?
                                                                  +1
                                                                  ну вот в том то и дело что только алгоритмы, и то не все, да io, остаются. Вот кстати io хороший пример в basic_ios нам дали возможность убрать чась исключений, для всего остального нет.
                                                                  0
                                                                  И тут мы приходим к выводу что либо запилите исключения ручками для рантайма сами, либо не трогайте STL либо откажитесь от всего синтаксического сахара и пишите на C.

                                                                  Написал аналог Either и теперь дальше приближаюсь к диабету с таким-то сахарком! Не хаскель, конечно, но жить можно, и, вероятно, даже удобнее, чем с исключениями. Типы ошибок сразу в сигнатуре функции видно.
                                                                  0
                                                                  вроде как все стандартные методы имеют либо не кидающие исключений аналоги, либо возможность заблаговременной проверки ошибочного условия. Кроме new, но на платформах без поддержки исключений все равно делать через аллокаторы.
                                                                    +1
                                                                    std::conditional_variable как проверить заранее что не бросят system_error во время вызова wait?
                                                                      0
                                                                      в с++14 condition_variable::wait не кидает исключений
                                                              +4
                                                              А вот такой вопрос, не очень связанный с содержимым статьи, но связанный с развитием C++: а на заседаниях комитета всплывают вопросы отсутствия в C++ де-факто стандартных средств управления зависимостями и/или средств сборки C++ проектов?

                                                              Ну вот в том же Rust-е есть Cargo, которая снимает изрядную часть головной боли с растоманов. В C++ же все, такое ощущение, осталось неизменным с середины 80-х годов. Каждый волен извращаться как хочет. В итоге систем сборки как грязи, на любой вкус, что особенно доставляет, когда в одном проекте нужно объединить библиотеки, использующие разные системы.

                                                              Понятное дело, что стандарт C++ — он совершенно не про то, и в стандарте не будет прописываться какая-то система сборки. Но хотя бы эта проблема затрагивается в кулуарах?
                                                                0
                                                                В итоге систем сборки как грязи, на любой вкус, что особенно доставляет, когда в одном проекте нужно объединить библиотеки, использующие разные системы.

                                                                Это как? Вы их прямо в дерево проекта добавляете и дёргаете их сборку из вашего мейкфайла/CMakeLists.txt/.jam?
                                                                  0
                                                                  Вы их прямо в дерево проекта добавляете и дёргаете их сборку из вашего мейкфайла/CMakeLists.txt/.jam?
                                                                  А как надо? Чтобы просто, кроссплатформенно, повторяемо?
                                                                    0
                                                                    просто

                                                                    Я в своём CMakeLists.txt пишу find_package(meh), проще некуда.

                                                                    кроссплатформенно

                                                                    Положиться на пакетные менеджеры в соответствующих ОС/дистрах. Если какого-то пакета нет — добавить в интересующие вас (их не так много, в конце концов). От этого выиграете и вы, и всё сообщество.

                                                                    повторяемо

                                                                    Для каких целей? Если для ваших внутренних билдов — берёте условную убунту 16.04 LTS и радуетесь жизни в ближайшем будущем.

                                                                    Собственно, а иначе как? Какие-нибудь Qt будете втягивать? А libstdc++, от которых оно будет зависеть?
                                                                    С поддержкой программы, которая зависела всего-то от буста, но пыталась поставляться в виде одного бинарника под все возможные дистрибутивы линукса, я в своё время уже наелся, спасибо.
                                                                      0
                                                                      У вас какие-то странные представления о кроссплатформенности. Ну и да, не весь мир пользуется CMake. И не желает, что характерно.
                                                                        0
                                                                        У вас какие-то странные представления о кроссплатформенности.

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

                                                                        Ну и да, не весь мир пользуется CMake. И не желает, что характерно.

                                                                        Я сам бы с радостью пользовался чем-то более приятным, но, увы, в общем случае лучше ничего нет. Или я подотстал от жизни?
                                                                          0
                                                                          Ну и да, не весь мир пользуется CMake.
                                                                          А почему, собственно?
                                                                          И не желает, что характерно.
                                                                          Ах, вон оно чё, Михалыч. Ну дык а почему весь мир вдруг возжелает пользоваться новыми тулзами, которые комитет разработает?

                                                                          Думаете перейдут потому, что это стандарт? Тогда об этом смысла нет говорить без работающих модулей. Ибо переход на C++11 до сих пор не завершен — а ему, как бы, уже довольно много лет. То есть даже в самом оптимистичном случае распространение эта система получит уже в эпоху, когда C++'никам будет что ответить на вопрос: «почем в Tubro Pascal'е модули появились 30 лет назад, а в C++ их нет до сих пор». Без модулей в любой системе будет очень много времени и сил уходитm на обслуживание костылей, их заменяющих, а если скоро — системы управления зависимостями не будет, тогда зачем в ней всё это?
                                                                            +2
                                                                            А почему, собственно?

                                                                            Синтаксис наркоманский. Особенно строки сравнить, цикл сделать или что-нибудь такое.
                                                                    +4
                                                                    Была создана подгруппа Tooling (SG Tooling) в Альбукерке. Возможно что через пол годика можно будет посылать предложения по унификации систем сборок, пакетным менеджерам и прочему.
                                                                      +1
                                                                      От оно чё, Михалыч… :) Ну будем посмотреть. Сам факт движения радует.
                                                                        +1
                                                                        А как же позиция комитета, что «Тулзы не имеют никакого отношения к самому языку, почему мы ими должны заниматься»?
                                                                          +4
                                                                          Думаю, что время и опыт «молодых» языков, вроде Rust-а и Go, показывает, что «тулзы не имеют отношения...» несколько устарело.
                                                                            0
                                                                            Ну оно то всё так, я не спорю. Просто насколько мне известно, долгое время у комитета было именно такое мнение. И я так думаю, что ничего в этом плане в ближайшее время не поменяется. C++-комьюнити само быстрее выберет билд-систему по умолчанию, менеджер зависимостей по умолчанию и так далее.
                                                                              0
                                                                              Да, было такое мнение. Вопрос потому и возник, чтобы узнать, а не поменялось ли оно со временем.

                                                                              Ибо складывается ощущение, что C++-комьюнити само выбирает тот же CMake и ничего хорошего в этом нет :(

                                                                              Плюс есть такой фактор, что когда люди говорят про модули, которые ожидаются в C++, то у многих складывается ощущение, что с пришествием модулей наступит такое же благоденствие, как в каких-нибудь языках с поддержкой модулей, вроде D или Rust-а, где сам компилятор может разобраться в каком порядке что компилировать. С большой долей вероятности в C++ это будет не так. Если только коммитет на озадачиться тем, чтобы у языка была своя де-юре стандартная система сборки.
                                                                                0
                                                                                Вы сами понимаете, что перевести все те тонны кода, что уже есть, на что-то стандартное, является, пожалуй, непосильной задачей.
                                                                                  0
                                                                                  Переносить тонны кода с C++98 на C++11/14/17 тоже не все торопятся. Это же не означает, что не нужно развивать C++, выпускать C++17 и разрабатывать C++20.

                                                                                  При появлении де-юре (да и даже де-факто, но признанного большинством) инструмента для управления зависимостями, процесс адаптации под него обязательно пойдет. Какая-то часть старого кода, естественно, никуда не денется. Но вот новый код будут делать уже с расчетом на него.

                                                                                  Тоже самое и системами сборки. Вот становится CMake де-факто стандартом и те проекты, которые развиваются, волей-неволей, но вынуждены либо переходить на CMake, либо добавлять какую-то поддержку для него (например, FindFoo.cmake-файлы).
                                                                      +1
                                                                      P0275R2. Очень нужная вещь. Спасибо!)
                                                                        0
                                                                        std::is_pod и std::is_pod_v помечены как deprecated.
                                                                        Можно поподробнее?
                                                                          0
                                                                          Помечены как deprecated, чтобы мотивировать людей использовать is_standard_layout и is_trivally_copyable.
                                                                            0
                                                                            То есть мотивировать людей писать локальную функцию?
                                                                            bool is_pod()
                                                                            {
                                                                              return is_standard_layout<T>::value && is_trivally_copyable<T>::value;
                                                                            }

                                                                            Какая-то сомнительная мотивация, хотя в type_traits это не единственная странность, взять к примеру наличие is_member_function_pointer, но отсутствие is_function_pointer.
                                                                              +3
                                                                              То есть мотивировать людей писать локальную функцию?
                                                                              А зачем вам эта функция? Если вы хотите засунуть это в realloc, то вам нужно is_trivally_copyable, если вам нужно с C общаться — вам нужен is_standard_layout, а вот случаи, когда нужно и то и другое — крайне редки (да собственно уже и is_trivally_copyable мало когда нужен, а уж чтобы был нужен POD и именно POD — я ни разу не встречал, хотя чисто теоретически такое можно придумать, но… не встречал).

                                                                              Взять к примеру наличие is_member_function_pointer, но отсутствие is_function_pointer.
                                                                              Та же самая ситуация: в 99% случаев вместо гипотетического is_function_pointer — нужно использовать is_invocable. А если очень нужно (зачем?) — то можно, наверное, и самому такое изготовить…
                                                                                0
                                                                                Мне запись is_pod кажется гораздо более очевидной, чем is_standard_layout, как и само определение «plain-old-data» проще осознать, чем «standard layout». Кроме того, раз уж добавили, то зачем убирать? Одно дело делать deprecated auto_ptr, вместо которого добавили несколько новых, а другое дело убирать что-то из type_traits, который просто предоставляет удобные штуки.

                                                                                Для is_invocable нужен список аргументов, и добавили его только в С++17, а не в С++11 как остальные две функции. Вопрос «зачем» здесь вообще не актуален, если есть библиотека для поддержки информации о типах, то там должно быть все, что с этим связано. С таким же успехом можно спросить «Зачем нужна is_arithmetic, если это всего лишь is_integral && is_floating_point?».
                                                                                  0
                                                                                  С таким же успехом можно спросить «Зачем нужна is_arithmetic, если это всего лишь is_integral && is_floating_point?».
                                                                                  Можно. И можно получить разумный ответ: есть вещи в стандарте, которые разрешены только для арифметических типов и запрещены — для всех остальных. А вот для POD — таких мест нет.

                                                                                  Мне запись is_pod кажется гораздо более очевидной, чем is_standard_layout, как и само определение «plain-old-data» проще осознать, чем «standard layout».
                                                                                  И именно поэтому сотни и тысячи програмистов используют is_pod там, где нужен is_standard_layout.

                                                                                  Рассмотрим простой пример. Вот такой тип:
                                                                                  struct Test {
                                                                                      int x = 0;
                                                                                      int y = 0;
                                                                                      int z = 0;
                                                                                  };
                                                                                  Ну надоела мне вечная возня с неинициализированными данными. Могу я его передать в C? Да, разумеется — это standard layout класс. Могу я использовать его с вашей библиотекой? Да господь с вами: вам же is_pod писать удобнее, а что кто-то там безопасности и предсказуемости хочет — так это его проблемы.

                                                                                  Нафиг-нафиг-нафиг. Если что-то слишком легко использовать неправильно — то лучше это что-то из языка и/или библиотеки удалить. auto_ptr и is_pod — как раз такие вещи. Вы, собственно, так и не ответили на вопрос: где вы is_pod применяете и почему вам is_standard_layout не подходит. А без этого дальнейшие рассуждения как бы бессмысленны.
                                                                                    0
                                                                                    Да, похоже я использовал is_pod там, где достаточно is_trivially_copyable, но зато теперь стало понятно, зачем его хотят убрать.
                                                                                      0
                                                                                      Об чём и речь. С появлением constexpr выражений (включая конструкторы и деструкторы!), default member initializers и прочего оказалось что слишком часто использование is_pod «не по делу» мешает писать красивый и удобный код.

                                                                                      Да, можно выкрутится, скажем сделать POD-класс предком того класса, с которым вы, в большинстве случаев, работаете, но это всё — костыли, которые грозят слезьми при малейшей ошибке. Гораздо лучше — использовать ровно то свойство, которое вам нужно. В C++17 POD'ы упоминаются буквально в паре мест — и, есть подозрение, что в C++ не будут упоминаться вообще нигде. Тем самым понятие потеряет всякий смысл с точки зрения языка.

                                                                                      P.S. Кстати класс из моего примера и is_standard_layout и is_trivially_copyable. Он не POD — потому что он не is_trivially_default_constructible — что тоже бывает нужно (например только такие типы вы можете считать «готовыми к употреблению с помощью reinterpret_castа поверх абстрактного куска памяти, выделенного mallocом) — но очень редко.
                                                                          +3
                                                                          Я понимаю что тут серьезные пацаны собрались, сами себе в зеркало не улыбаются, и все же — где фотки Los Pollos Hermanos, где Octopus Car Wash, где все это? Чего ездили, спрашивается? )
                                                                            0
                                                                            Jesse, it's time to cook.
                                                                            0
                                                                            Где бы это все попробовать?!
                                                                              +6
                                                                              А в сторону reflection есть какие-нибудь подвижки?
                                                                                +3
                                                                                Не дождемся, графика в станадрте очевидно важнее!
                                                                                  0
                                                                                  Про графику ведутся только начальные разговоры. Так что не стоит беспокоиться, что Комитет ерундой занимается.
                                                                                    +1
                                                                                    Зато про reflection не введутся никакие почти, а первое нужно, и это должно быть частью языка. Графика же — не очень важная часть стандартной библиотеки.

                                                                                    Я вот сижу на Delphi, как не посмотрю в сторону C++, нет почти подвижек, модули все только обещают, о рефлексии разговора толком нет, как вообще можно жить без рефлексии? Про строки которых 100500 у каждой либы и все не совместимы, я молчу(ок так исторически вышло).
                                                                                    Зато графика, комплексные числа — в стандарте — ага, спасибо.
                                                                                      0
                                                                                      о рефлексии разговора толком нет, как вообще можно жить без рефлексии?
                                                                                      А чего именно вы хотите от рефлексии? А то как-то я спокойно без неё живу с type_traits… чего я такого важного теряю?

                                                                                      P.S. Сразу предупреждаю, что инспекторы объектов я не пишу, но пользую — они отлично работают с DWARF'ом и поддержки в стандерте, как бы, не особо и требуют… всё равно для них требуется куча вещей, которых в стандарте нет… интересует куда и какую рефлексию аж такую, что без неё «жить нельзя» хотите приспособить… После получения реальных примеров уже можно будет и о расширении языка говорить…
                                                                                        0
                                                                                        Какие реальные примеры нужны? — реальнее того что Qt работает исключительно чрез эмуляцию Reflection. Хочешь рефлексию — прикручивай костыли, сейчас, когда почти все языки поддерживают эту базовую функцию — даже не смешно говорить о необходимости. В любом случае это во много раз нужнее ограниченой графической либы.
                                                                                          –1
                                                                                          реальнее того что Qt работает исключительно чрез эмуляцию Reflection.
                                                                                          Gtkmm работает без «эмуляции Reflection», Aura работает без «эмуляции Reflection», да и старый добрый WTL как-то без этого обходится.

                                                                                          Хочешь рефлексию — прикручивай костыли, сейчас, когда почти все языки поддерживают эту базовую функцию — даже не смешно говорить о необходимости.
                                                                                          Тысячи леммингов не могут ошибаться? А поконкретнее чего-нибудь можно?

                                                                                          То, что Qt'шники хотят делать в рантайм вещи, которые на C++ сделать можно только в compile-time не значит что нужно прям всё бросать и превращать C++ в Java: есть сотни проектов и тысячи библиотек, которые без этого как-то живут. А для тех, кто хочет Java, вы не поверите, есть Java.

                                                                                          Так что вопрос остаётся в силе: какую-такую рефлексию без которой «жить нельзя» вам нужно — и для решения какой бизнес-задачи вы хотите её приспособить? А также — и это очень важно — сколько будет «стоить» ваша рефлексия если вы её не будете использовать?

                                                                                          В любом случае это во много раз нужнее ограниченой графической либы.
                                                                                          Возможно. Но на графическую либу смотрят совсем не те люди, которые могли бы что-то сделать с рефлексией в любом случае.

                                                                                          То, что в C++ вообще есть RTTI, как мне кажется, есть ошибка (это одна из немногих фич, которая чего-то ощутимого стоит, когда ею не пользуются — недаром в большинстве компиляторов есть флаг -fno-rtti или что-нибудь подобное — а ведь «selling point» C++ состоит как раз в том, что ты не платишь за то, что не используешь), не стоит её усугублять.
                                                                                            +1
                                                                                            У кутешников до поры до времени была необходимость поддерживать сильно унылые компиляторы, поэтому всякие сигналы-слоты, которые до Qt 5 чаще всего использовали рефлексию, иначе не сделаешь. Да и даже в Qt 5 moc всё ещё генерирует немного кода для сигналов, и я не готов сходу сказать, что всё, что он делает, можно сходу переложить на компилятор.

                                                                                            Плюс, есть ещё всякие Q_INVOKABLE и Q_PROPERTY, которые торчат наружу в QML и прочие скриптовые вещи. В Gtkmm/WTL есть аналог QML?
                                                                                              0
                                                                                              Плюс, есть ещё всякие Q_INVOKABLE и Q_PROPERTY, которые торчат наружу в QML и прочие скриптовые вещи.
                                                                                              Они, к сожалению, просто «торчат наружу», а не «торчат наружу в QML». У вас нет никакой возможности узнать — используются они или нет.

                                                                                              С точки зрения языка это — просто некоторое описание данных для внешнего потребителя.

                                                                                              В Gtkmm/WTL есть аналог QML?
                                                                                              Нет, разумеется. Это будет противоречить самому принципу: программа должна быть доступна компилятору C++.

                                                                                              Как выдать данные дня «внешних потребителей» — над этим сейчас очень серьёзно работают. Но поскольку тут уже «играют» не только потребности C++-программистов, то очень тяжело понять, прежде всего — что, на самом-то деле нужно и что, без существенных изменений языка, возможно.

                                                                                              Когда мне в качестве примера говорят: а возьми, мил-человек, 50MB+ исходничков и перелопать из начала в конец и из конца в начало — а потом уж разговоры разговаривай… это неконструктивно. Вот это -уже конструктивнее. И SG7, разумеется, этот блог-пост читал…
                                                                                                0
                                                                                                Они, к сожалению, просто «торчат наружу», а не «торчат наружу в QML». У вас нет никакой возможности узнать — используются они или нет.

                                                                                                Я не вижу здесь каких-то особых проблем. Зачем мне об этом узнавать? Да и когда, в рантайме или в компилтайме? Если в рантайме, то это прикручивается, если в компилтайме, то для динамических вещей вроде QML или Python-скриптов это не особо возможно.

                                                                                                С точки зрения языка это — просто некоторое описание данных для внешнего потребителя.

                                                                                                Так и должно быть.

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

                                                                                                Нет, разумеется. Это будет противоречить самому принципу: программа должна быть доступна компилятору C++.

                                                                                                Безотносительно принципов, на QML всякие свистелки-перделки очень кратко и ёмко выражаются, и для некоторых сортов интерфейсов и задач это самое оно. Если язык не позволяет выразить это, не прибегая к кодогенерации, и кодогенерация не является его девизом (привет Go), то стоит подумать, как можно улучшить язык.

                                                                                                Но поскольку тут уже «играют» не только потребности C++-программистов

                                                                                                Эм, а чьи ещё? Мы ж о С++ говорим.
                                                                                                  +2
                                                                                                  Зачем мне об этом узнавать?
                                                                                                  Затем что иначе нарушается базовый принцип C++: платите только за то, что используете.

                                                                                                  Что значит, что подход, принятый в Java или Qt для C++, в общем, недопустим: нужны не метаклассы как таковые, а инструменты для их создания.

                                                                                                  Если в рантайме, то это прикручивается, если в компилтайме, то для динамических вещей вроде QML или Python-скриптов это не особо возможно.
                                                                                                  Что, собственно, и обозначает, что требуется помощь со стороны программиста — только он может сказать какое, когда и в каких количествах знание нужно экспортировать из C++ программы.

                                                                                                  Только я бы голосовал за компил-тайм-рефлексию. Рантайм-рефлексия через неё выражается, а в обратную сторону оно не работает.
                                                                                                  Это само собой — но это сразу же ставит кучу вопросов, которые достаточно сложно решать. Очень мало языков имеют компайл-тайм рефлексию не имея рантайм рефлексии. C++ здесь, во многом, первопроходец.

                                                                                                  Безотносительно принципов, на QML всякие свистелки-перделки очень кратко и ёмко выражаются, и для некоторых сортов интерфейсов и задач это самое оно.
                                                                                                  Возможно. Но на C++ — свет клином не сошёлся и, возможно, для решения каких-то задач стоит использовать другой язык. Я вот не уверен, что «свистелки-перделки» использующие в 10-100 раз больше ресурсов, чем, на самом деле, нужно — это вообще то, что нужно делать на C++.

                                                                                                  Эм, а чьи ещё? Мы ж о С++ говорим.
                                                                                                  Нет. Когда мы начинаем рассуждать о DBus, QML и прочем — то это значит, что у нас появляются какие-то жёстко заданные требования «извне», которые в языке C++ не определяются.

                                                                                                  Такие вещи в C++ есть (начиная с extern "C", ага), но говорить о них всегда сложнее, так как эсперты по этим «внешним» вещам считают очевидным, что все понимают — что им нужно, что, как бы, ни разу не так для людей, которые соответствующую технологию не используют.
                                                                                                    +1
                                                                                                    Затем что иначе нарушается базовый принцип C++: платите только за то, что используете.

                                                                                                    Не добавляю маркер Q_OBJECT — не плачу. Добавил — подразумеваю возможность использования.

                                                                                                    Что, собственно, и обозначает, что требуется помощь со стороны программиста — только он может сказать какое, когда и в каких количествах знание нужно экспортировать из C++ программы.

                                                                                                    Конечно. О рантайм-рефлексии для всего и вся по умолчанию никто в здравом уме и не говорит.

                                                                                                    Очень мало языков имеют компайл-тайм рефлексию не имея рантайм рефлексии.

                                                                                                    Ну взять тот же TH и черпать вдохновение оттуда.

                                                                                                    Но на C++ — свет клином не сошёлся и, возможно, для решения каких-то задач стоит использовать другой язык. Я вот не уверен, что «свистелки-перделки» использующие в 10-100 раз больше ресурсов, чем, на самом деле, нужно — это вообще то, что нужно делать на C++.

                                                                                                    Под этим QML может лежать тяжёлая бизнес-логика на плюсах, которую на этих плюсах имеет смысл делать.

                                                                                                    А сколько оно там ресурсов жрёт — ну можно и с CLI сравнить, в конце концов.

                                                                                                    Нет. Когда мы начинаем рассуждать о DBus, QML и прочем — то это значит, что у нас появляются какие-то жёстко заданные требования «извне», которые в языке C++ не определяются.

                                                                                                    А, в этом смысле.

                                                                                                    Ну, эти юзкейсы должны быть чем-то вроде граничных условий, позволяющих проверить, является ли данное предложение о рефлексии разумным, позволяет ли оно выразить те юкзейсы, или нет.
                                                                                                      0
                                                                                                      Ну, эти юзкейсы должны быть чем-то вроде граничных условий, позволяющих проверить, является ли данное предложение о рефлексии разумным, позволяет ли оно выразить те юкзейсы, или нет.
                                                                                                      Ну дык об этом и речь! Отсюда, собственно, и нужно «танцевать». А не с заявлений: нужна именно внтуриязыковая по типу в C# или Java. Если вам нужен C# или Java, то, чёрт побери, кто вам запрещает использовать C# или Java? Они проде есть и умирать (к сожалению или к счастью — не знаю) пока не собираются…
                                                                                                  0
                                                                                                  Вот это -уже конструктивнее. И SG7, разумеется, этот блог-пост читал…

                                                                                                  Предложение Герба Саттера по метаклассам всё-таки попроще будет
                                                                                                0
                                                                                                Это уже разговор ни о чём пошёл. Если бы в C++ была рефлексия — язык рванул бы по возможностям на уровень C# и Java, но значительно превосходил бы их в скорости и используемой памяти. Те же GUI, которые на Qt летают, на C#, Java страшно тормозят: IDE, приложения с контролами (таблицы, комбобоксы), в которых много элементов и т.д. и т.п.

                                                                                                Хорошо, что благодаря Qt эти вопросы решаются и сильно расширяют возможности C++.
                                                                                                  0
                                                                                                  Тормознутость GUI связана не с языком, а с GUI фреймворками и использующими их криворукими программистами.

                                                                                                  IDE Visual Studio написана на .NET (WPF), и она совершенно не тормозит.
                                                                                                  IDE Idea, Rider написаны на Java, и они тоже не тормозят.
                                                                                                    +1
                                                                                                    Это были сводки из параллельной реальности?

                                                                                                    1) Напиши таблицу в C++/Qt Excel на тысячи строк и пару десятков столбцов — она не будет тормозить. И в C#/Java хотя бы пару сотен строк (лаги видные невооружённым взглядом) и сравни.
                                                                                                    2) IDE Visual Studio — посмеялся. Сравни с 2008 студией, когда там WPF ещё не было
                                                                                                    3) IDE Idea — пользуюсь каждый день, но сравнивать с реактивным Qt Creator смешно особенно запуск (в идее — около минуты, креатор — несколько секунд), загрузку проекта, скроллинг и навигацию.
                                                                                                      0
                                                                                                      1) И на C# не будет тормозить, если не использовать какой-нибудь DataGrid, обвешанный рефлексией, а использовать более низкоуровневые примитивы. Да, чтобы работало быстро, придётся ручками писать код.

                                                                                                      2) Сейчас подходит к концу 2017 год.

                                                                                                      3) Ну так и пользуйтесь Qt Creator-ом. Всё дело в функционале же.
                                                                                                        0
                                                                                                        Да, чтобы работало быстро, придётся ручками писать код.
                                                                                                        … на C++

                                                                                                        Ну так и пользуйтесь Qt Creator-ом. Всё дело в функционале же.
                                                                                                        Дело не в креаторе или IDEA — пользуемся тем, что нужно для задачи. А в том, что с рефлексией уровень задач решаемых C++ значительно бы вырос.
                                                                                                          0
                                                                                                          А в том, что с рефлексией уровень задач решаемых C++ значительно бы вырос.
                                                                                                          Совершенно необязательно. На примера Java я вижу, что рефлексию, как правило, используют для того, чтобы сделать код «гибчее» и… медленнее и прожорливее!

                                                                                                          Я не уверен, что это прям то, что так уж нужно С++. Но да, в определённых случаях во всём этом есть смысл.
                                                                                                            0
                                                                                                            … на C++

                                                                                                            Это не важно, даже при использовании C# основное процессорное время будет затрачено в user32.dll и gdi32.dll.
                                                                                                            Хотите, чтобы я привёл пример?


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

                                                                                                              0
                                                                                                              Это не важно, даже при использовании C# основное процессорное время будет затрачено в user32.dll и gdi32.dll.
                                                                                                              Почему Qt не затрачивает это процессорное время? Обычная программа на C#/Java работает раза в 2 медленнее, а GUI на порядок медленнее, чем C++/Qt.
                                                                                                                0
                                                                                                                Обычная программа на C#/Java работает раза в 2 медленнее

                                                                                                                Да, работает медленее. И что? Просто не пишите UI, требующий большого количества вычислений.


                                                                                                                а GUI на порядок медленнее, чем C++/Qt.

                                                                                                                А QtSharp?


                                                                                                                И вообще, как GUI может работать медленнее, если он просто сводится в вызову системных функций?

                                                                                                                  0
                                                                                                                  «GUI работает медленнее» — это такой эвфемизм вместо «реакция на событие не происходит за ожидаемые 16 миллисекунд».

                                                                                                                  И да, здесь многоуровневые слои рефлексии и фабрики-фабрик-фабрик ни разу не помогают.
                                                                                                                    0
                                                                                                                    Да, работает медленее. И что? Просто не пишите UI, требующий большого количества вычислений.

                                                                                                                    Тут вопрос стоит так: «справляется или не справляется GUI-поток?». Справляется? — всё хорошо. Не справляется? — плохая программа, тормозит и виснет. А реальная разница в быстродействии может быть и в не вдвое, а процентов на 20
                                                                                                                    И вообще, как GUI может работать медленнее, если он просто сводится в вызову системных функций?

                                                                                                                    потому что Qt использует не нативные виджеты, а собственную реализацию, которая выглядит как нативные виджеты.
                                                                                                                    Да и скорость разработки сейчас — это более важный фактор, чем производительность софта.

                                                                                                                    Итоговая программа всё равно должна удовлетворять требованиям, в т.ч. и по отзывчивости/быстродействию. Не сказал бы, что на с++/Qt программы пишутся прям намного дольше, чем на шарпике. Для некоторых приложений возможно даже, что и быстрее, т.к. меньше времени уйдет на оптимизацию бизнес-логики.
                                                                                                          0
                                                                                                          IDE Visual Studio написана на .NET (WPF), и она совершенно не тормозит.
                                                                                                          IDE Idea, Rider написаны на Java, и они тоже не тормозят.
                                                                                                          Ага. Щаз. Запустите из на Atrom'е на 1GHz и сравините с Visual Studio 6.0 (последняя, не испорченная C#).

                                                                                                          И современная Visual Studio и Idea и Rider — тормозят безбожно. Конечно сделать их тормозами не было основной задачей и за то, что системные ресурсы и потребная мощность процессора возросли на два порядка мы таки кое-что получаем, но… контрпримерами они не являются ни разу, увы.
                                                                                                            +1
                                                                                                            сравините с Visual Studio 6.0 (последняя, не испорченная C#).

                                                                                                            Сравнение, мягко говоря, не особо эквивалентных программ по функционалу.
                                                                                                              –3
                                                                                                              Сравните тот функционал, который есть в обоих. А его, в общем, довольно много: открытие файлов, работа с визардами и т.д. и т.п.

                                                                                                              То, что Visual Studio 6.0 «не умеет» IntelliSense — да, правда, но тормозит-то в Visual Studio 2017 не только IntelliSense, а вообще всё!
                                                                                                                +1
                                                                                                                Сравните интерфейс не открывая солюшены. Могу сказать про VS10, вполне себе уже испорченную дотнетом, что GUI там не тормозит на 1Гц Атоме.

                                                                                                                Тем не менее, для использования современной студии не нужно «особое» оборудование, достаточно обычного офисного компьютера. Она с открытым проектом среднего размера будет потреблять памяти столько же, сколько Firefox с единственной вкладкой Хабра.
                                                                                                            0
                                                                                                            Сделайте s/Idea/CLion/ и сравните результат с KDevelop. Я тут KDevelop ради интереса открыл после где-то года с CLion — божечки, как я отвык от нетормозящего набора текста!

                                                                                                            Потом закрыл обратно, правда, потому что модель кода и всякие рефакторинги-интеллисенсы в CLion лучше, но это не повод тормозить.
                                                                                                              –1
                                                                                                              модель кода и всякие рефакторинги-интеллисенсы в CLion лучше, но это не повод тормозить
                                                                                                              Де нет — в общем-то повод (пока никто не сделал быстрого интерфейса с хорошим интеллисенсом, так что ясно, что это непросто), но… это хороший тест: если человек заявляет, что CLion, Idea, MSVC, или, не дай бог, Eclipse «не тормозят» — это значит либо, что у него плохое зрение, либо что у него очень, очень дорогой и быстрый компьютер — а часто и то и другое одновременно.
                                                                                                                0
                                                                                                                Де нет — в общем-то повод

                                                                                                                Ну как же, ну есть же многопоточность и все дела.

                                                                                                                Просто IDE для плюсов самих по себе не так уж много, чтобы была какая-то разумная статистика.

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

                                                                                                                У меня дома i7 3930k с 64 гигами оперативки. Только этому CLion хоть тредриппер купи — он всё равно при подвисании только одно ядро жрёт.
                                                                                                                  0

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


                                                                                                                  Ну и важный момент — мои проекты не очень большие (~500 файлов, 3М текста), а студию я использую голую, т.к. с плагинами (Resharper, VAssist) она действительно тормозит.

                                                                                                                    0
                                                                                                                    Я бы использовал Atom, если бы не знал vim. Для Idris, правда.

                                                                                                                    Но речь не о том, сколько ресурсов нужно софтине для интеллисенса и прочих рефакторингов, а о том, что ввод текста лагает.
                                                                                                              –1
                                                                                                              Хорошо, что благодаря Qt эти вопросы решаются и сильно расширяют возможности C++.
                                                                                                              Так они «решаются» или «если бы в C++ была рефлексия — язык рванул бы»?

                                                                                                              Вы уж выберите что-то одно, а?

                                                                                                              Это уже разговор ни о чём пошёл.
                                                                                                              Я понимаю, что для верующих обсуждать вопрос их веры бессмысленно, но вроде как пока что «школы адептов рефлексии» не наблюдается, так что вопросы нужно обсуждать по-существу, а не в духе «примите нашу веру — и будет вам ЩАСТЯ».
                                                                                                                0
                                                                                                                Qt — не стандарт, не все хотят дополнительные библиотеки тянуть в свой проект только из-за рефлексии.
                                                                                                                  –1
                                                                                                                  А тогда непонятно, чем вам рефлексия в языке поможет. «Внутриязыковая» рефлексия в C++ уже и так достаточно развита. То, что нужно — это «внеязыковая» рефлексия позволяющая как-то общаться с библиотеками и скриптами не написанными на C++.

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

                                                                                                                  Вы уж определитесь — вам шашечки или ехать.
                                                                                                                    0
                                                                                                                    А тогда непонятно, чем вам рефлексия в языке поможет. «Внутриязыковая» рефлексия в C++ уже и так достаточно развита.
                                                                                                                    Это какая, например?

                                                                                                                    То, что нужно — это «внеязыковая» рефлексия позволяющая как-то общаться с библиотеками и скриптами не написанными на C++.
                                                                                                                    Ничего подобного не требовалось. Нужна именно внтуриязыковая по типу в C# или Java.
                                                                                                                      –1
                                                                                                                      Это какая, например?
                                                                                                                      Magic Get, к примеру. Коего вполне достаточно для RPC, например. Или сериализации.
                                                                                                                        0
                                                                                                                        Нужна именно внтуриязыковая по типу в C# или Java.

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

                                                                                                                          0
                                                                                                                          Не «бессмысленно», а «не нужно». Это будет другой язык с другой областью применения. Как какой-нибудь C++/CLI.
                                                                                                                      0
                                                                                                                      Тем более, что в Qt рефлексия очень ограничена и вообще рантайм.
                                                                                                              +1
                                                                                                              А чего именно вы хотите от рефлексии? А то как-то я спокойно без неё живу с type_traits… чего я такого важного теряю?

                                                                                                              Смотря что вы делаете.

                                                                                                              Я бы хотел, ну… Слышали про Template Haskell что-нибудь? Но это так, недостижимые грёзы. В мире С++ я бы хотел написать один раз один метакласс, который потом мне сгенерит DBus-обёртки для моего типа. Или будет проксировать вызовы методов через какой-нибудь [другой] RPC-механизм. Или сгенерирует методы для сериализации-десериализации. Или для работы с представлением типа в БД.

                                                                                                              Конкретно последнее я, конечно, могу и сам написать, но придётся делать всякие некрасивые BOOST_FUSION_ADAPT_STRUCT, да и реализация выглядит совсем не как образец читабельности. Надо бы там, кстати, что-нибудь придумать, чтобы селекты писать как Select(fieldName == "meh") вместо Select(_0 == "meh"), но кроме макросни либо нечитаемых указателей на члены ничего в голову не лезет.
                                                                                                                0
                                                                                                                Слышали про Template Haskell что-нибудь?
                                                                                                                Слышал, слышал. Про то, как вызывать его из Java или C++ библиотеки — не слышал.

                                                                                                                В мире С++ я бы хотел написать один раз один метакласс, который потом мне сгенерит DBus-обёртки для моего типа.
                                                                                                                Ну то есть опять — что-то для внешнего потребителя. Который не существует на этапе компиляции программы. Тут сразу встаёт задача классификации этих потребителей и их «хотелок». Так как они «живут» вне C++ кода, то про них и их «желания»/«ограничения» мы знаем очень мало. И пока не будем знать достаточно — хорошего решения не придумаем.

                                                                                                                Или будет проксировать вызовы методов через какой-нибудь [другой] RPC-механизм.
                                                                                                                Опять-таки: чего вы от него хотите.

                                                                                                                Или сгенерирует методы для сериализации-десериализации.
                                                                                                                Magic Get делает это в рамках C++14.

                                                                                                                Или для работы с представлением типа в БД.
                                                                                                                А тут — снова возникает вопрос: что конкретно и зачем.

                                                                                                                То есть так-то понятно, что рефлексия — это хорошо… но вот что именно нужно и насколько оно востребовано… дьявол, как обычно, в деталях. C++ — всё-таки компилируемый язык… Мне очень нравится Beautiful Soup — но я понимаю что подобные трюки в C++ не сработают если мы захотим в «жёсткую структуру» всё загнать: на этапе компиляции мы ж не знаем какие теги возможны и какие в них могут быть субтеги! А если всё делать гибко поверх std::any — ну так там и рефлексия сразу в таком дереве будет!
                                                                                                                  0
                                                                                                                  Слышал, слышал. Про то, как вызывать его из Java или C++ библиотеки — не слышал.

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

                                                                                                                  И ни для чего из этого не нужно прямой поддержки в ядре языка, всё это библиотечный код, в ядре языка достаточно просто уметь управляться с AST.

                                                                                                                  Ну то есть опять — что-то для внешнего потребителя.

                                                                                                                  Почему? Для меня любимого. Просто написать метакласс для DBus один раз приятнее и веселее, чем методично кодогенерировать или писать обёртки руками. И я даже знаю это всё на этапе компиляции.

                                                                                                                  Опять-таки: чего вы от него хотите.

                                                                                                                  Я хочу не только агрегаты туда-сюда гонять, но и вызовы функций, не перечисляя руками эти функции, например.

                                                                                                                  А тут — снова возникает вопрос: что конкретно и зачем.

                                                                                                                  Не писать тонны бойлерплейта руками. Хочу по
                                                                                                                  struct Person
                                                                                                                  {
                                                                                                                      PKey<int> m_id;
                                                                                                                      int m_age;
                                                                                                                      std::string m_name;
                                                                                                                  };
                                                                                                                  
                                                                                                                  struct Payment
                                                                                                                  {
                                                                                                                      PKey<int> m_id;
                                                                                                                      References<&Person::m_id> m_person;
                                                                                                                      double m_amount;
                                                                                                                  };
                                                                                                                  

                                                                                                                  сгенерить две таблички и все функции для вставки-удаления-обновления этих записей, а также селекта по всем возможным полям и ограничениям, типа select(&Payment::m_amount >= 1000 && &Payment::m_person == &Person::m_id && &Person::m_age < 25). Вышеупомянутая хренотень делает почти это, только вместо &Payment::m_amount надо писать _2 (обращения по индексу), и кросстабличные запросы я пока вроде не запилил.

                                                                                                                  Конечно, вы правы — она это уже делает, но есть чувство, что через правильную рефлексию оно всё будет выглядеть куда лучше.

                                                                                                                  Это как сравнивать SFINAE-костыли и полноценные концепты.
                                                                                                                    +1
                                                                                                                    И ни для чего из этого не нужно прямой поддержки в ядре языка, всё это библиотечный код, в ядре языка достаточно просто уметь управляться с AST.
                                                                                                                    Этим путём идёт rust… посмотрим что из этого выйдет.

                                                                                                                    Конечно, вы правы — она это уже делает, но есть чувство, что через правильную рефлексию оно всё будет выглядеть куда лучше.
                                                                                                                    А в этом, собственно, и проблема: поскольку через костыли это делается уже сейчас — то никому неинтересно добавлять «какую-нибудь» рефлексию. «Какая-нибудь» уже есть (и не одна, да).

                                                                                                                    Это как сравнивать SFINAE-костыли и полноценные концепты.
                                                                                                                    Не обязательно SFINAE. DWARF — это тоже рефлексия и тоже стандарт, хотя и не ISO C++.

                                                                                                                    В том-то и дело, что уже много чего есть и вопли «адептов рефлексии» — это «пена», на которую не стоит обращать много внимания.

                                                                                                                    Да, рефлексия нужна. Но она не нужна «вот прям щаз» («костыльных» решений — вагон и маленькая тележка) — лучше подумать и сделать хорошо. Над этим — работают, хотя и медленно.
                                                                                                                      0
                                                                                                                      Этим путём идёт rust… посмотрим что из этого выйдет.

                                                                                                                      В каком-то смысле да, это любопытный эксперимент даже при наличии TH. Хотя бы потому, что синтаксис раста куда богаче синтаксиса хаскеля, поэтому TH на хаскеле выглядит сильно проще.

                                                                                                                      никому неинтересно добавлять «какую-нибудь» рефлексию. «Какая-нибудь» уже есть (и не одна, да).

                                                                                                                      Поэтому я и говорю о правильной.

                                                                                                                      Но она не нужна «вот прям щаз» («костыльных» решений — вагон и маленькая тележка) — лучше подумать и сделать хорошо. Над этим — работают, хотя и медленно.

                                                                                                                      Конечно. Надо просто не забывать, что само оно не придумается, и надо думать. Ну или пинать чуваков из Яндекса, чтобы они пинали Комитет, чтобы он думал.
                                                                                                                0
                                                                                                                Это на уровне — зачем вам полноценные строки в C?
                                                                                                                Я обожаю чистый C, и спокойно обхожусь без строк, но их отсутствие заставляет меня выбрать другой язык для некоторых задач, где отлично бы подошел C, были бы в нем строки.
                                                                                                                Также и тут, это сильно ограничивает возможности C++, хотя-бы отсутствием возможности сделать автоматическую сериализацию. И да, я видел несколько попыток сделать это макросами и набором костылей — это плохой способ, в котором разбирается только автор.
                                                                                                                  –1
                                                                                                                  И да, я видел несколько попыток сделать это макросами и набором костылей — это плохой способ, в котором разбирается только автор.
                                                                                                                  Кто вам сказал, что сериализация, которую напишут поверх рефлексии будет лучше?

                                                                                                                  Это тогда уж нужно добавлять библиотеку сериализации в стандарт — а это совсем-совсем другая история. Её, как бы, можно сделать уже сейчас через magic_get, но… не делают. Пользуют всякие протобуфы, Cap’n Proto или даже JSON'ы.
                                                                                                                    +1
                                                                                                                    Простите, но вы — не пробиваемый, я привел достаточно аргументов, зачем нужна рефлексия.
                                                                                                                      0
                                                                                                                      Вы написали много слов, но не привели ни одного конкретного убедительного примера. Только общие слова в стиле «на дворе XXI век, а у нас рефлексии нету».

                                                                                                                      Хочется увидеть примеры, которые были бы осмысленны в рамках C++. «Эмуляция рефлексии» в Qt к подобным примерам отнесена быть не может: как уже верно заметили Qt был сделан именно так, потому что хотелось поддерживать «весьма унылые компиляторы». Другие современные библиотеки спокойно существуют без рефлексии.

                                                                                                                      Сериализация через рефлексию — это круто и здорово… только вот в Java, где вроде как рефлексия и есть и сериализация через неё есть RPC делают не через сериализацию поверх рефлексии, а через JSON, XML и многое другое. А рефлексию используют для того, чтобы сделать программы «гибчее»… и тормознее. А последнее — это уже совсем не C++-way.

                                                                                                                      Пока что единственный заслуживающий внимания пример — это генерация Dbus-биндингов. Тут — действительно рефлексия нужна и в том виде, в каком она есть недостаточна.

                                                                                                                      Все же остальные примеры — скорее о том, как с помощью рефлексии что-то сделать плохо (медленно, небезопасно и с затратой кучи памяти). Вряд ли желание кого-то что-то делать «быстро и плохо» — может являться причиной для добавления новой фичи в язык. Языков, на которых получить более быструю разработку за счёт качества получаемого продукта — достаточно много и без C++.
                                                                                                                        0
                                                                                                                        <сарказм>
                                                                                                                        Приведите хоть один убедительный пример зачем в C++ есть шаблоны?
                                                                                                                        Много проектов, которые генерируют код сторонними скриптами, есть 101 способ обойтись без шаблонов. Шаблоны лишь затрудняют чтение кода. Зачем они нужны не ясно.
                                                                                                                        </сарказм>
                                                                                                                          0
                                                                                                                          Знаете, мне сейчас эта дискуссия напомнила дискуссии в сообществе Rust по поводу нужности типов высшего порядка. Много кто говорил, что нужно обязательно добавить HKT. Зачем — ну они позволяют решать много проблем, в Haskell и др. успешно применяются. Только в итоге ответом было: да, задачи есть, да, их можно решить HKT. В других языках это может хорошо работать и быть хорошим решением. Но Rust имеет свои особенности и напрямую HKT не ложатся на общую структуру языка. Но есть другой способ получить почти то же самое, который решает вроде бы все задачи, которые решает HKT и при этом хорошо интегрируется в язык.

                                                                                                                          Так вот, даже если в других языках это принято делать рефлексией, в C++ большинство этих задач можно решить без неё. В некоторых случаях рефлексия таки могла бы быть удобной (Dbus биндинги например). Но а) рефлексия не очень ложится на общую структуру и цели C++, б) Если уж очень надо — действительно есть костыль в виде той же кодогенерации внешними скриптами. Если сообщество придумает способ органично вписать рефлексию или что-то её заменяющее — наверняка это примут в стандарт. А пока — имеем то, что имеем. В конце концов есть другие языки, если C++ для конкретных задач не нравится использовать.
                                                                                                                            0
                                                                                                                            <сарказм>
                                                                                                                            Приведите хоть один убедительный пример зачем в C++ есть шаблоны?
                                                                                                                            Много проектов, которые генерируют код сторонними скриптами, есть 101 способ обойтись без шаблонов. Шаблоны лишь затрудняют чтение кода. Зачем они нужны не ясно.
                                                                                                                            </сарказм>
                                                                                                                            Уберите теги "</сарказм>", пожалуйста.

                                                                                                                            Потому что ваши слова правильны и справедливы. Как же так: как я, фанат таких вещей, как Boost.Hana или любитель что-нибудь этакое сотворить через шаблоны могу так говорить?

                                                                                                                            А вот так. Шаблоны, в том виде, в котором они изначально были задуманы — практически никому не нужны. Я не могу вспомнить ни одного проекта, в котором я бы использовал basic_string, но не std::string, а всякие mapы — вполне могли бы существовать в виде Ada-стайл genericов.

                                                                                                                            А шаблоны… шаблоны — нет, не нужны. Что было нужно (и сейчас нужно!) — так это средства метапрограммирования. Однако их — в С++ не было. А шаблоны — были. И вот, когда Степанов придумал как с помощью шаблонов можно сделать плохое, кривое, но… всё-таки, работающее метапрограммирование — язык C++ стал чем-то большим.

                                                                                                                            Однако то, что метапрограммирование в нём — плохое и неудобное, а шаблоны по-прежнему не нужны — накладывает особый отпечаток на программистов на C++. Они плавают на перевёрнутом «вверх ногами» Боинге, а тот факт, что для этого нужно тщательно следить, чтобы ни через один иллюминатор не просочилась вода — считают достоинством и объясняют новичкам, что «так и надо».

                                                                                                                            Нет — так, не надо. Надо бы — корабль использовать. Но… корабля у нас нет, а вот этот самый Боинг с рядами гребцов — у нас есть. Но раз мы плаваем на Боинге, то и некоторые решения у нас оказываются… специфические. И вовсе не факт, что прикрутив на этот Боинг гребной винт мы получим облегчение: совершенно не факт, что эта конструкция будет лучше плавать — уж очень она отличается от той, для которой предлагаемый винт изначально предлагался…
                                                                                                                              +1
                                                                                                                              И вот, когда Степанов придумал как с помощью шаблонов можно сделать плохое, кривое, но… всё-таки, работающее метапрограммирование — язык C++ стал чем-то большим.
                                                                                                                              Это когда это Степанов придумал метапрограммирование на шаблонах? Степанов реализовал на шаблонах C++ свои идеи по обобщенному программированию, которые у него были еще с начала 1980-х. А метапрограммирование на шаблонах — это, как минимум, 1995-й год, когда STL уже был и его включали в первый стандарт C++.
                                                                                                                                0
                                                                                                                                Да, вы [почти] правы: как гласит wiki первая метапрограмма — это Erwin Unruh, 1994й, действительно к Степанову отношения не имеет.

                                                                                                                                Но остального — это не меняет: шаблоны в современном C++ используются почти исключительно «не по назначению», все связанные с ними проблемы (бинарники в 100500 магабайт и прочее) — имеют место быть, так что тот факт, что из-за мелкой случайности «история пошла совсем не туда» — отстаётся в силе.

                                                                                                                                Я думаю в альтернативном мире, где не было бы частичной специализации (то есть там, где шаблоны были бы дженериками), и где в C++ пришлось бы добавлять и нормальную рефлексию и нормальное метапрограммирование — всё было бы по-другому и, скорее всего, лучше и удобнее… но мы не живём в этом мире, увы… и попытки скрестить то, что есть с тем, что, как бы, хочется способны родить тааакого урода, что использовать его не захочется никому и ни для чего…
                                                                                                                                  0
                                                                                                                                  шаблоны в современном C++ используются почти исключительно «не по назначению»
                                                                                                                                  Не следует говорить за всех.
                                                                                                                                0
                                                                                                                                вы, как и большинство других, забываете, что с++ развивался эволюционно. Сначала люди вопили «надоел препроцессор! Сделайте параметризуемые типы». Voila. Потом люди заметили, что со скрежетом можно реализовать на шаблонах какую-то compile-time логику и стали этим пользоваться, вопя «неудобно, сделайте чтоб было лучше». В языке появились constexpr (if), variadic'и, SFINAE и пр. Снова не то: некоторые вещи пишутся очень уж многословно. Тут на выручку спешат концепты, но…

                                                                                                                                Людям то «виднее». Им подавай «как в ***», где *** — каждый второй ЯП. Им надо «чтобы просто вот такой код генерировался с набором параметров». Люди хотят еще один препроцессор…

                                                                                                                                Вспоминается анекдот: «невозможно понять, чего хочет женщина: сам бог дал ей брови, но она их сбрила и нарисовала карандашиком».

                                                                                                                                Разве что с T&& в шаблонах реально бред вышел
                                                                                                                                  0
                                                                                                                                  И всё это можно было бы решить разработкой нового языка. Но проблема в том, что этот язык никто не будет использовать, потому что он не будет совместим с C++.

                                                                                                                                  Если бы компилирование было двухэтапое: сначала в VM, затем в нативный код, то это было бы просто. Например, существует множество совметимых друг с другом языков, которые компилируют в MSIL или JVM.
                                                                                                                                    +1
                                                                                                                                    и что теперь, каждую проблему каждого ЯП решать созданием нового ЯП? А он точно будет лучше? И окупится ли для программиста переход на этот новый язык вместо использования «старого доброго»?
                                                                                                                              +1
                                                                                                                              Пока что единственный заслуживающий внимания пример — это генерация Dbus-биндингов. Тут — действительно рефлексия нужна и в том виде, в каком она есть недостаточна.

                                                                                                                              А чего не в БД сохранять-доставать-обновлять? :(

                                                                                                                              А была бы нормальная работа с AST, включая Oxford brackets, можно было бы сделать, скажем, библиотечную интерполяцию строк. Или дёрганье шелла, опять же, с интерполяцией и интерпретацией результата. Или даже другой язык дёргать, как вы догадались, тоже с интерполяцией. Или, в конце концов, кодогенерировать.
                                                                                                                                –1
                                                                                                                                А была бы нормальная работа с AST, включая Oxford brackets, можно было бы сделать, скажем, библиотечную интерполяцию строк.
                                                                                                                                «Нормальная работа с AST» — это, как бы, уже далеко не возможность отслеживать и модифицировать собственную структуру и поведение во время выполнения. Это возможность формировать новые обьекты во время компиляции — о чём пока и близко речи не идёт.
                                                                                                                                  +1
                                                                                                                                  Я как-то всегда возможность формировать новые объекты включал в понятие «модифицировать» в этом контексте.
                                                                                                                                    +1
                                                                                                                                    Вы не на то слово отреагировали: тут важно не «модифицировать», а «во время исполнения».

                                                                                                                                    Тут уже начинается софистика: может ли быть в компилируемом языке рефлексия вообще или нет.

                                                                                                                                    Принципиальная позиция Страуструпа (с момента создания языка) — в обьектный код классы, шаблоны и прочее не попадают. Попадает некая «выжимка», необходимая и достаточная для того, чтобы конструкции языка работали.

                                                                                                                                    Соответственно «модификация» очевидным образом ограничена хотя бы тем фактом, что во время исполнения шаблонов нет, а от типов, фактически, остаётся одно название (и то если -fno-rtti не сказали).

                                                                                                                                    То, что вы «вытащите» наружу — вы, во время исполнения, сможете модифицировать. И до переменных добраться и прочее. Уже сейчас много такого можно сделать. Но вот во время компиляции — нет, там многие вещи запрещены (как и вообще в constexpr много чего запрещено).

                                                                                                                                    А без этого ваши Oxford brackets будут работать… странно: вам придётся куда-то передать список переменных и строки, а потом это всё в рантайме связать.

                                                                                                                                    Насколько это будет полезно — сложно сказать…
                                                                                                                                      +1
                                                                                                                                      А, и правда.

                                                                                                                                      Только ведь тогда всё наоборот получается: я говорю о рефлексии времени компиляции. Когда все эти Oxford brackets во время компиляции же превращаются в, ну я не знаю, соответствующие вызовы функций, например, которые, конечно, вызовутся в рантайме, но превращение происходит всё равно во время компиляции.

                                                                                                                                      Надо, в общем, время компиляции и время выполнения разделять. Благо, отсутствие завтипов позволяет.
                                                                                                                            +1
                                                                                                                            Кто вам сказал, что сериализация, которую напишут поверх рефлексии будет лучше?

                                                                                                                            Потому что у меня есть опыт написания сериализации хоть в бинари, хоть в JSON, хоть в БД через хаскелевские Generic'и (которые куда слабее TH), равно как и написания библиотек, предоставляющих таковую сериализацию, и получается вполне неплохо.
                                                                                                                              0
                                                                                                                              Потому что у меня есть опыт написания сериализации хоть в бинари, хоть в JSON, хоть в БД через хаскелевские Generic'и (которые куда слабее TH), равно как и написания библиотек, предоставляющих таковую сериализацию, и получается вполне неплохо.
                                                                                                                              Интересно. Надеюсь что вы не забыли, что в контексте этой ветки «внолне неплохо» == способ, в котором разбирается не только автор, так что сразу вопрос: какое количество людей, кроме вас, пользуется вашей сериализацией и что они о ней думают…
                                                                                                                                +1
                                                                                                                                Вполне себе. Приняли пулл-реквест в библиотеку для работы с БД, пользуются. Каким-нибудь Aeson или Cassava вообще кто только не пользуется. Или в бинарный формат.

                                                                                                                                Оверхед от этого при этом никакой.
                                                                                                                +2
                                                                                                                Зашёл сюда посмотреть шутки про «Во все тяжкие»)
                                                                                                                  0
                                                                                                                  better call Soul тоже ничего, мне даже больше понравился.
                                                                                                                    –1
                                                                                                                    Скоро новый сезон =)
                                                                                                                  –3
                                                                                                                  Я конечно прошу прощения, но вам не кажется что пример оператора spaceship, который показан в начале статьи, не имеет особого смысла? Когда и в каком сценарии вы будете сравнивать точки в трехмерной системе координат, сравнивая поочередно x, потом y, потом z? Это нонсенс! Оператор == реализован логично, это понятно. А вот < и > совершенно безумно. Вот если бы сравнение было по модулю sqrt(x*x+y*y+z*z) я бы еще понял.

                                                                                                                  Формализация поведения оператора <=> вручную тоже получилась нечитабельной. Почему нельзя дать пользователю задать критерий сравнения как функцию, которая возвращает некий тип T, для которого однозначно реализованы операторы ==,<,>? Тогда можно было бы один раз посчитать модуль точки и использовать это значение во всех сравнениях.
                                                                                                                    +3
                                                                                                                    Когда и в каком сценарии вы будете сравнивать точки в трехмерной системе координат, сравнивая поочередно x, потом y, потом z?
                                                                                                                    Когда захотите засунуть из в std::map, к примеру.

                                                                                                                    Вот если бы сравнение было по модулю sqrt(x*x+y*y+z*z) я бы еще понял.
                                                                                                                    А этот безумный вариант вы где хотите использовать?

                                                                                                                    Почему нельзя дать пользователю задать критерий сравнения как функцию, которая возвращает некий тип T, для которого однозначно реализованы операторы ==,<,>?
                                                                                                                    Это лишает затею всякого смысла. Дело в том что на многих процессорах можно достаточно дёшево посчитать <=> для чисел (и не только — см. strcmp) — а дальше из «элементарных» построений над числами можно уже построить что угодно.

                                                                                                                    Но ясно же, что на практике всё это будет строиться в основном над строками — где как раз подобные построения уместны и разумны.

                                                                                                                    P.S. Пример всё равно не очень удачен. Текущее положение дел как-то уж очень страшно описано. Что мешало написать не как на C++98, а как на C++11:
                                                                                                                    bool operator==(p_ref a, p_ref b) {
                                                                                                                        return std::tie(a.x, a.y, a.z) == std::tie(b.x, b.y, b.z);
                                                                                                                    }
                                                                                                                    
                                                                                                                    bool operator< (p_ref a, p_ref b) {
                                                                                                                        return std::tie(a.x, a.y, a.z) < std::tie(b.x, b.y, b.z);
                                                                                                                    }
                                                                                                                      0
                                                                                                                      Так пример же мотивирующий, так что «плохой» вариант должен быть по длиннее :)
                                                                                                                        +1
                                                                                                                        P.S. Пример всё равно не очень удачен. Текущее положение дел как-то уж очень страшно описано. Что мешало написать не как на C++98, а как на C++11:

                                                                                                                        Так писать тоже, кстати, не надо, потому что довольно легко с одной из сторон указать, скажем, b вместо a, либо какой-нибудь член повторить два раза. Проще сделать метод, возвращающий тупл для текущего объекта, там пространство для ошибок меньше, и они заметнее.
                                                                                                                        +1
                                                                                                                        Почему нельзя дать пользователю задать критерий сравнения как функцию, которая возвращает некий тип T, для которого однозначно реализованы операторы ==,<,>?

                                                                                                                        Ну напишите один раз в хедере где-нибудь шаблонный operator==/operator>/etc, включенный только для типов, имеющих метод as_tuple(), а в своих типах пишите
                                                                                                                        auto as_tuple() const
                                                                                                                        {
                                                                                                                            return std::tie(field1, field2, field3);
                                                                                                                        }
                                                                                                                        


                                                                                                                        А так — очень часто в операции сравнения не нужен физический смысл (чем лексикографическое сравнение векторов плохо, кстати?), а нужна всего лишь корректность и гарантия, скажем, полного порядка для возможности сортировки или запихивания в мапы. Тогда в плюсах пишется соответствующий оператор, сравнивающий всё подряд, это неудобно и лишняя писанина тогда как в хаскеле пишется всего лишь deriving(Eq, Ord).

                                                                                                                        Ещё бы добавили автоматический вывод функций для хеширования, вообще было бы ништяк.
                                                                                                                      • UFO just landed and posted this here
                                                                                                                          +1
                                                                                                                          osyncstream

                                                                                                                          Не знаток С++, однако есть же мьютексы, зачем городить очередную сущность?
                                                                                                                            0
                                                                                                                            osyncstream работает без мьютексов под капотом. Так что он немного производительнее и намного лучше масштабируется.
                                                                                                                            0
                                                                                                                            starts_with и ends_with для строк

                                                                                                                            Давно пора.
                                                                                                                              +3
                                                                                                                              Было бы лучше, если бы это было как свободные функции =) Но нам этого ещё долго ждать. Следующий великий шаг — добавление std::trim в библиотеку :-)
                                                                                                                              +2
                                                                                                                              Когда будет нормальная рефлексия?
                                                                                                                                +1
                                                                                                                                Похоже что никогда
                                                                                                                                  0
                                                                                                                                  Не в C++20. Надеюсь что в C++23
                                                                                                                                    0
                                                                                                                                    Ложка дорога к обеду. Пока что Qt — наше всё в плане рефлексии! :)
                                                                                                                                      0
                                                                                                                                      Боюсь самые лояльные адепты C++ плюнут на это все, за этот срок.
                                                                                                                                    +1
                                                                                                                                    Атомарные умные указатели — это что?
                                                                                                                                      0
                                                                                                                                      А что там с локализацией и юникодом? Где почитать, что уже есть и чего ещё нет?
                                                                                                                                        0
                                                                                                                                        Дык эта. Как обсуждалось единороги — уже давно есть.

                                                                                                                                        Или вы о чём-то другом?
                                                                                                                                          +1
                                                                                                                                          Локализация — поддержка перевода текстовых строк на разные языки. То есть то, чем занимается, например, GNU gettext, а также всякие форматы дат и т.п.

                                                                                                                                          Поддержка юникода — классификация символов, поиск/замена, регулярки, конвертация из/в других кодировок. То есть то чем занимается ICU. Но не только — важна поддержка перекодировки для локальных имён файлов/каталогов, например. Или конвертация вывода в std::cout из юникода в локальную кодировку «на лету» и т.п.

                                                                                                                                          На сколько эти все работы завершены и что ещё не сделано?
                                                                                                                                            0
                                                                                                                                            Это ещё хлеще, чем мертворождйнный высер P0267.

                                                                                                                                            Сейчас только что посмотрел на сборку Android'а: вся стандартная библиотека (C и C++ вместе) — порядка 2MB, в то время, как только ICU — это две библиотеки на 4MB плюс файл данных на 20MB.

                                                                                                                                            То есть вы хотите из-за того, что вам лично захотелось GUI изобразить увеличить стандартную библиотеку в десять с лишним раз? Губозакатывательные машинки продаются в соседнем отделе.

                                                                                                                                            Вот в виде отдельного опционального TS — пожалуйста, милости просим. А в стандарную библиотеку — ну никак. Извините.
                                                                                                                                              0
                                                                                                                                              работу с локалями можно вынести в отдельную либу, поставляемую рядом со стандартной, по аналогии с atomic либой в gcc. Если она не нужна, то она просто не линкуется.
                                                                                                                                                0
                                                                                                                                                Я правильно понял, что прогресса в этой области нет и комитет по стандартизации занимается… гм… другими полезными (на их взгляд) нововведениями?

                                                                                                                                                Сегодня, на секундочку, 2017 год и отсутствие такой, в сущности, базовой функциональности это какой-то позор…

                                                                                                                                                Я не вижу никакой проблемы с увеличением размера библиотеки. Для всяких встраиваемых недокомпьютеров (а телефоны к ним не относятся), как уже указал Antervis, вполне можно сделать либо обрезанную библиотеку, либо отдельный модуль.

                                                                                                                                                Решение этой задачи необходимо, конечно же, не только для графического интерфейса пользователя, но практически везде, где есть обработка текста, файловая система или хотя бы текстовые сообщения об ошибках. Не хочу умалять и необходимость стандартной, продуманной библиотеки графического интерфейса пользователя, но это архисложнейшая задача на многие годы вперёд, которая потребует и вышеуказанное.
                                                                                                                                                  0
                                                                                                                                                  Для всяких встраиваемых недокомпьютеров (а телефоны к ним не относятся), как уже указал Antervis, вполне можно сделать либо обрезанную библиотеку, либо отдельный модуль.
                                                                                                                                                  Ну и? Кто будет это делать? Кстати почему это «телефоны к ним не относятся»? ICU отсуствует в Android NDK — ровно по причине того, что её размеры слишком велики, а API имеющейся библиотеки нестабилен (то есть она не может быть частью системы).

                                                                                                                                                  Да, там периодически происходят разные разговоры на тему выделения стабильной части, которую уже можно было бы включить в NDK… но пока — это всего лишь разговоры! А вы хотите сразу: бабах — и в ферзи. Извините, но пешка E2-E8 не ходит…

                                                                                                                                                  Решение этой задачи необходимо, конечно же, не только для графического интерфейса пользователя, но практически везде, где есть обработка текста, файловая система или хотя бы текстовые сообщения об ошибках.
                                                                                                                                                  Это с какого-такого перепугу? Файловой системе — это не нужно: при использовании UTF-8 подход «имя файла — это произвольная последовательность байт, не включающая в себя символов '\0' и '\'» — отлично работает. Переводить же низкоуровневые сообщения об ошибках — глупость несусветная: для них главное — возможность засунуть их в Гугл или Яндекс, чем перевод будет активно мешать.

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

                                                                                                                                                  Будут модули, будут опциональные компоненты — тогда и можно будет говорить о локализации или графике. А пока — нет.
                                                                                                                                                    0
                                                                                                                                                    Ну и? Кто будет это делать? Кстати почему это «телефоны к ним не относятся»? ICU отсуствует в Android NDK — ровно по причине того, что её размеры слишком велики

                                                                                                                                                    Для встраиваемых систем уже есть обрезанные версии библиотек на любой вкус. Для телефонов же 20МБ это не проблема, о чём вообще разговор???
                                                                                                                                                    Файловой системе — это не нужно: при использовании UTF-8 подход «имя файла — это произвольная последовательность байт, не включающая в себя символов '\0' и '\'» — отлично работает.

                                                                                                                                                    При глобальном использовании UTF-8 никакой проблемы и не возникло бы изначально, но (к сожалению) это не так.
                                                                                                                                                      0
                                                                                                                                                      Файловой системе — это не нужно: при использовании UTF-8 подход «имя файла — это произвольная последовательность байт, не включающая в себя символов '\0' и '\'» — отлично работает.

                                                                                                                                                      Проблема в том, что не любая последовательность байт является корректной строкой UTF-8. Напомню, что в Linux имя файла — это набор байт, а в Windows — UTF16 (раньше была UCS2). И способов обрабатывать это кросс-платформенно просто не существует.

                                                                                                                                                        0
                                                                                                                                                        Проблема в том, что не любая последовательность байт является корректной строкой UTF-8.
                                                                                                                                                        Однако любая последовательность байт является корректным именем файла.

                                                                                                                                                        в Windows — UTF16 (раньше была UCS2).
                                                                                                                                                        И сейчас, на самом деле, UCS2. Невалидные UTF16-названия файловая система принимает на ура, независимость от регистра тоже распространяется только на символы с кодами до 65535 и т.д. и т.п. Так что… это только всякие диалоги открытия файлов делают вид, что там UTF16.

                                                                                                                                                        Если вы GUI не делаете, то и юникод вам, в общем, не нужен.

                                                                                                                                                        И способов обрабатывать это кросс-платформенно просто не существует.
                                                                                                                                                        Ну это к Microsoft'у вопросы.
                                                                                                                                                      0
                                                                                                                                                      Сегодня, на секундочку, 2017 год и отсутствие такой, в сущности, базовой функциональности это какой-то позор…

                                                                                                                                                      Она далеко не везде и не во всех применениях базовая. Из личного опыта — оно нужно, наверное, процентах в пяти задач, которые я решаю.
                                                                                                                                                        +1
                                                                                                                                                        Она далеко не везде и не во всех применениях базовая. Из личного опыта — оно нужно, наверное, процентах в пяти задач, которые я решаю.
                                                                                                                                                        У «адептов рефлексии» — оно базовая. Потому что они обьекты с тремя интами через рефлексию создают, блин.

                                                                                                                                                        А потом удивляются почему GUI тормозит, да.
                                                                                                                                              0
                                                                                                                                              КДПВ, которую постеснялся вставить в коммент


                                                                                                                                              За сахаром не видно чая… Интересно, каким образом расставляют приоритеты вводимых в язык фич? Какой смысл набивать его и без того пухлый каркас всё новыми (пусть и полезными) красивостями, когда имеются серьёзные пробоины ниже ватерлинии? За счёт чего будет расширяться комьюнити языка, у которого интеграция нового пакета — задача из категории стыковок космических станций? Кто будет выбирать язык, в котором десятистраничные ошибки генерации типов во время компиляции — это норма? Вряд ли за счёт добавления щепотки новых сладеньких конструкций С++ станет привлекательнее для неофитов. А без свежей крови языки становятся латынью.

                                                                                                                                              Я очень люблю С++ и рад, что он пока худо-бедно держится на пятых местах всяких рейтингов. Однако каждый новый стандарт заставляет грустить. Не тем козыряют, как по мне. Совсем не тем, чем следовало бы.
                                                                                                                                                +1
                                                                                                                                                Кто будет выбирать язык, в котором десятистраничные ошибки генерации типов во время компиляции — это норма?

                                                                                                                                                Должно быть починено Concepts TS, уже будет в C++20.

                                                                                                                                                За счёт чего будет расширяться комьюнити языка, у которого интеграция нового пакета — задача из категории стыковок космических станций?

                                                                                                                                                Это общая проблема всех языков программирования. И никакой пакетный менеджер это не решает, ошибки с pip/maven/gem/conan всё еще проще чинить копированием нужного пакета в репозитарий и выкидыванием пакетного менеджера.
                                                                                                                                                  0
                                                                                                                                                  Это общая проблема всех языков программирования.

                                                                                                                                                  Нет, не любого. В том же C#, например, для подключения библиотеки достаточно одного файла — сборки. В C++ же такой фокус не прокатит — изволь тащить с собой все хедеры, исходники или статические либы, причём последние не только системо-, но и компиляторозависимы. Ещё надо не забыть про условную компиляцию и скорость этой самой компиляции.

                                                                                                                                                    –1
                                                                                                                                                    Не надо сравнивать. В шарпике цена абстракций перекладывается на рантайм, а в с++ — на время компиляции.
                                                                                                                                                      +2

                                                                                                                                                      А я и не сравниваю компиляцию во время выполнения со статической компиляцией. Я лишь указываю на то, что сам процесс компиляции С++ очень болезненнен и неэффективен.


                                                                                                                                                      В шарпике цена абстракций перекладывается на рантайм

                                                                                                                                                      Главное премущество C#, да и Java — мухи (язык программирования) отдельно, котлеты (VM) отдельно.


                                                                                                                                                      Было бы удобно, если бы либы распространялись не в виде хедеров/исходников, а виде предкомпилированных платформо-независимых модулей. Тот же clang сначала компилирует в LLVM, а уже потом генерит нативный код.

                                                                                                                                                        0
                                                                                                                                                        Тот же clang сначала компилирует в LLVM, а уже потом генерит нативный код.
                                                                                                                                                        Вот только AST clang'овский зависит как от версии компилятора, так и от целевой платформы. И да, сделать его переносимым не так-то просто, замедление получается весьма заметным.
                                                                                                                                                          0
                                                                                                                                                          > И да, сделать его переносимым не так-то просто

                                                                                                                                                          Не спорю. C/C++ рассматривается как язык под любую платформу и железку.
                                                                                                                                                          Но я уверен, что конкретно под массовые платформы x86/x64/ARM64 решение придумать можно.
                                                                                                                                                            –1
                                                                                                                                                            Но я уверен, что конкретно под массовые платформы x86/x64/ARM64 решение придумать можно.
                                                                                                                                                            Вы вообще сколько с компилияторами общались, извините? Откуда эта уверенность взялась? Рассмотрите простую программу:
                                                                                                                                                            struct Point {
                                                                                                                                                              int x;
                                                                                                                                                              int y;
                                                                                                                                                            };
                                                                                                                                                            extern void Do_Something(Point what, int how);
                                                                                                                                                            void Adapter(int x, int y) {
                                                                                                                                                              Do_Something({x, y}, 42);
                                                                                                                                                            }
                                                                                                                                                            
                                                                                                                                                            Так вот на x86 вам нужно будет вынуть два числа со стека, засунуть туда 42, после чего добавить туда же x и y, на ARM — нужно будет просто записать в r2 42 и сделать jmp, на x86-64 — вам нужно будет скомбинировать два аргумента в один. Да, ёлки ж палки — посмотрите сами! И? Как вы это всё в одно AST собрались засовывать?

                                                                                                                                                            Нет, это сделать можно (а в программировании вообще мало чего нельзя сделать в принципе, никогда) — но это полкомпилятора придётся переделывать!

                                                                                                                                                            Вся информация — описана в Википедии — это не какая-то супесекретная информация…

                                                                                                                                                            И это — ещё простой случай! А рассмотрите вариантик посложнее:
                                                                                                                                                            #include <cstdio>
                                                                                                                                                            template<int n> struct confusing
                                                                                                                                                            {
                                                                                                                                                                static int q;
                                                                                                                                                            };
                                                                                                                                                            template<> struct confusing<4>
                                                                                                                                                            {
                                                                                                                                                                template<int n>
                                                                                                                                                                struct q
                                                                                                                                                                {
                                                                                                                                                                    q(int x)
                                                                                                                                                                    {
                                                                                                                                                                        printf("Separated syntax and semantics.\n");
                                                                                                                                                                    }
                                                                                                                                                                    operator int () { return 0; }
                                                                                                                                                                };
                                                                                                                                                            };
                                                                                                                                                            int main()
                                                                                                                                                            {
                                                                                                                                                                int x = confusing<sizeof(x)>::q < 3 > (2);
                                                                                                                                                                return 0;
                                                                                                                                                            }
                                                                                                                                                            Ничего что у вас на x86 confusing<sizeof(x)>::q — это функция, а на x86-64 — переменная. Нормально так? Всё ещё горите желанием придумать решение «под массовые платформы x86/x64/ARM64»?

                                                                                                                                                            Нет уж, извините. Либо у вас ваши модули будут, фактически, ахивами со слегка обработанными исходниками, либо вам весь язык придётся переделывать. Снизу доверху.