Разработчики GCC реализовали (https://gcc.gnu.org/projects/cxx-status.html#cxx1z) в компиляторе G++ все возможности, определённые в черновике грядущего стандарта С++17 (https://ru.wikipedia.org/wiki/C%2B%2B17) (C++1z), финальный вариант которого ожидается в этом году. В libstdc++ отдельные возможности C++17 пока остаются (https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#... нереализованными. Экспериментальная поддержка всех возможностей C++17 будет предоставлена в составе GCC 7.0 и для включения  потребует указания  флага "-std=c++1z", а для включения GNU-расширений - флага "-std=gnu++1z".

В Clang работа над поддержкой C++17 также близка к завершению (http://clang.llvm.org/cxx_status.html#cxx17), не готовыми пока остаются только лямбда-выражения constexpr (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p017... выведение (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p009... (дедукция) аргументов шаблона для шаблонов класса и сопоставление (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p052... параметров шаблона с совместимыми аргументами.

URL: https://news.ycombinator.com/item?id=13387005
Новость: http://www.opennet.dev/opennews/art.shtml?num=45846

• В компиляторе G++ обеспечена поддержка C++17,Anonchip, 09:58 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 10:09 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 10:19 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Аноним, 10:36 , 13-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Аноним, 10:49 , 13-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Аноним, 11:07 , 13-Янв-17
          • В компиляторе G++ обеспечена поддержка C++17,Andrey Mitrofanov, 11:24 , 13-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,rshadow, 11:20 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,VoDA, 11:35 , 13-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Crazy Alex, 12:41 , 13-Янв-17
          • В компиляторе G++ обеспечена поддержка C++17,ram_scan, 20:16 , 14-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,scorry, 13:50 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Мяут, 14:04 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 16:27 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,all_glory_to_the_hypnotoad, 18:33 , 14-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,all_glory_to_the_hypnotoad, 18:05 , 14-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 14:47 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Andrey Mitrofanov, 15:05 , 13-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Аноним, 10:31 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 10:54 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Andrey Mitrofanov, 11:38 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Тот_Самый_Анонимус, 11:34 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 00:26 , 14-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Andrey Mitrofanov, 11:56 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,kachsheev, 11:45 , 17-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,adolfus, 15:13 , 18-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Led, 00:45 , 19-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Andrey Mitrofanov, 15:13 , 19-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 14:26 , 14-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Аноним, 10:33 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,freehck, 12:13 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:23 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 16:42 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,freehck, 17:48 , 13-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,nobody, 19:58 , 13-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Ivan, 20:01 , 13-Янв-17
          • В компиляторе G++ обеспечена поддержка C++17,freehck, 12:01 , 14-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,adolfus, 15:14 , 18-Янв-17
          • В компиляторе G++ обеспечена поддержка C++17,freehck, 02:23 , 05-Фев-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:14 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 13:31 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,dq0s4y71, 19:10 , 13-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Аноним, 10:47 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:25 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:38 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,nobody, 20:00 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,ram_scan, 20:26 , 14-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,adolfus, 15:37 , 18-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Аноним, 10:53 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 10:58 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:20 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Аноним, 14:18 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Аноним, 00:29 , 14-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Аноним, 09:30 , 16-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,WoT, 10:55 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,A.Stahl, 11:00 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Мяут, 11:24 , 13-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,лютый жабист__, 11:39 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,A.Stahl, 11:47 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:12 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:40 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 17:36 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,nobody, 20:04 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Аноним, 04:40 , 14-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:03 , 14-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:13 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Crazy Alex, 12:53 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 20:09 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Аноним, 01:51 , 15-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:29 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Crazy Alex, 12:51 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Антонимус, 15:55 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,dq0s4y71, 19:20 , 13-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:11 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,nobody, 20:09 , 13-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:15 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:28 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,гость, 12:46 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:32 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 14:10 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Антонимус, 16:02 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Аноним, 22:56 , 13-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Аноним, 02:51 , 14-Янв-17
          • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:12 , 14-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Аноним, 02:51 , 14-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,freehck, 12:09 , 14-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Аноним, 14:32 , 14-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,iZEN, 20:19 , 20-Апр-17
  • В компиляторе G++ обеспечена поддержка C++17,Антонимус, 16:00 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,dq0s4y71, 19:22 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,freehck, 12:10 , 14-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Аноним, 14:41 , 14-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,dq0s4y71, 16:53 , 17-Янв-17
          • В компиляторе G++ обеспечена поддержка C++17,freehck, 01:36 , 25-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,nobody, 20:11 , 13-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:24 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:28 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:42 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Шоколадный заяц, 13:11 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Аноним, 13:52 , 13-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Аноним, 14:05 , 13-Янв-17
          • В компиляторе G++ обеспечена поддержка C++17,_, 18:04 , 13-Янв-17
            • В компиляторе G++ обеспечена поддержка C++17,Аноним, 22:59 , 13-Янв-17
              • В компиляторе G++ обеспечена поддержка C++17,Аноним, 05:46 , 14-Янв-17
                • В компиляторе G++ обеспечена поддержка C++17,Аноним, 09:39 , 16-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 17:19 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,_, 18:05 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 17:33 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,_, 18:08 , 13-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Аноним, 23:03 , 13-Янв-17
          • В компиляторе G++ обеспечена поддержка C++17,Аноним, 17:14 , 14-Янв-17
            • В компиляторе G++ обеспечена поддержка C++17,Аноним, 22:31 , 14-Янв-17
          • В компиляторе G++ обеспечена поддержка C++17,Вареник, 19:24 , 14-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,nobody, 20:14 , 13-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Аноним, 23:09 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 14:12 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Andrey Mitrofanov, 14:53 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Аноним, 15:57 , 13-Янв-17
        • В компиляторе G++ обеспечена поддержка C++17,Andrey Mitrofanov, 17:45 , 13-Янв-17
          • В компиляторе G++ обеспечена поддержка C++17,_, 18:09 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 16:10 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Аноним, 17:35 , 13-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:27 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 12:29 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,_, 18:11 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,nobody, 20:18 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Вареник, 19:26 , 14-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Аноним, 13:43 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 13:53 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,dq0s4y71, 19:32 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним, 14:16 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Антонимус, 16:06 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,_, 18:14 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 18:53 , 14-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Аноним, 14:44 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Аноним84701, 15:09 , 13-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Аноним, 17:57 , 13-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,nobody, 20:23 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Andrey Mitrofanov, 15:14 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Антонимус, 16:07 , 13-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Анестезиолог, 11:52 , 14-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Ilya Indigo, 11:11 , 14-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,nobody, 14:14 , 14-Янв-17
    • В компиляторе G++ обеспечена поддержка C++17,Ilya Indigo, 01:28 , 15-Янв-17
      • В компиляторе G++ обеспечена поддержка C++17,Аноним, 14:45 , 16-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Анестезиолог, 11:58 , 14-Янв-17
  • В компиляторе G++ обеспечена поддержка C++17,Вареник, 19:30 , 14-Янв-17
• В компиляторе G++ обеспечена поддержка C++17,Аноним, 21:58 , 15-Янв-17

GCC лучший!

Только сам язык C++ уже не лучший из-за неоправданной переусложнённости последними стандартами.

Не используй возможности последних стандартов. С++ - платишь только за то, что используешь.

все равно их надо изучить:
1) чтобы понять, что они тебе не нужны
2) чтобы не выпадать из тематических дискуссий (никто не тыкал в тебя, что ты давно устарел и не угнался за прогрессивными фичами)

