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 в Нижнем Новгороде.


    * Во всех этих случаях в стандарт приняли несколько обновлённые версии.
    Яндекс 491,49
    Как мы делаем Яндекс
    Поделиться публикацией
    Комментарии 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.
        • +4
          Знаете что меня огорчает?
          Открываем любой сайт вакансий С++
          Одна из строк требования — знание языка С++ (C++98, C++03, C++11, C++14, С++-20)
          Да да 20 я уже и такое встречал
          Я понимаю это могут быть глупые хр которые возможно копипастят, но наверняка разнарядка приходить для них сверху
          И потом на собеседовании тебя начинают спрашивать, а в чем тонкость вот этой версии от той, а в какой версии появилось тото тото…
          Читаем ченж логи новых стандартов, то..., это..., итд добавили, это… депрекейдет или удалили
          Язык С++ превращается в язык версий С++
          • +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
                                                                          Где бы это все попробовать?!
                                                                          • +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++.

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

                                                                                                                Вы уж определитесь — вам шашечки или ехать.