Без этого можно обойтись. Я знаю людей, которые обходятся. У меня на работе это все, кроме меня...

Да, учиться вообще вредно.

> Да, учиться вообще вредно.

В смысле, "дурака учить - только портить"?  Согласен!  Мудрость народа, да.  Возразить %) нечего.

Это вам надо на скриптовые языки перебираться с таким подходом. Либо в работе что-то менять. Забивать гвозди микроскопом всегда было очень сложно.

> Не используй возможности последних стандартов. С++ - платишь только за то, что
> используешь.

Даже в малом проекте (человек на 5-10 разработчиков) за 5 лет будут использованы ВСЕ возможности языка и все паттерны и анти-паттерны. Потому придется изучать все. Либо собирать грабли и опять изучать.

Ну если у вас ни стайл-гайда, ни ревью нет... А так - вон, у гугла с мозиллой получается даже без довольно фундаментальных вещей (искючений тех же) обходиться. Отнюдь не на проектах  в 10 человек.

А если есть стайл гад и прочие плюшки но на куда эти мегафичи уперлись вообще если коран как правило их юзать не велит ?

На асм ещё пожалуйся.

C++: Что если мы добавили в язык все что могли?
C++11: Что если мы не можем остановить процесс добавления возможностей?

(c) http://argumate.tumblr.com/post/118013166244/python-what-if-...

> Только сам язык C++ уже не лучший из-за неоправданной переусложнённости последними стандартами.

Выскажу неожиданную для вас мысль: Последние стандарты "не только лишь" усложняют язык, но и упрощают его!

Например, теперь можно писать:

    auto

вместо

    std::vector<SomeClass::SomeCrazyType>::const_iterator

----

    class A
    {
    private:
        int i = 5;
    };

вместо

    class A
    {
    public:
        A();
    private:
        int i;
    };

    A::A()
        : i(5)
    {
    }

----

    [int a](int b) -> bool { return a == b; }

вместо

    class SameAs
    {
    public:
        SameAs(int a);
        bool operator==(int b);
    private:
        int aa;
    };

    SameAs::SameAs(int a)
        : aa(a)
    {
    }

    bool SameAs::operator==(int b)
    {
        return a == b;
    }

----

    std::vector<int> GenerateData();

вместо

    void GenerateData(std::vector<int>& result);

благодаря move-семантике.

----

Да долго всякие упрощения перечислять можно.

>[оверквотинг удален]
>         int aa;
>     };
>     SameAs::SameAs(int a)
>         : aa(a)
>     {
>     }
>     bool SameAs::operator==(int b)
>     {
>         return a == b;
>     }

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

template<typename Type> class SameAs {
   SameAs(Type val): Val(val) { }

   bool operator==(const Type &val) const { reutrn val == val; }
private:
   Type Val;
};

>     std::vector<int> GenerateData();
> вместо
>     void GenerateData(std::vector<int>& result);
> благодаря move-семантике.

RVO/NRVO существуют уже достаточно давно и move семантика тут абсолютно ни при чем. А если хватит ума вхерачить явный move в реализации GenerateData(), то поломаешь NVRO и наплодишь ненужный move.

> Да долго всякие упрощения перечислять можно.

Все твои "урощения" не в тему, кроме мудотни с итераторами. Хотя с упрощениями даже этого делать не обязательно, в большинстве случаев хватает range-based for loop.

За последние лет 10-15 как раз таки стал лучшим. В любом случае альтернатив ему всё ещё нет, может быть только rust отрежет некоторые ниши.

лучший у помойки?

> лучший у помойки?

Не беспокойтесь. Ваши регалии вне опасности.

Плюсы только расцветают с последними обновлениями!

Они перестали тянуть за уши максимальную совместимость с Си-ассемблером? Язык явно становится стройнее и чище.
Ща, еще только сборщик добавят в стандарт (опциональный). И, можно сказать, мы увидим его таким, каким его задумывал Страуструп.

Страуструп его как раз задумал сделать без сборщика. Но против ничего не имеет, если его можно будет подключать как расширение.

> Страуструп его как раз задумал сделать без сборщика. Но против ничего не
> имеет, если его можно будет подключать как расширение.

На Си но проще... наверное... https://packages.debian.org/src%3Alibgc

user:~$ apt-cache rdepends libgc1c2 |grep '^  '|sort -u
  asymptote
  chase
  debfoster
  ecl
  fauhdlc
  goo
  guile-2.0-libs
  inkscape
  kaya
  libapache2-mod-parser3
  libgc-dev
  libmailutils4
  libneko0
  libsynopsis0.12
  mailutils
  parser3-cgi
  w3m
user:~$ _

Труп страуса ещё выступал за максимальную совместимость с Си. Может вы наоборот являетесь его противником?

Это не так. Не за максимальную, а за максимально возможную. C++ уже в конце 80-х не был совместим с C.

> Плюсы только расцветают с последними обновлениями!
> Они перестали тянуть за уши максимальную совместимость с Си-ассемблером? Язык явно становится
> стройнее и чище.

Кто-то ж из Анонимов говорил, что то ли Си14 будет ообязятелен в Си++19, то ли кактие-то другие числа, но врожде ж обязателен... Вроде, на днях же ж -- но найти ссылку на авторитетного Анонима сейчас не могу.  //Ау! Где, ты, о Всеведущий??

> Ща, еще только сборщик добавят в стандарт (опциональный). И, можно сказать, мы
> увидим его таким, каким его задумывал Страуструп.

> Кто-то ж из Анонимов говорил, что то ли Си14 будет ообязятелен в Си++19

Точно известно, что в C++17 обязателен C11. К тому же, разве C14 существует?

Существует только С++11. Все остальное есть фейк и кал, пока не выйдет из комитета в виде печатного релиза.

> Существует только С++11. Все остальное есть фейк и кал

А ты - первое или второе? или сочетаешь?

>> Кто-то ж из Анонимов говорил, что то ли Си14 будет ообязятелен в Си++19

", то ли кактие-то другие числа".

> Точно известно, что в C++17 обязателен C11. К тому же, разве C14
> существует?

Я позволил себе [от/про]пустить отсвоение сортов чисел. На уровне после прочтения K&R примерно. И фигурно вырезанной выше конструкцией "то ли X, то ли Y" и прикреплёнными к ней вопросами к Сверхразуму, я, как мне казалось, ясно обозначил не особую свою уверенность в тех числах.  Надеюсь, я помог Вам В Вашем затруднении?  Если ещё что-то не понятно, обращайтесь.  Спасибо.

Ну совместимость с Си-ассемблером у него всегда была плохая вследствие несоместимости ABI. И уж точно Страуструп не задумывал туда пихать функциональщину.

PS Ну право же, для любитей ФП и ООП одновременно есть OCaml, который тоже может в машкоды компилировать.

модули добавили?

А пространства имён - чем не модули для плюсов?

Кому и кобыла невеста.

> А пространства имён - чем не модули для плюсов?

Модули - это несколько другое. А именно, возможность не вести "двойную бухгалтерию", т.е. не дублировать заголовки функций в .h и .cpp файлах. Почитайте здесь:

https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules.../

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

>> А пространства имён - чем не модули для плюсов?
> Модули - это несколько другое. А именно, возможность не вести "двойную бухгалтерию",
> т.е. не дублировать заголовки функций в .h и .cpp файлах.

Хм. Я понял, смысл в том, что хочется уйти от необходимости отдельно писать код в .cpp/.cxx, и отдельно описывать интерфейсы в .h, передавая эту работу компилятору, когда это возможно.

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

Это смотря как реализовать. Если это будет штучка для "автоматической генерации интерфейсов", тогда скорее всего да, забьют на него.

А вот если смогут реализовать наследование, расширение модулей и генерацию на лету (functors) на основе других модулей, то это будет мега-фича. Впрочем, с фанкторами, скорее всего не получится. Они будут, пожалуй, сродни модулям первого порядка, а в c++ реализовать подобное будет сложновато.

В любом случае, спасибо за ссылку, было интересно.

> Хм. Я понял, смысл в том, что хочется уйти от необходимости отдельно писать код в .cpp/.cxx

Неправильно понял. Шаблоны в .cpp не поместишь, они до сих пор живут в хэдерах. 90% того же Boost - в хэдерах. И практически всё это компилятору нужно переразбирать при компиляции чуть ли не КАЖДОГО .cpp из проекта

> Хм. Я понял, смысл в том, что хочется уйти от необходимости отдельно писать код в
> .cpp/.cxx, и отдельно описывать интерфейсы в .h, передавая эту работу компилятору,
> когда это возможно.

Я бы сказал, что это не главная фича. Основная мотивация это позволить компилятору закешировать результат парсинга/синтаксического анализа хедеров и переиспользовать его в каждой единице трансляции. Сейчас компилятору приходится парсить/анализировать хедер столько раз, сколько он инклудится в разные единицы трансляции.

Это больше напоминает precompiled хедера, только более fine-grained и встроенные в язык.

Ещё один минорным side-effect'ом является то, что это получить ODR-нарушение станет гораздо сложнее. Большинство пользователей этого не заметят, просто их программы будут работать как они ожидают.

> Я бы сказал, что это не главная фича. Основная мотивация это позволить
> компилятору закешировать результат парсинга/синтаксического анализа хедеров и переиспользовать
> его в каждой единице трансляции. Сейчас компилятору приходится парсить/анализировать
> хедер столько раз, сколько он инклудится в разные единицы трансляции.

Это-то понятно. Когда интерфейсы компилируются отдельно - это станартная практика. Хорошо бы ещё позволить интерфейсы модуля прописывать отдельно, в целях инкапсуляции вспомогательных функций. Думаю, в сях многие этого хотели бы.

> А вот если смогут реализовать наследование, расширение модулей и генерацию на лету
> (functors) на основе других модулей, то это будет мега-фича. Впрочем, с
> фанкторами, скорее всего не получится. Они будут, пожалуй, сродни модулям первого
> порядка, а в c++ реализовать подобное будет сложновато.

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

> На лету и остальная динамика хороши с точки зрения академического интереса.

Этот самый академический интерес работает не сильно медленнее обычного Си. Раза эдак в четыре всего.

> Для продакшена хотелось бы возможности явного отключения тяжелых конструкций, например, все динамическое, проверки границ и прочее. Чтобы было что-то типа прагмы.

Посмотрите на Ocaml. Там именно так и сделано.

> Не мешало бы поиметь несколько точек входа в процедуру

А может тогда лучше пусть это будут несколько разных процедур?

> и арифметическое ветвление

Ой, ну это же синтаксический сахар. Его не так уж сложно добавить.

> прямой выход из вложенных вызовов с очисткой стека,

exceptions

используй инклюды препроцессора. модули еще он хочет.

Нет.

https://en.wikipedia.org/wiki/C%2B%2B17

Ещё в 1983-м.

Толку то, C++17 не добавляет ничего интересного. У языка море проблем, проходят года, а они только мелочевку фиксят. Комитет сплошняком из тунеядцев. Не мудрено что появился целый зоопарк новых языков, всем просто надоело ждать. Тем более работы чтобы привести язык к приемлемому состоянию там максимум на год, а они кроме постоянного обсуждения ничего не делают.

Груз обратной совместимости

Маловато будет для оправдания. Решение или есть, или его нет. Еслиб я столько времени тратил на раздумья, ужеб сменил с десяток работ.

Давай-давай, немедленно расскажи нам всем, а ещё лучше покажи, как надо

> Толку то, C++17 не добавляет ничего интересного. У языка море проблем, проходят
> года, а они только мелочевку фиксят. Комитет сплошняком из тунеядцев.

Си и все что из него выросло как понятная и логичная вещь умер вместе с архитектурой PDP для которой он и был написан. Когда можно было глядеть в исходник и легко в уме прикидывать в какой бинарник чуть ли не с точностью до инструкции это все компилятор соберет.

А дальше пошло запиливание мегакостылей вокруг атавизмов 40-летней давности заради "обратной совместимости" которой по состоянию на сегодня нет чуть более чем полностью.

Все-таки дедушка Вирт прав был.

> Си и все что из него выросло как понятная и логичная вещь
> умер вместе с архитектурой PDP для которой он и был написан.

Архитектура у PDP куда лучше, чем у штеуда. Уж то под штеуд хрен какой язык напишешь, настолько все там угробищно.

Между 14 и 17 прошло целых 3 года. За это время вот что согласовали: https://ru.wikipedia.org/wiki/C%2B%2B17
Полнейший абсурд...

«Ожидаемые» не значит все. Даже в английской версии статьи больше ожидаемых возможностей.

За 3 года ничего не сделали, и Вы считаете за оставшиеся месяцы ситуация кардинально изменится?

Судя по минусам есть такие люди

А в чем проблема за пару месяцев дописать статью в википедии?

В википедию как раз не проблема, проблем в стандарт, с такими темпами то

На странице
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#...
есть такие параметры
-std=c++11 , -std=c++14  и  -std=c++1z

Стало интересно, а почему "C++ 201z" ?
На Википедии "C++17 (also called C++1z)"

У черновых вариантов всегда странные названия. Релизное же название подгоняется к виду "c++14" и т.п.

Ну потому что надежды, что стандарт выпустят в течение 2й декады 21века, но непонятно в какой год, потому последнюю цифру меняют на условный "x". Так было с C++11, который сначала назывался c++0x, и с C++14 -- с++1y

В "могучем" си по прежнему нельзя сделать switch по Стрингу? :)

Ты либо стринги надень либо switch сними.

свитчи уродливая нечитабельная конструкция, else if, else if к твоим услугам

Поскольку тип данных один - switch оптимизируется до бинарного поиска или хэш-таблицы.

else if по-вашему лучше? case можно выравнять и будет всё четко видно, гораздо лучше else if

Это лестница if-else-if - уродливая, нечитаемая и плохо оптимизируемая конструкция. А выбор одного из набора вариантов - фундаментальная конструкция высокоуровневых языков программирования.

Какая лестница? Все по строкам? И как она оптимизируется? Забудь break поставить и у тебя все полотно текста выполнится, так как нутри там тот же if else. Ох уж эти новички с самомнением

Оптимизируется до логарифмического поиска или поиска по хэш таблице. Значения сортируются или строится их хэш таблицы на стадии компиляции. else if - только последовательный перебор.

switch это всего лишь синтаксический сахар.

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

switch - это goto.

switch (как и 'if else', 'for', 'while') это jmp.

Можно! Берёшь лексер по вкусу и будет тебе.

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

Собственно можно, и не только свитч, и не только по стрингу.

М-да... Это как предъявлять претензии к Джаве, что в ней до сих пор нельзя сделать ассемблерную вставку.

Читаю изменения стандарта, даже не знал что в си были триграфы )

Вот и замечательно, что эту хрень вычистили из стандарта. Даже если ты про них не знаешь, они портят твой код, в частности строки: "??(...)" превращаются в "[...)" при компиляции...

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

Для чего?

Rust — многопользовательская компьютерная игра нового поколения в жанре симулятора выживания :-) Хе-хе :D

для начала выпилите из Rust убогие unwrap'ы и вырвиглазный синтаксис, потом посмотрим.
а покачто c++ намного круче выходит.

Rust уже значительно обошел с++ по потенциалу оптимизации и безопасности кода, но по прежнему далеко отстает по библиотечной базе. Попытался тут перевести один свой C++ Qt проектик на Rust, понял сколько нужно с нуля реализовывать и забил.

>> Rust уже значительно обошел с++ по потенциалу оптимизации и безопасности кода

Давайте уже поймем, что ЛИБО оптимизация, ЛИБО безопасность.
>> Попытался тут перевести один свой C++ Qt проектик на Rust

Qt/C++ и C++ - весьма разные, вплоть до полной непохожести вещи.
>> понял сколько нужно с нуля реализовывать и забил

В смысле, с нуля Qt реализовывать?)

Статический анализ, который обеспечивается в Rust'е, позволяет проверять код на безопасность, и одновременно, удивительным образом, производить оптимизации, которые в том же c++ произвести не возможно.  
Вот пример:
> void squareArrayWith100500Items (int* const dest, const int* const source)
> {
>   for (int i=0; i < 100500; ++i) {
>        dest[i] = source[i]*source[i];
>      }
>  }

C++\C, в отличии от нормальных языков, для данной функции не может провести часть оптимизаций и предрасчётов во время компиляции, не может векторизовать этот цикл, не может распараллелить его.
А всё почему?
А потому что не уверен перекрываются ли указатели dest и source. В C99 для этого ввели костыль в виде ключевого слова restrict. В языке просто нет понятия динамического массива, который бы более или менее гарантировал отсутствия перекрытий. Они эмулируются через указатели, которые не может нормально оптимизировать компилятор. И весь stl построен на указателях, оптимизация тоже не возможна.

Для С++ существуют статические анализаторы, например http://clang-analyzer.llvm.org .

g++ векторизирует эту функцию, вот код сгенерированный для тела цикла:

// void square(int* const dest, const int* const source, size_t lenght)
//{
//  for (size_t i = 0; i < lenght; ++i)
//    dest[i] = source[i] * source[i];
//}

<square(int*, int const*, unsigned long)>:
               ...
start:
    movdqu (%rsi,%rax,1),%xmm1
    add    $0x1,%rcx
    movdqa %xmm1,%xmm2
    pmuludq %xmm1,%xmm2
    psrlq  $0x20,%xmm1
    pshufd $0x8,%xmm2,%xmm0
    pmuludq %xmm1,%xmm1
    pshufd $0x8,%xmm1,%xmm1
    punpckldq %xmm1,%xmm0
    movdqu %xmm0,(%rdi,%rax,1)
    add    $0x10,%rax
    cmp    %rcx,%r9
    ja     start
    ...

И распараллелить автоматически тоже может, см. OpenMP.

>> И весь stl построен на указателях, оптимизация тоже не возможна.

Ты или неуч или провокатор.

OpenMP - не автоматические распараллеливание. Это костыль, созданный чтобы как-то поддержать с++ на плаву в многопоточивающемся мире. Он даже не входит в стандарт с++. Это отдельный стандарт для компиляторов.
> Ты или неуч или провокатор.

Без проверки перекрытия распараллелить не получится, т.к. указатели могут указывать на один и тот же участок памяти. Необходима проверка перекрытия, и в с++ она возможна только в рантайме. При этом, на стадии компиляции в RUST выясняется не только перекрываются ли они, но и на сколько перекрываются.

Для С++ существуют статические анализаторы, например http://clang-analyzer.llvm.org .

g++ векторизирует эту функцию, вот код сгенерированный для тела цикла:

// void square(int* const dest, const int* const source, size_t lenght)
//{
//  for (size_t i = 0; i < lenght; ++i)
//    dest[i] = source[i] * source[i];
//}

<square(int*, int const*, unsigned long)>:
               ...
start:
    movdqu (%rsi,%rax,1),%xmm1
    add    $0x1,%rcx
    movdqa %xmm1,%xmm2
    pmuludq %xmm1,%xmm2
    psrlq  $0x20,%xmm1
    pshufd $0x8,%xmm2,%xmm0
    pmuludq %xmm1,%xmm1
    pshufd $0x8,%xmm1,%xmm1
    punpckldq %xmm1,%xmm0
    movdqu %xmm0,(%rdi,%rax,1)
    add    $0x10,%rax
    cmp    %rcx,%r9
    ja     start
    ...

И распараллелить автоматически тоже может, см. OpenMP.

>> И весь stl построен на указателях, оптимизация тоже не возможна.

Ты или неуч или провокатор.

> Давайте уже поймем, что ЛИБО оптимизация, ЛИБО безопасность.

Ну почему же. Бывает и так, что обе сразу, зависит лишь от того, с какой стороны глядишь. Вот, например, смотрит Racket-программист на OCaml, и понимает, что это +оптимизация, +безопасность.

То-то у меня периодически sks в режиме recon выпадает в сегфолт на ровном месте. Звизди больше.

> Попытался тут перевести один свой C++ Qt проектик на Rust, понял сколько нужно с нуля реализовывать и забил.

Время компиляции и сборки Rust 1.16 сопоставимо с временем компиляции и сборки LLVM 3.9.
Qt - самый жирный фреймворк/набор C++ классов. Так, чтобы собрать какую-нибудь малюсенькую программку на Qt, нужно каждый раз разворачивать архив qt-everywhere-opensource-src-4.8.7.tar.gz размером 241 МБ, чего-то с ним делать и потом удалять ненужное, получая нужное (честное слово - как статую из скалы высекаешь). Вы же выбираете самое тормозное и жручее в квадратичной степени. Зачем так делать, не понимаю. Qt непопулярный фреймворк. Оконные приложения в основном пишутся/писались на Gtk2. Лично я настороженно отношусь к приложениям с Qt.

>>для начала выпилите из него классы и шаблоны

т.е. оставить таки Pure C?
>>а покачто Rust намного круче выходит.

Откуда, простите, выходит?

> т.е. оставить таки Pure C?

Таки да!

>>>для начала выпилите из него классы и шаблоны
> т.е. оставить таки Pure C?

Pure C + полимирфизм. Видимо, полиморфизм тому анониму по душе. А может он просто не знает про него...

Чё, полиморфизм на чистом C, это, простите, как?

http://www.state-machine.com/doc/AN_OOP_in_C.pdf

> http://www.state-machine.com/doc/AN_OOP_in_C.pdf

Жуть. Меня поражает объём работы. Не лень же кому-то было написать столько очевидных вещей.
10 страниц очевидных вещей. И картинки нарисовать... Блин. Жуть.

Так надо ещё циклы и переменные выпилить для верности, чё уж там.

Фундаментальные проблемы языка всё равно не исправят. Им остается только сахарком посыпать, пока язык не умрет под натиском Rast'а и ему подобных.

> Фундаментальные проблемы языка всё равно не исправят. Им остается только сахарком посыпать,
> пока язык не умрет под натиском Rast'а и ему подобных.

расты и ему подобные приходят и уходят, а си++ остается

т.е. к лучшему ничего не изменится?

Ну откройте вакансии и посмотрите реальную картину. Остальное - соплежуйство для школьников и студентов.

Для Rast'а нет.

Rust еще меняется и дорабатывается. С++ уже нет.

Поэтому на расте _обещают_ сделать новфй PostgreSQL, NNTPSec, browser engine Servo и миллион других крутых вещей ...
А на с\с++ - тупо - делают.

Выбирай :)

> А на с\с++ - тупо - делают.

Сколько лет С++ и сколько Rust? На сколько стабилен Rust и на сколько стабилен c++? Понятно, почему Ваш аргумент - глупости?

Поэтому на расте _обещают_ сделать новфй PostgreSQL, NNTPSec, browser engine Servo и миллион других крутых вещей ...
А на go - тупо - делают.

// fixed

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

Си(С++): https://ru.wikipedia.org/wiki/Си_(язык_программирования) 1972 год (45 лет).
Rust: https://ru.wikipedia.org/wiki/Rust_(язык_программирования) 2010 год (7 лет).
Вы прошиблись аж на 38 лет! За эти 45 лет на Си(С++) понаписано множество библиотек, операционок, драйверов и приложений.

Расты и ему подобные приходят навестить могилку си++ и уходят, а си++ остается лежать на кладбище.

Сколько говоришь у вас в штате раст-программеров ...
Дитё. ТЧК.

Пример приведите пожалуйста. Подобных Rust'у еще не было.

Ка-а-ане-е-ечна-а-а :)
Навскидку - D. Позиционировался точно так же как рас. Проще\красивее\безопаснее\быстрее\и борщ варит сам...
И чо? "Все пробуют, а замуж не берут" (С)

За D, по сути, никто не стоял. За Rust стоит Mozilla Corporation.

Это у которой браузер пользователей теряет стремительным домкратом ?

Угадал, та самая, которая с 2002 работает и занимает существенную долю интернет аудитории., которая так же запилила свой весьма популярный почтовый клиент, и та, которая успела запилить свою ОС и успешно поставить ее на десятки тысяч теликов. И, как не крути, а умирать Mozilla Corporation не собирается.

> За D, по сути, никто не стоял. За Rust стоит Mozilla Corporation.

- Это где каждый релиз хуже предыдущего, а бабло от продажи данных пользователей?

Objective C, Java, C#, D (несколько языков с таким названием), Go, Swift, Nim... Это из последних. Кого ещё из "убийц"/"исправлений" C/C++ забыл?

Objective C для Apple. С какого потолка Вы взяли, что он разрабатывался в качестве убийцы с++? А Java? Тоже убийца c++, Вы серьезно? Go разработан на замена питону, а не c++. Swift то же, что и Objective C. Nim это Lisp + Python...

Можете минусовать сколько угодно, ситуацию это никак не поправит.

> Можете минусовать сколько угодно, ситуацию это никак не поправит.

Ну, вот тебе минус за разговор с минусами.

Я вообще-то про комментарий выше

> Я вообще-то про комментарий выше

Заплачь ещё.

Остановись Андрейка. А то оно в петлю полезет :-\

Ты тоже можешь кукарекать на опеннете сколько угодно, ситуацию это никак не поправит.

И тебе тоже в унисон подкукарекивать разрешается

Новость ни о чем. Черновик заполняется постепенно, и наверняка g++ нагонял его ни один раз.

Сейчас комитет добавит микрофикс в черновик, и g++ опять перестанет поддерживать C++17 в полном объеме. Быстро поправят и можно новую новость публиковать: "В компиляторе G++ снова обеспечена поддержка чернового C++17"

Комитет работает, продолжайте башлять ...
Что тут либерасты про попилы в "этой стране" пели ? :-)  

GCC обогнал Clang по реализации новых фич. Это уже значимая новость. Многие тут его хоронить собирались в появлением последнего

> GCC обогнал Clang по реализации новых фич. Это уже значимая новость. Многие
> тут его хоронить собирались в появлением последнего

- Конкуренция это хорошо.

С++ переусложнён.
Лучшее для нового стандарта С++ - повторить 6-ой подвиг Геракла.

> С++ переусложнён.

Используй BASIC.

Боже упаси! Особенно какой-нибудь VB.NET...

Я вот никак тоже не пойму, обратную совместимость они уже ломали, тем же auto_ptr. Почему нельзя взять, и переделать всё нормально?!... Они там по-моему вообще не работают.

>> С++ переусложнён.

Определитесь уже, "переусложнен", или "не хватает модулей, автовывода, пропертей etc."
>> Лучшее для нового стандарта С++ - повторить 6-ой подвиг Геракла.

Собственно, как ни странно, склонен местами согласиться. Какбэ новый язык нужен по формуле НовыйЯзык = C++ - совместимость с С - обратная совместимость. И все будет в шоколаде.

а чо остановился то? Продолжай! К примеру:

- совместимость со всем что уже есть.

И кому нужно будет это чудо?  Нет робяты, только плавненько! Или в Ж.

>> Определитесь уже, "переусложнен", или "не хватает модулей, автовывода, пропертей etc."

Ты не поверишь! Они умудрились достигнуть этих целей одновременно!

Единственное наиогромнейшее и почти непреодолимое его преимущество перед кучей других языков - гигатонны написанных за многие годы исходников/библиотек/программ (миллионы человеколет), которые всем очень нужны.

> для включения GNU-расширений - флага "-std=gnu++1z".

как обычно - без vendor lock обошлись не могли. GNU оно такое ГНУ, всех ругает а сами потихоньку..

>> для включения GNU-расширений - флага "-std=gnu++1z".
> как обычно - без vendor lock обошлись не могли. GNU оно такое
> ГНУ, всех ругает а сами потихоньку..

Ага. То ли дело компания бобра, которая  собственные расширения *_s даже в стандарт c11 пропихнула, при этом умудряясь в своих компиляторах все еще забивать на поддержку с99 и вообще, не планировать лишних телодвижений в эту сторону:
https://visualstudio.uservoice.com/forums/121579-visual-stud...
>   Visual Studio Team ADMIN
> Visual Studio Team (Product Team, Microsoft Visual Studio) responded  ·  May 08, 2012
> Our primary goal is to support "most of C99/C11 that is a subset of ISO C++98/C++11.
> We do not plan to support ISO C features that are not part of either C90 or ISO C++.

Устарело: https://msdn.microsoft.com/en-us/library/hh567368.aspx
Тут еще автор выше не слышал про -std=gnu99, который включает 95% плюшек, без которых невыносимо жить :)

Ну-ка, ну-ка. Без каких это гнутых плюшек Вам не живётся? 15 лет обхожусь без них

>> для включения GNU-расширений - флага "-std=gnu++1z".
> как обычно - без vendor lock обошлись не могли. GNU оно такое
> ГНУ, всех ругает а сами потихоньку..

В чём локин-то, если двумя словами раньше написано про "" указания  флага "-std=c++1z" ""?

Вы можете не использовать. Если спросят -- я разрешил.

Хм... А вас прямо заставляют их включать? Не нужны - не включай. Если код их не юзает, норм. скомпилируется.

Ты понимаешь, что ты поехавший уже, всё?

>Экспериментальная поддержка всех возможностей C++17 будет предоставлена в составе GCC 7.0 и для включения потребует указания флага...

Они же грозились её по умолчанию запилить, для 7-ки, а теперь через флаг, да ещё и экспериментальную?

> грозились её по умолчанию запилить

Когда и кому грозились? Линк давай

>> грозились её по умолчанию запилить
> Когда и кому грозились? Линк давай

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

Грозились включить C++14 по умолчанию. И действительно включили - в 6.0.

Вывод типов в новых плюсах - это ад. Оно с самого начала было адово, потом добавился вывод типов для шаблонов, потом добавили auto, лямбды, rvalue-ссылки и move-семантику... Система типов уже напоминает романы Кафки, блджад. А они смеются и херачат ещё.

> Вывод типов в новых плюсах - это ад. Оно с самого начала
> было адово, потом добавился вывод типов для шаблонов, потом добавили auto,
> лямбды, rvalue-ссылки и move-семантику... Система типов уже напоминает романы Кафки, блджад.
> А они смеются и херачат ещё.

Больше непоняток - больше работы. Больше работы - больше рабочих мест в IT. Всем хорошо, кроме жалоб школоты, что после бейсика сложно, а на вырвиглазный хруст проектов нет.

Когда пакет менеджер будет для C++? Задрала все продукты таскать с собой )))