C++17, который мы потеряли

  • Tutorial

5-го марта 2016-го года в городе Джэксонвилл закончился очередной съезд комитета ISO C++. Люди собирались предварительно-окончательно решать, что же войдёт, а что не войдёт в стандарт С++17. Конечно, ещё не 2017-ый год и кое-что ещё, возможно, переиграется. Тем не менее, есть мнение, что именно данное мероприятие очертило С++17 в его будущем виде.

Я не буду тут тянуть кота за хвост и искать толерантные выражения: нас ждёт катастрофа. Стандарты С++11/14 были очень значительным скачком вперёд, но на этом всё закончилось. С++17, обещанный когда-то «мажорным» релизом, по факту не несёт в себе ничего существенного. Немного синтаксического сахара, пару мелочей в стандартную библиотеку — и на этом всё. Отголоски данной трагедии уже звучали некоторым эхо на Хабре, но я всё-таки решил обобщить информацию и понять, куда мы катимся.


Начнём с хорошего.

Что войдёт в С++17



Файловая система
Отличная штука! Была бы, если бы вошла в стандарт лет 15 назад. В самом деле, даже в богомерзком .NET классы для работы с файловой системой — с версии 1.1 (а это 2003 год). А тут вот руки дошли позаимствовать boost::filesystem в 2016-ом году. Ну и на том спасибо.

any, optional, string_view
Первые две штуки и так были доступны в разных библиотеках, string_view же выглядит как затычка, для тех, кто не освоил константные ссылки и shared_ptr. Третий способ сказать «вот тебе строка, которой ты не владеешь, можешь её только почитать». Ну ок, будет хорошо смотреться в интерфейсах, какого-то принципиального быстродействия по сравнению с двумя предыдущими способами не даст.

Лямбды в constexpr-функциях
constexpr int AddEleven(int n) {
return[n]{return n+11;}();
}
static_assert(AddEleven(5)==16,"");


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

Параллельные алгоритмы
Да, это хорошо, что теперь какую-нибудь сортировку можно распараллелить «из коробки». Но с этой проблемой уже полтора десятка лет боролись все производители компиляторов, процессоров, основных фреймворков, и в общем-то на данный момент куда ни плюнь — так попадёшь или в Threading Building Blocks, или в один из десятка «Parallel STL», или в расширения языка вроде Intel Cilk Plus или ещё во что-то подобное. Кому был нужен параллелизм — у того был параллелизм. Более того, все библиотеки и фреймворки с выходом стандарта никуда не денутся, поскольку у каждого решения есть свои плюсы и они в них будут превосходить стандарт. Классическая ситуация «к 14-ти стандартам прибавился 15-ый»

Специальные математические функции
Что-что вы решили добавить в язык?! Сферические гармоники и гипергеометрические функции? Это вот прямо то, без чего каждый программист на С++ жить не может, по вашему? Ну боже мой, почему этому всему не нашлось места в какой-нибудь лежащей далеко в углу математической библиотеке, в бусте каком-то, в маткаде, в интеловских сдк, да где-угодно, кроме стандарта языка С++17?

С помощью ranged-for теперь можно бегать по диапазонам, в которых начало и конец имеют разные типы
Сейчас начало и конец диапазона должны быть одного типа (итерируемого). Для начала это и правда имеет смысл — мы ведь от него будем идти вперёд, это должен быть итератор. В то же время конец — штука неизменная, быть ему итератором совершенно не обязательно. Более того, иногда даже лучше иметь начало и конец двух принципиально разных типов, чтобы в виду отсутствия концептов можно было как-нибудь себя обезопасить от случаев «ой, я случайно скопипастил begin() дважды для указания диапазона».

Захват копии *this по значению в лямбдах
Ожидаемая фича. Передавать указатель на this можно было и раньше, но это не всегда было то, чего хотелось. Теперь можно и так, и так.

[[fallthrough]], [[nodiscard]], [[maybe_unused]]
Просто средства избежать ворнингов при компиляции. Код и раньше можно было организовать так, чтобы их не было. Причём я бы сказал, что и читабельность при этом удавалось сделать повыше, чем она будет теперь со всеми этими атрибутами.

Перейдём к плохому.

Что не войдёт в С++17



Концепты
Комитет сказал «не готово». Комитет сказал «давайте подождём ещё год или два». Я бы на их месте был более честен с людьми и сказал как есть: «а мы и не понимаем, как оно должно быть». Я не знаю как всё там в комитете варится внутри, но снаружи возня с концептами выглядит так, как будто каждый хочет их сделать для чего-то своего. Кому-то надо «чтоб было как typeclass в Хаскеле», кому-то хочется просто побольше ошибок компиляции и ворнингов, кто-то уже бредит новой шаблонной магией, кому-то невтерпёж наворотить архитектуру как у Звезды Смерти на базе нового функционала. В итоге лебедь, щука и рак тянут воз во все стороны с ожидаемым результатом.

Модули
Прекрасная фича! Блаженный рай избавления от инклюдов, инклюд-стражей, уменьшение зависимости от мерзкого препроцессора. Вот вы и услышали коротенькое описание того, чего не будет в С++17. Дело в том, что модули нынче существуют в виде старой (от 2012-го года) реализации в Clang и относительно новой реализации от Microsoft. Конечно же, они не совместимы между собой (кто бы сомневался), а комитет по стандартизации пока не может решить, кто ему милее. Отличаются реализации, окромя мелочей, принципиальной штукой — трактовкой понятия макроса внутри модуля. Принадлежит ли он модулю, или должен быть виден наружу? Оба подхода имеют плюсы и минусы, поэтому решить, какой брать, пока не могут. Поэтому всё будет наихудшим из возможных способов: в С++17 не будет вообще ничего, а вот в следующем стандарте, попомните моё слово, наверняка опять подожмут хвост и с тезисом «нам нужна обратная совместимость» выберут худшее архитектурной решение (экспортировать макросы).

Транзакционная память
Об этом пока рано говорить как-то всерьёз. Слишком ново, слишком революционно, надо мышление перестраивать. Правильно сделали, что не включили в стандарт.
int f()
{
  static int i = 0;
  synchronized {
    printf("before %d\n", i);
    ++i;
    printf("after %d\n", i);
    return i;
  }
}


Унифицированный синтаксис вызова
«Не было консенсуса для принятия». Прям как у депутатов, когда заходит речь о борьбе с коррупцией. И ведь предлагают его Bjarne Stroustrup и Herb Sutter. Кто же у них там в комитете настолько авторитетен, что может им аргументированно противостоять?

Дедуктивный вывод параметров шаблонов
Ну, чтобы можно было писать
pair p(2, 4.5);

вместо
pair<int,double> p(2, 4.5); 


Красивая штука! Но «пока не всё понятно». Для auto им, главное, правила вывода типов понятны, а для шаблонов — нет. С чего бы?

Networking
Шел 2016-ый год, а С++ о сетях слыхом не слыхивал. И до 2020-го года и не услышит теперь! И чего это, казалось бы, народ вон вокруг на Эрланги всякие переходит для обработки сетевых запросов? А потому что уважаемый С++ до сих пор не озаботился какой-никакой сетевой функциональностью из коробки. (Ну я утрирую, конечно, не только и не столько поэтому. Но за державу обидно.)

Сопрограммы
Эта история уже была на Хабре, не будем повторяться: habrahabr.ru/post/278267

Контракты (два варианта)
Эта штука совершенно до сего момента выпадала из моего поля зрения, а ведь классно:
auto function(ArgType1 arg1, ArgType2 arg2, ArgType3 arg3)
 [[ pre: arg1 != 0]]
 [[ pre: arg1 < arg2]]
 [[ pre: global_predicate(arg3) ]]
 [[ post: return > 0 ]]
 [[ post: other_predicate(return, arg1) ]]
 -> ResultType;


Можно проверить что-нибудь полезное на этапе компиляции, линковки, рантайме. Может помочь в ситуациях «решили передавать первым параметром всегда true, а не false и вроде бы везде(?) исправили вызов». Теперь уже на этапе компиляции можно будет сказать везде или не везде. Я не очень расстроен тем, что это не вошло в С++17, поскольку выглядит слишком уж неожиданно, требует обсуждения и доработки. В добрый путь!

constexpr if
Продолжаем перетягивать рантайм на этап компиляции. Хотя конкретно эта фича может быть вполне полезна, поскольку может изрядно сократить количество кода, построенного на шаблонах (см. примеры в доке).

Reflection
Шли годы, а разговоры о рефлексии в С++ всё продолжались. Сейчас на рассмотрении аж три подхода:

Но пусть меня покрасят, если хотя бы один из них войдёт в С++17. Даже на счёт стандарта 20-го года я бы сказал можно принимать ставки 50/50.

Что мы имеет в итоге


С++, конечно, не стоит на месте. Видно, что люди работают, документы пишутся, компиляторы развиваются. Но задор С++11 утерян. Это чувствует и сам комитет ISO C++. Они больше не называют С++17 мажорным релизом стандарта. Теперь это у них очередная рабочая лошадка, которая станет в строй по графику, будет предсказуема, послушна и не встанет на дыбы. Наверное, это то, что нужно большому бизнесу — стабильность. Но для среднего программиста большой целью перейти на 17-ый стандарт не будет. Никто не будет бить кулаком по столу проджект-менеджера с требованием перейти на новую студию, мало кто будет качать ночную сборку Clang чтобы посмотреть, наконец, на вот эту bleeding-edge функциональность 17-го стандарта. Комитет ISO C++ говорит, что это хорошо — мы можем планировать свою работу на годы вперёд. В каком-то плане, да, безусловно. Но перемены — это ведь так захватывающе. Дорогой-любимый комитет ISO C++, ну пожалуйста, не бойся напугать нас новыми фичами языка!
C++17?

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Инфопульс Украина 84,10
Creating Value, Delivering Excellence
Поделиться публикацией
Комментарии 393
  • НЛО прилетело и опубликовало эту надпись здесь
    • +13
      Так остановитесь на C++11, никто ж не заставляет новым пользоваться.
    • +11
      Rust и swift теперь точно сожрут плюсы, тут к гадалке не ходи.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +5
          если C++ уйдет из прикладного программирования

          Не волнуйтесь, если это и произойдет, то лет через 15 только.

          • +5
            С++ тоже применяется на железе, в моей фирме для программирования под МК используется С++11
          • +4
            >>lang-runtime

            Swift, Clang, LLVM, Java HotSpot написаны на C++.
          • +16
            Ну про свифт это вы погорячились =)) С таким же успехом можно было сказать что и objective-C сожрет C)
            • 0
              swift нынче без obj-c рантайма на линуксе работает и есть проект по реализации основных foundation'ов чисто на нём.
              • +5
                Да это здорово. Но в дизайне Swift как языка упор делается на динамическую диспетчеризацию, в то время как в C++ на статическую.

                Т.е. как Objective-C, так и Swift это языки немного из другого семейства нежели C++. Т.к. если сравнивать их по быстродействию и гибкости, то Swift оптимизирован больше в сторону гибкости, а C++ в сторону быстродействия.

                Т.е. да, Rust действительно сильный конкурент для C++. Но Swift совсем нет, т.к. ни Java, ни Objective-C, ни C# не повлияли на положение C++ в своем сегменте.
                • 0
                  Мне кажется, что для ui swift удобнее и плюсов и раста. В 3ьей версии обещают интероперабельность с плюсами, а когда-нибудь мы быть может увидим и для rust'а интероперабельность, тем более мне кажется, что это то как раз проще сделать, чем с плюсами.
                  • +4
                    В 3ьей версии обещают интероперабельность с плюсами

                    Не обещают. Как раз наоборот — упоминают в разделе out of scope.
              • НЛО прилетело и опубликовало эту надпись здесь
                • +4
                  Не сожрал бы. Он намного медленней...
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • +6
                      С чего бы это? А может она обновляется 10 раз, а не 30, поэтому и берут С++.
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • +16
                          Ваш уровень аргументации, напоминает — "я знаю, каратэ, ушу, айкидо, бокс — и ещё много других страшных слов".
                          Про движки — спасибо, было весело....
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • +3
                              Правда? Это наверное потому что openGL — это чистый Си, вот так сюрприз…
                              С++ может нативно использовать Си, предоставляя более совершенную систему контроля типов, при том же быстродействии.
                              А если вы посмотрите глубже, то представьте себе… процессор выполняет микрокод, для него всё равно на каком языке написан софт — внутри процессора это всё микрокод...
                              • НЛО прилетело и опубликовало эту надпись здесь
                                • 0
                                  Расскажите тогда, как через "extern "C" {" передать std::vector ?
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • +4
                                      Перестаньте уже петросянить...
                                      • +5
                                        Ни у си ни у си++ нет ключевого слова structure.
                                    • +2
                                      "Опять для особенных" — да вы просто т… хамло, сударь...
                                  • +4
                                    Да уж DirectX на столько pure C что аж все его интерфейсы дыбом встают. Спасибо посмеялся.

                                    Основная работа по растеризации, применении шейдеров лежит на pure C драйвере устройста.

                                    Вы работаете с драйвером или api? Потому что в DX с шейдерами и девайсом и контекстом и всем остальным я работаю через классы. Апи по физике(коллизии) тоже как бы делается через интерфейсы (PhysiX). И о чудо Unreal С++, Unity С++, Cry C++. Никто не пишет движки на С уже давно, последний из С движков это id Tech 5 (да и то не уверен, 6 версия уже на С++)
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      • +2
                                        Таким путём всё можно свести к тому, что всё является обёрткой над asm. В общем классическая чушь С++ хэйтера ))
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                • +2
                                  компилятор языка С++ от интела переписан на С++ уже давно. LLVM — C++, gcc и то на С++ (обрезанный) перевели.
                              • 0
                                А вы пробовали сами на нём писать какие-либо библиотеки, а не тупо использовать то, что вам выкатила Apple?
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • +1
                                    Т.е. чистые библиотеки вы не писали, зато мнение имеете…
                                    Просто покажите код, который вы писали, или ссылки которые подтверждают ваши аргументы (про движки и т.п.), иначе это просто газификация луж...
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                        • +1
                                          Скатились в "Сам дурак" ?
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            • 0
                                              1. Я привёл список проектов, которые написаны на Си++.
                                              2. https://github.com/borisovs
                                              3. дискутировать с вами не интересно...
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                • –19
                                                  большего не стоите.
                                                  • 0
                                                    А если посмотреть внимательней?
                                                    image
                                  • +1
                                    У меня нет форм и её обновлений, все узкие места пишутся на C++.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • +1
                                      Chrome. Yandex.Search.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                    • +3
                                      Ошибаетесь, не все. Драйвера — часто при разработке WDM драйверов используется C++. «Рантаймы языков» — .NET CLR и Oracle JVM написаны на C++.
                                      Даже в embedded все чаще используют C++.
                                      • +2
                                        Напишите мне на C, пожалуйста, https://github.com/0xd34df00d/IAmMad/
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • +1
                                            Чем что метапрограммирование впиленное в компилятор языка С++ хуже чем программы на С которые генерят программы на С?

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

                                            Кто такой мышьхъ и какой авторитет в области C++ он имеет, я не очень знаю. Вспоминается почему-то лишь далёкое ксакепножурнальное детство.
                                    • +2
                                      Ну как же. С 90-х Objective-C стал частью GCC. Так что уже как 20 лет он не one-platform-specific.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                • +7
                                  Свежи предания, да верится с трудом. «Пожирателей» С++ было уже немало, а воз и ныне там. К тому же, с очередными потенциальными «пожирателями» Вы, скорее всего, сильно ошиблись: Rust — это, скорее, замена С, а не С++, а Swift — вообще «местечковый» язык, который вряд ли выйдет за пределе «яблочной» экосистемы. Ни тот, ни другой на замену С++ в принципе и не претендуют. Откушать где-то небольшую нишу, занятую сейчас С++ может и смогут, но сожрать… Я Вас умоляю!
                                  • +4
                                    Вы правы, Rust — замена C, и именно по этому он — конкурент C++, который тоже замена C. По субъективным ощущениям, раст — на голову выше плюсов почти по всем направлениям. Это я как заядлый плюсовик заявляю. Если ещё не пробовали на нём писать, то вам непременно стоит это сделать.
                                    P.S. Swift вообще не о то. Зачем он тут вообще? Какое отношение он имеет к области применимости плюсов?
                                    • +1
                                      > Rust — это, скорее, замена С, а не С++

                                      А можно раскрыть мысль? Несколько раз там и сям видел это мнение и не очень его понимаю. Может я слово «замена» в таком контексте как-то не так понимаю, может дело в предметной области, где человек работает, хз.
                                      • –1
                                        C (как и Rust) — языки системного программирования, а С++ — язык программирования общего назначения. То есть в теории, конечно, любой язык можно использовать где угодно, но на практике С++ в прикладном программировании удобнее, чем С, Rust, D, и прочие по списку (по крайней мере, на данный момент времени). Потому что в прикладном программировании на первое место выходит не столько сам язык, сколько различные библиотеки: GUI, графика, сети, то-сё. Так вот язык X сможет заменит С++ только тогда, когда на нём напишут большую часть библиотек, которые сейчас в буквальном смысле заставляют плакать, колоться, но писать на С++. Как только будут сопоставимые по мощи аналоги Qt, VTK, Eigen, и прочих библиотек, которые и держат С++ "на плаву", так сразу С++ может утонуть.
                                        • +2
                                          Т.е. вопрос в библиотеках, а не самом языке.

                                          Я тихо надеюсь, что ржавчина сможет себе уютное местечко в игрострое отгрызть у плюсов как раз потому, что при написании игровых движков принято велосипедить совершенно все)
                                          • 0
                                            Ну не только в библиотеках, а в инструментарии вообще (библиотеки, среды разработки, статические анализаторы и т.д. и т.п.). В общем и целом дихотомию "взлетит-невзлетит" можно свести к следующему простому правилу. Прямо здесь и сейчас в ограниченный промежуток времени новый язык может взлететь в определённой нише только если он: a) позволяет "из коробки" (желательно даже напрямую, без написания каких-либо "обёрток") пользоваться большой частью уже имеющегося в нише инструментария; либо б) богатый сопутствующий инструментарий в нише практически не нужен, так что накладные расходы на его разработку на новом языке в конечном счёте окупятся простотой дальнешего решения уже самой задачи на этом языке.
                                            • 0
                                              И да, я не думаю, что серьёзный игровой движок вам кто-то сейчас на Rust велосипедить будет. Это ж дорого, а потенциальных покупателей можно в итоге и не найти. Не только ведь игровые движки на С++ пишут, но и игры. Тут, вроде как, замкнутый круг: большинство игровых движков пишется на С++, потому что большинство игр пишется на С++, а большинство игр пишется на С++, потому что большинство игровых движков пишется на С++.
                                              • 0
                                                Честно говоря, я вообще почти не встречал проектов на C++ в которых бы не велосипедили. Никто не любит левые зависимости, как правило.
                                                Rust — это, скорее, замена С, а не С++

                                                Мысль не моя, и я как раз считаю, что Rust — прямой конкурент C++. Просто есть мнение, что Rust сильнее C++ не только в прикладной области, но и в области системного программирования, благодаря чему он также может составить конкуренцию C. Сейчас при написании системных вещей выбор стоит как правило C или C++. Смею надеяться, что в скором времени к кандидатам добавиться и Rust. Хотя, к сожалению, область очень консервативная. Зато серьёзную конкуренцию, как мне кажется, Rust может составить C++ в игрострое.
                                          • 0
                                            С++ — не замена С. Чётко очерченная на данный момент ниша С — системное программирование — лишь отчасти пересекается с таковой С++. С++ — язык общего назначения. На нём можно писать и системное, и прикладное ПО, и вот в нише прикладного ПО, которая несоизмеримо больше, С вообще ни разу не конкурент С++. C# да Java там основные конкуренты, ну VB.NET c Python ещё можно упомянуть, плюс в конкретных областях "местечковые конкуренты" (типа Fortran для высоко-производительных вычислений).
                                            • 0
                                              Согласен полностью. Просто я тут имел в виду именно область системного программирования, в которой по моему мнению C++ чувствует себя наиболее уверенно. И именно поэтому я сказал, что Rust превосходит тут C++, потому как он удобнее плюсов и для системного программирования и для прикладного.
                                        • 0
                                          По моему, давно пора.
                                          • +4
                                            Сходил к гадалке, сказала что С++ проживет еще вечность, а насчет Rust/Swift она не уверена. Сорри.
                                            • 0
                                              Той гадалкой был Бьёрн Страуструп.
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                • +4
                                                  Swift не поддерживается на Windows. И тут можно конечно разводить демагогию что "Windows не нужна", но сейчас, с точки зрения рынка, намного аппетитней, если уж на то пошло, выглядит C#. Он становится все более кросс-платформенным, для него поспеют зрелые тулы (посмотрите например на Project Rider).
                                                  Я ничего не имею против Swift, я просмотрел пару курсов на Pluralsight — он мне нравится, но пока Apple тянет одеяло на себя, ничего хорошего не получится.
                                                  • 0
                                                    Кому нужен C# если у нас есть F#?
                                                    • +1
                                                      У нас есть F# но у нас нет полноценного инструментария для того, чтобы этим F# воспользоваться в полной мере. Основная проблема — это конечно же вывод типов, а также нервозные попытки понять, в какой же точке из 20 строк в твоей фукции компилятор не смог вывести тип и ему нужно дописать hint. Помимо этого, без поддержки инструментария, использование любого ООП (которое потребуется использовать для взаимодействии с .NET framework) превращается в настоящую агонию. Например реализация сложного интерфейса "вслепую" — да вы даже с 5й попытки не напишете правильный код для нужных свойств и функций.
                                                      Еще одно крайне неприятное явление это конечно поведение апологетов F#. Если бы эти люди аргументированно вели беседы и отстаивали свой язык — я бы был только за. Но к сожалению фанаты F# не видят у себя в глазу бревна, зато постоянно пытаются предъявлять какие-то претензии к C#. Я вот недавно на конференции общался, показывал им свой код (у меня коммерческое приложение частично на F#, показывал что частичные рекурсивные шаблоны — это безумие, говорил что я уже после месяца работы возвращаюсь в код и в упор не понимаю что тут написано — а мне отвечали что "ну ты не умеешь его (f#) готовить". Блин. Ну ладно.
                                                      • 0
                                                        а мне отвечали что «ну ты не умеешь его (f#) готовить»
                                                        вот слово в слово знакомые фанаты и С, и С++
                                                        • +2
                                                          в какой же точке из 20 строк в твоей фукции компилятор не смог вывести тип

                                                          Я, конечно, не эфшарпер, но хаскелевский опыт подсказывает, что функции на 20 строк — это плохо.
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                        • +1
                                                          Да ну вас, где ж тут хейтеры. Swift выглядит как отличный язык, я не спорю. Просто для того чтобы писать на языке, нужно иметь веб-фреймворки, оконные классы, и все такое. На Mac, понятно, все это есть через Cocoa. На Windows ничего этого нет. То есть для бэкенда оно может конечно и подошло бы но, по-хорошему, это куча работы. Что касается "прикрутят", вы плохо знаете Microsoft — они сами добровольно не будут ничего такого делать. Посмотрите на OSX/Linux — есть ли там WPF, например. Его нет, и в ближайшем будущем не планируется. Бизнес-модель MS — это пересадить всех в облако.
                                                • +19
                                                  есть милый Rust
                                                  • +2
                                                    В D все чего ждут программисты С++ есть очень давно и из коробки. Есть даже возможность компилировать С++ библиотеки с помощью https://github.com/Syniurge/Calypso (правда еще не релиз, но Qt собирает).

                                                    Не вижу смысла сейчас начинать новые проекты на С++ если на том же D все будет проще и быстрее. По опыту своих коллег могу сказать, что язык осваивается за пару недель и через месяц можно писать уже писать вполне идиоматический код и не париться с тем, что в С++ будет только через 10-15 лет.

                                                    На всякий случай уточню, что я не против Rust т.к. для низкоуровневых вещей он наверно все же крут. Однако более высокоуровневые в разы проще писать на D.
                                                    • +4
                                                      Что-то он не особо как живым выглядит. Плюсы бы сейчас спасло более частое обновление стандарта, ну раз в полгода понемногу добавлять фичи, к примеру.
                                                      • –1
                                                        D жив, и ещё долго будет оставаться таким. Он малоизвестен, но это ему, скорее + в его положении: высокий уровень стандартизации и централизованность развития в виде двух главных разработчиков. Единственное, что ему не хватает — поддержки со стороны крупных корпораций и отсутствие нормальной IDE, хоть и в этой стороне есть подвижки.

                                                        • +13
                                                          У Go до сих пор нет нормальной IDE и ничего. Мне кажется у D проблема с тем, что он между нишами застрял сейчас. Он не слишком zero cost для системного программирования и при этом не так удобен, как всякие managed языки. В итоге там, где нужна детерменированая работа с памятью и другими ресурсами он не подходит, а где не нужна он проигрывает существующим языкам.
                                                          • 0
                                                            Я, конечно, не настоящий сварщик, т.к. на Go не писал уже пару лет, но https://plugins.jetbrains.com/plugin/5047 не выглядит не то, что мёртвым, но даже застойным.
                                                            • –2
                                                              Это Go скорее между нишами сидит. На D я могу решать куда больше задач чем на Go, при этом код будет местами значительно короче.

                                                              У D есть хорошие шансы понемногу занять нишу С++ т.к. Rust слишком низкоуровневый для ряда задач, а С++ слишком растолстели, чтобы на них можно было писать просто и легко. А других альтернатив нет.
                                                              • 0
                                                                Я пишу на D свои проекты уже несколько лет.
                                                                Что для вас zero cost и почему его нет в D? Если оттранслировать C++ код 1 в 1 на D, то при компиляции получится одно и то же.
                                                                Детерменированности больше, чем в C++: то, что в C++ UB, в D вполне себе DB. Есть asm statements, которые позволяют писать специфичный код на ассемблере.
                                                                При этом сам язык намного мощнее. Возьмём для примера «мама мыла раму» => «раму мыла мама».
                                                                Типичное решение на C++(возьмём даже буст для упрощения, попробуете написать на STL?):
                                                                boost::copy(«мама мыла раму» | boost::adaptors::tokenized(boost::regex("\w+")) | boost::adaptors::reversed, std::ostream_itertor(std::cout, " "));
                                                                Решение на D:
                                                                мама мыла раму.split.retro.join().writeln;
                                                                • 0
                                                                  У меня как не знакомого с D по вашему примеру возник вопрос на тему что в обоих вариантах болше похоже на приемущества/недостатки стандартных библиотек доступных для использования. Т.е. в С++ нужно «сложный» regex использовать, а в D есть готовые удобные методы: «split», «retro», «join».
                                                                  И только когда я начал читать wiki по D я понял что ваш пример совсем про другое, а именно про UFCS.
                                                                  На мой взгляд это очень удобная возможность для любого языка.
                                                                  (комментарий оставил для тех кто как и я не понял изначально сути примера). За пример спасибо.
                                                                  • 0
                                                                    Извиняюсь, харбапарсер съел кавычки в примере.
                                                                    Это я также к тому, что уменьшение размера кода способствует лучшей читабельности и надёжности.
                                                                    Намного легче заметить ошибку в паре строк кода, чем, скажем, в десятке.
                                                                  • +10
                                                                    Garbage Collector ни разу не zero cost. Причём тот самый cost не столько в накладных расходах по тактам и памяти. Сколько в недетерминированности и отсутствии RAII. Как ни прискорбно, все языки с автоматически управляемой памятью делают управление всеми остальными ресурсами полностью ручным.
                                                                    • +2
                                                                      Да, забыл. Garbage Collector также создаёт проблему таскания рантайма за собой и разборок между рантаймами в случае shared objects. Где язык без сборки мусора может спокойно работать на системном аллокаторе.
                                                                      • +1
                                                                        D поддерживает RAII, или я вас не так понял?
                                                                        GC можно вообще отключить и вызывать те же самые malloc/free самостоятельно.
                                                                        В стандартной библиотеке очень многие алгоритмы не вызывают аллокаций памяти.
                                                                        Недавно добавили аттрибут nogc, который гарантирует, что блок кода не делает вызовов к GC.
                                                                        Также появился std.experimental.allocator в котором собрано большое число аллокаторов, как раз для тех, кто не хочет использовать GC. Через пару версий станет стабильным std.allocator.
                                                                        Я писал множество приложений, начиная от web-сайтов, заканчивая 3D движками на D. Сборщик мусора проблемой никогда не был, наоборот, входит в привычку не заботиться о delete и утечках памяти.
                                                                        • +1
                                                                          ЕМНИП RAII в D делается через scope statement. Это, уж простите, костыль в стиле C# using. Как я сказал, проблема даже не в перформансе — Golang хорошо демонстрирует, что может быть быстрый нативный язык с GC. Проблема в том, что все остальные ресурсы теперь приходится менеджить руками. Или в D появились детерминированные деструкторы?
                                                                          По поводу рантайма. Если есть несколько динамических либ, каждая из которых собрана со своим рантаймом. Какой рантайм использовать? Особенно если исполняемый файл без рантайма? В общем решаемо, но головной боли добавляет.
                                                                          • +1
                                                                            Деструкторы структур в D следуют тем же правилам, что и в C++.
                                                                            Классы — всегда создаются в куче, поэтому деструктор тоже как и в C++ вызывать нужно руками. А чтобы не вызывать руками — на структурах делается подсчёт ссылок — враппер есть в стандартной библиотеке.
                                                                            Исполняемый файл без рантайма? Написан на ассемблере, что-ли? Сейчас даже обычное сишное приложение требует свой glibc, иногда той версии, которая отсутствует на хосте.
                                                                            А в примере с библиотеками: просто линковать статически. Это стандартный вариант сборки библиотек на D.
                                                                            • +1
                                                                              Ок, т.е. структуры в D следуют той же семантике, что и в С++? Признаю, был не в курсе.
                                                                              "Без рантайма" обычно означает "без среды исполнения, GC, etc.", т.е. максимум обвязка на системные функции вроде работы с памятью, сетью, ФС и т.п.
                                                                            • 0
                                                                              В D деструкторы для структур детерминированные — вызываются при выходе из области видимости
                                                                            • +3
                                                                              Если отключить GC, то отваливается большая часть библиотек, что мягко говоря неприемлемо для разработки. То есть это не аргумент ни разу.
                                                                              С такой же логикой и в go gc не обязателен, тут люди выкладывали реализацию.
                                                                        • 0
                                                                          Плагина для JetBrains IDEA и Microsoft VS Code, не считая кучи других, уже недостаточно?
                                                                          • +3
                                                                            Только большинству хватает вима емакса или саблайма, к тому же vs code это скорее аналог последнего, чем full featured ide. Всё-таки go весьма примитивный язык и на нем обычно редко пишут что-то огромное.
                                                                      • +2
                                                                        С++ жив за счёт C и всё же довольно мощной оптимизации при компиляции. Но и тут при таком развитии далеко не уедет. А вот какой смысл обновлять стандарт по чуть чуть, проблема в том, что компиляторы далеко не все быстро будут обновляться, да и при этом не все будут постоянно менять версии. Да и в итоге это превратит в кашу еще сильнее, сначала сделают фичу, а потом поймут, что она кривая, что, новую версию фичи добавлять?

                                                                        А на деле получается, что комитет хочет новые вещи получить в идеальном варианте, при этом именно как правительство, только своей мелкой кучкой. Пока они думают, другие делают, обкатывают на комьюнити и развиваются быстрее. С другой стороны по действиям комитета я могу сказать одно, дьдькам детство вступило в одно место и они хотят поиграться, вот и играют в своей песочнице и им просто наплевать на весь остальной мир, подождет.
                                                                        • –1
                                                                          Оптимизация C и C++ затруднена, из-за трудности обнаружения алиасов (когда к одной переменной или ячейке памяти можно обратиться несколькими способоми). До сих пор при желании выжать из компилятора максимум используют фортран. Хотя с появлением LLVM можно ожидать эффективной оптимизации и для других языков с ограниченным использованием указателей.
                                                                    • +10
                                                                      И ведь даже если к след. станадрту введут хотябы одну из ожидаемых фич, то "вау" уже не будет. Будет: "Спасибо конечно, что сделали фичу, которая нам нужна была 5 лет назад". Одно разочарование. Вхождение в стандарт концептов уже почти похоже на выход Half-Life 3.
                                                                      • +2
                                                                        Главное, чтобы не было похоже на Duke Nukem Forever...
                                                                        • +2
                                                                          Да чёрт с ними с концептами, где рефлексия? Банальная задача сериализации, возникающая в каждой второй программе на плюсах, без рефлексии нормально не решается.
                                                                          • +2
                                                                            Не наступйте на больное — сам жду. Вопрос в том, что если те фичи с которыми все примерно ясно не вошли, то про рефлексию compile/runtime и вовсе заикаться неудобно.
                                                                            • +1
                                                                              Как по мне, так compile-time рефлексии будет вполне достаточно. Сделали бы хотя бы её. Эх...
                                                                        • 0
                                                                          Ну учитывая что у модулей Stage 6, а у Ranges, Networking, Library Fundamentals 3, and Parallelism 2: Stage 7, есть вероятность что на следующих 2-3 встречах может все решится и появится как минимум TS.

                                                                          Забыли упомянуть про proposal на 2D Graphics библиотеку на основе Cairo
                                                                          • 0
                                                                            Если в библиотеке языка в 2016 только networking появился, то 2D графика там появится, когда все уже будут в шлемах виртуальной реальности ходить.
                                                                            • +1
                                                                              Если в библиотеке языка в 2016 только networking появился

                                                                              Не появился, не появится и даже в 2017, возможно, тоже не появится.
                                                                            • +5
                                                                              О Боже… Библиотеку мат. функций они уже в стандарт положили. По моему скромному мнению, С++ не хватает не столько стандартизированных библиотек, сколько стандартизированного (хотя бы де-факто) и лёгкого средства их доставки, сборки на месте и подключения (\me косится в сторону NuGet, NPM, Cargo, Go Get). Тогда можно было бы дорабатывать такие библиотеки независимо от ядра языка. И для простого добавления filesystem не требовался бы комитет.
                                                                              • 0
                                                                                В NuGet есть поддержка платформы «native», как раз для плюсов. Boost и проч уже там.
                                                                                • +1
                                                                                  В принципе интересно, но неясно, умеет ли NuGet нормально работать за пределами VS. Т.е. служить средством доставки зависимостей для, например, CMake или QMake проекта. Наверное, мне просто хочется аналога Cargo для С++:
                                                                                  • загрузка зависимостей, в т.ч. транзитивная
                                                                                  • транзитивная сборка зависимостей по необходимости
                                                                                  • автоматическое "пробрасывание" Include папок, с возможностью делать публичные и приватные
                                                                                  • мягкое или жёсткое версионирование
                                                                                  • в качестве источников как репозитории артефактов, так и гит-репозитории, УРЛ, локальные папки

                                                                                  Короче, возможность описать для модуля папку с инклюдами, папку с исходниками, список зависимостей — и получить сборку всего этого добра одной командой. Короче, я слишком многого хочу.
                                                                                  • 0
                                                                                    Вдогонку. Пока наиболее близок biicode, но нужно разобраться, как его правильно готовить. Вообще же один из основных камней преткновения — отсутствие модулей, из-за чего нельзя нормально изолировать транзитивные зависимости.
                                                                                    • 0
                                                                                      Ещё вдогонку для интересующихся. biicode умеет тянуть зависимости только из репозитория. Как я понимаю, такое хранилище можно сделать и локально. Но зависеть от Git репозитория или соседней папки нельзя. Так что мимо.
                                                                                      • 0
                                                                                        Зависеть от локальной папки — это прописывать в проектах относительные пути к инклюдам и либам, или что? Не очень понимаю ваш сценарий — как локальные папки представить «пакетами» (кроме как создать в локальной папке, скажем, .nupkg, и руками собрать и толкнуть его в репу). Как публиковать, без репозитория? Как добиться, чтобы у всех эти локальные папки были единообразны? Как версионность поддерживать через локальные папки?

                                                                                        Я вот наоборот стараюсь избавиться от зависимостей с локальными папками, ибо задолбало своей хрупкостью. Исторически у нас как раз повелось лепить зависимости через пути, и теперь хочешь сбилдать один проект — сыграй в угадайку, какие ещё репозитории нужно вытянуть и, главное, по каким папкам их разложить, чтобы начало собираться. Фактически локальные пути заставляют класть все зависимые проекты в пару-другую супер-репозиториев (типа IncludeCommon, Applications и т.п.), вырастающих в огромный ком, и которые всегда нужно клонировать в определённое место и билдать в определённом порядке, и этот порядок передаётся из уст в уста как древнее сказание.
                                                                                        • +2
                                                                                          Как раз наоборот — хотелось бы не иметь дела с такими костылями. Хотелось бы иметь систему сборки и доставки зависимостей в одном флаконе. Нечто, аналогичное Cargo. К сожалению, в среде С++ это нереально из-за зоопарка тех самых систем сборки. Поэтому хорошим вариантом была бы система доставки зависимостей и управления сборкой
                                                                                          • достать "пакет" откуда угодно — хоть из соседней папки, хоть из специального репозитория, хоть из гита
                                                                                          • собрать "пакет" используя его родную систему сборки; результат сборки — бинарники, заголовки и, возможно, какие-либо специфичные конфиг-параметры
                                                                                          • сделать результаты сборки и файлы заголовков видимыми в одной и той же форме, независимо от того, как хаотично они раскиданы в исходном проекте
                                                                                          • корректно "пробрасывать" транзитивные зависимости

                                                                                          В общем, мечты, мечты...
                                                                                          • 0
                                                                                            Ситуация еще сложнее, имеется два сценария сборки:
                                                                                            1) "разработка" — здесь желательно иметь как можно более свежий код зависимостей из релиз-веток, коррекция тестов в зависимости от баго-фиксов в них, полная пересборка при выходе мажорных версий…
                                                                                            2) "пост-релиз/установка" — установка чего-то более свежего, вероятно, сломает поведение, но баг-фикс может наоборот исправлять ( тут необходимо различать баг-фикс от минор/мажер версий, чего нет и не предвидится, как результат либо полное ручное управление, либо сборка «на свой страх риск» ), как костыль — хранить все зависимости в установочном пакете.
                                                                                            • 0
                                                                                              Мне кажется, вы пытаетесь возложить на пакетный менеджер несвойственную ему работу по подготовке и сборке файлов для пакета. Ведь «достать исходники откуда угодно, сбилдать чем угодно, упорядочить хаос» — это задача со слишком многими переменными, её должны выполнять майнтайнер пакета и билд-инженер. У package manager-а задача маленькая — получить на вход манифест и файлы на выходе билд-сервера, собрать файлики в кучку согласно описи, заархивировать, проштамповать версию, выдать анонс, хранить пакеты вечно, выдавать пакеты и их зависимости согласно запрошенной версии. А откуда на входе файлики появились — не его забота, для этого есть билд-сервер, тот знает где, что и как брать, как это билдать и как передать сбилданое package manager-у.
                                                                                              • 0
                                                                                                Скорее всего да. А ещё я хочу от C++ того, чего в нём не будет ещё лет 5 — нормальной модульности.
                                                                                                Вообще же частенько бывают ситуации, когда поднимать пакетный репозиторий бессмысленно — например требуется всего-то вытаскивать автоматом при сборке парочку бинарных SDK, маленький репозиторий с общим для нескольких продуктов кодом и пару опен-сорс пакетов вроде юнит-тестового фреймворка и логгера.
                                                                                      • 0
                                                                                        Насколько я понимаю, для NuGet заточен исключительно на MSBuild (он добавляет свои msbuild targets к проектам, а пакеты потом накидывают свои), и на PowerShell (для запуска скриптов), поэтому с СMake/QMake оно дружить не будет. А так вроде всё перечисленное в списке есть, только напрямую из гита конечно ничего качаться не будет, пакеты нужно описать, упаковать и выложить как артефакт, можно в локальную папку, можно на любой NuGet-хост. Никто не мешает класть в пакет исходники — если это нужно для обычной сборки, то клади в обычный пакет, если только для отладки — клади в symbols-пакет. Собственно, boost наглядный пример — там одни лишь исходники.
                                                                                • +11
                                                                                  Ни boost::FS, ни "новая" std::FS до сих пор не поддерживают пути длинее PATH_MAX (260 байт) в Windows, которые самой системой поддерживаются уже почти 10 лет. При этом все красиво и здорово, итераторы и emplace, только вот по факту "новая" функциональность ничуть не лучше какой-нибудь замшелой _mkdir из direct.h, прости рандом.
                                                                                  • +1
                                                                                    Ну неправда же. Через UNC всё отлично поддерживается.
                                                                                    Во всяком случае, с boost::filesystem::create_directories и boost::filesystem::copy_file никаких проблем.
                                                                                    В отличие от дотнета, кстати.
                                                                                    • +7
                                                                                      Фиг там, извините. Тот факт, что create_directories любезно вызовет CreateDirectoryW, если ей дать полный путь с префиксом \\?\ — это замечательно, конечно, только вот это не поддержка ни разу. Ни канонизацию, ни траверс, ничего с длинным путем нормально сделать нельзя, а соотвествующие тесты даже закомментированы (filesystem\test\path_test.cpp). Т.е. весь траверс и канонизацию предлагается написать самому, и непонятно, зачем тогда вообще такая библиотека.

                                                                                      • +2
                                                                                        Мда, и правда.
                                                                                        Я тут совершенно недавно столкнулся с этой проблемой в повершелле (читай — .net), обычный Copy-Item при копировании файлов терял длинные имена и зацикливался на вложенных reparse point-ах.
                                                                                        В итоге переписал его на вызовах winapi и бусте — надо было матчить reparse point-ы, и я решил не полагаться на обёртки. А вот всякие create_directories и copy_file было лениво писать, поэтому #include <boost/filesystem.hpp> и вперед.
                                                                                        Строго говоря, стандартные функции WinAPI тоже упираются в MAX_PATH. С одной стороны — всем страшно ломать совместимость, с другой стороны — для поддержки достаточно тривиальных вызовов приходится городить костыли. В любом случае, странно обвинять в этом
                                                                                        комитет — кто его знает, какие ещё костыли навесят на UNC в следующих релизах. Я бы начал с выпиливания букв, например.

                                                                                    • 0
                                                                                      Ни boost::FS, ни «новая» std::FS до сих пор не поддерживают пути длинее PATH_MAX (260 байт) в Windows, которые самой системой поддерживаются уже почти 10 лет.

                                                                                      Печаль в том, что исчезающе мало софта поддерживает такие пути, то есть на системном уровне такие пути есть, а на прикладном практически отсутствуют, в том числе в стандартном софте. Та же история с "/" в путях — формально поддерживается, но на деле через раз.
                                                                                      Вроде, в .NET поддержку длинных путей не добавили как раз по этой причине: приложение запросто насоздаёт длинных путей, а остальной софт из-за этого поломается.
                                                                                      • +1
                                                                                        Qt их поддерживает из коробки начиная с четвертой версии, поэтому я ими успещно пользовался и был не в курсе проблем с ними. А потом по лицензионным причинам пришлось отвязывать ПО от Qt, и проблемы неожиданно вскрылать так ярко, что теперь, видимо, придется писать свой велосипед по лекалам какого-нибудь FAR Manager'а, код которого открыт и длинные пути который поддерживает в полном объеме.
                                                                                      • 0
                                                                                        Ни boost::FS, ни «новая» std::FS до сих пор не поддерживают пути длинее PATH_MAX

                                                                                        Что-о-о-о?!? Серьезно? Это ж каких масштабов fail. Как-то я это совсем упустил, хотя boot::fs использовал.
                                                                                      • +12
                                                                                        А модули все-таки жалко.
                                                                                        • +2
                                                                                          Мне очень жалко. Слов просто нет. Если все остальные фичи действительно еще сырые, то блин для модулей 4 года как есть 2 реализации — обсудить да станадартизировать…
                                                                                          Я готов смириться с откладыванием всего остального, но это наследие препроцессора Си…
                                                                                        • +1
                                                                                          Унифицированный синтаксис вызова правильно отменили. Нет, идея отличная, но хотели вывернуть её с ног на голову. D продемонстрировал, что obj.foo(args) должно искать сначала метод, а потом функцию foo(obj, args). А хотели унифицированным сделать foo(obj, args), чтобы он искал метод. Это решает проблему с begin/end, но неудобно для остальных случаев, например статических расширений классов.
                                                                                          По статье не понял, а библиотеку Ranges всё-таки приняли?
                                                                                          • 0
                                                                                            Ranges нет, её Ниблер ещё не доделал вроде как.
                                                                                          • +1
                                                                                            Спасибо за интересную статью!
                                                                                            Но если бы стиль был менее быдловатым, читать было бы в разы приятнее.
                                                                                            • +1
                                                                                              С одной стороны соглашусь, но именно из-за стиля статья очень бодро читается. А главное — все понятно.
                                                                                              • –3
                                                                                                Пожалуйста.
                                                                                                Нет, не было бы. Академический стиль нуднее в разы, а тут "пока всё им своими словами объяснил — сам уже даже понял".
                                                                                                • +10
                                                                                                  Ну ок, ёпта
                                                                                                  • +4
                                                                                                    Академический стиль нуднее в разы

                                                                                                    О, а неприятие академического стиля многое объясняет.
                                                                                                    • +2
                                                                                                      Если стиль каждого автора, мало-мальски чувствующего язык и умеющего ловко складывать слова в предложения, называть "быдловатым", а под академическим понимать "стиль" письма среднего не очень одаренного шестиклассника, то ок — выбираю первое.
                                                                                                      • +2
                                                                                                        А если ещё поиграться с терминами, то можно будет вообще что угодно доказать.
                                                                                                • +2
                                                                                                  Дедуктивный вывод параметров шаблонов

                                                                                                  make_pair так и работал всегда.
                                                                                                  • 0
                                                                                                    Но не писать же по отдельной функции на каждый такой шаблон?
                                                                                                    • 0
                                                                                                      А вот странно вообще, что типы функций (шаблонных) выводятся автоматически даже в С++03, а типы конструкторов нет. Так что это скорее не нововведение, а багфикс.

                                                                                                      • +1
                                                                                                        Вот этого-то фикса в C++17 и не будет, как говорится в статье.
                                                                                                        • 0
                                                                                                          Точно. Спасибо.
                                                                                                        • +1
                                                                                                          А как ты отличишь шаблонный конструктор обычного класса от обычного конструктора шаблонного класса, а если это шаблонный конструктор шаблонного класса?
                                                                                                          Такие штуки в плюсах ни один стандарт не исправит уже без скальпеля. А комитет упорно не хочет брать его в руки.
                                                                                                          • +1
                                                                                                            А зачем из различать? Если все параметры подставлены, типы их известны, неизвестных типов нет, то не возникает противоречий. Шаблонный ли это конструктор или шаблонный ли это класс — типы известны, ни что не мешает конкретизировать тип.
                                                                                                            Такой трюк не пройдёт с шаблонным конструктором шаблонного класса, т.к. у класса и конструктора в шаблонах будут разные наборы типов. Но этого и не требуется.

                                                                                                            • +1
                                                                                                              компилятор C# в случае неоднозначностей просто требует указать тип явно.
                                                                                                      • +11
                                                                                                        Думаю, в случае с С++ не стоит его дальше развивать вообще — слишком много унаследованных проблем. Вместо этого комитету стоило бы создать рабочую группу по разработке принципиально нового языка, базирующегося на классическом си-подобном синтаксисе и включающем все лучшее из С++, C#, D, Go, Rust, Swift и некоторых других языков. И предусмотреть некий стандартизированный механизм взаимодействия кода на двух языках — чтобы можно было переходить постепенно, добавляя в старые проекты на С++ новые файлы с кодом на новом языке.
                                                                                                        Вот такое решение было бы пожалуй оптимальным — с одной стороны и "совмесимость" в каком-то виде осталась бы, с другой — можно все написать с нуля, учтя ошибки прошлого.
                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                          • +20
                                                                                                            А потом создать ещё один, который включит всё лучшее из перечисленного и того нового, что был создан.
                                                                                                            • +5
                                                                                                              Ну так на то и прогресс чтобы постоянно что-то совершенствовать и учиться на ошибках...
                                                                                                              • +1
                                                                                                                Лет 30 назад предлагали делать язык как систему разноуровневых диалектов, от элементарных низкоуровневых, до высокоуровневых (сейчас бы сказали DSL) специализаций. По своей сути gcc — "коллекция" разных языков и их диалектов, и таковой будет оставаться. А то, что в "c++" нет средств идентификации диалектов, и соответственно средств унифицированной компиляции делает "с++" незаконченной и хрупкой системой, с долгим "legacy", дублированием в различных библиотеках функциональности, медленным развитием (скорее, отставанием).
                                                                                                                Пока же нет стандарта ядра языка и общих принципов для формирования всего кластера диалектов, очевидной системы синтаксиса и семантики. Хотя, что мешает объединить rust, c++17, go, D2, java(или kotlin) в единую систему диалектов, с единой runtime, общими библиотеками, кроме корпоратократии?
                                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                  • +2
                                                                                                                    Ms пробовали такое сделать, но .NET языки писались специально таким образом что бы работать на общем рантайме и с одной стандартной библиотекой. А перечисленные вами языки не эквивалентны друг другу, в Rust например ADT есть, а Go даже перечислений нет.
                                                                                                                    • 0
                                                                                                                      … Та идея не про общий «runtime» (и .NET, или LLVM тут не причем)! А, именно, про абсолютно разные диалекты. Что то похожее если бы в TopSpeed вместо модулы-паскали-с-с++ были бы языки с++-go-java-d. Самое важное, это понятный синтаксис, возможность интегрировать программы на разных языках в единый проект.
                                                                                                                      … Практически с++03, с++11 и с++14 это такие диалекты, можно читать и понимать и тот, и другой, но нет средств интегрировать и компилировать в единый проект, без ручного выбора в конфигах ключа компиляции. К тому же, с++ язык многопарадигменный, если строить язык как набор диалектов, то столь сложную систему строить не обязательно, всю область можно покрыть несколькими выделенными подмножествами языка, от «студенческого/школьного», и до «полномасштабного» с/без семантической совместимости с си, и нацеленного на крупные проекты со средствами валидации и strict-владением… про эквивалентность диалектов никто и не говорит, они по определению неэквивалентны, это инструменты нацеленые на решение разных/специфичных задач (DSL), и "колоть орехи" всем стеком диалектов никто не предлагает.
                                                                                                                      Именно жедание запихнуть все и вся, тогда, привело к появлению монструозных языков PL/1, Ada… путь которых повторяет С++, и желание удовлетворить одним языком всю прикладную область и приводит к тому, что программисты получают от комитета по стандартизации язык который призван решить задачи "давно прошедшей войны".
                                                                                                                      • 0
                                                                                                                        Тогда что вы подразумеваете под системой диалектов, набор языков с одним бэкендом компилятора и системой сборки?
                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                          • 0
                                                                                                                            Диалект — один из системы родственных языков. В данном случае: объединенный схожим синтаксисом (для с++ все версии имеют общий синтаксис и семантику в рамках с++98[шаблоны+stl] "по дизайну", и каждая имеет уникальное расширение), языковым ядром(общие библиотеки, шаблонной магией обеспечено, но например java или go имеют собственные библиотеки, не совместимые с с++, т.е. ядра не совместимы в таком виде, желательно чтобы был общий доступ к единой стандартизованной библиотеке из любого диалекта)… а вот как все это будет организованно, единым бекэндом или дубликатами библиотек на разных диалектах — не суть стандарта, это проблемы реализации, а в стандарте должны быть описаны единые принципы строительства синтаксиса, минимальное языковое ядро и описание диалектов, и библиотеки. В аде были требования к среде компиляции, исполнения и валидации компилятора, возможно, что со временем это станет стандартом, аде, borland и topspeed это не помогло.
                                                                                                                            Вот почему Вы следствие ставите во главу? единая система сборки — это самый простой и логичный путь, но не самоцель, главное — смешение "старого" и нового кода, решение задач адекватными инструментами, а не "гиганской универсальной мухобойкой", средств позволяющих развивать язык не нарушая целостности языковой системы и не генерируя конфликты из-за развития синтаксиса.
                                                                                                                            Но есть и "ложка дегтя" выбор ядра языка и стандартных библиотек определит всю историю и скорость развития языка и обучение языку.
                                                                                                                            • 0
                                                                                                                              В таком случае я не понимаю чем вам не нравится .NET или LLVM.
                                                                                                                              Синтаксис не может служить критерием для определния родства в вашем понимании, многие C-подобные языки хоть и могут общаться через C ABI ушли от него довольно далеко, в тоже время Objective-C строгое надмножество C, но его синтаксис далек от предка.
                                                                                                                              • 0
                                                                                                                                А если подумать? Может Вам помочь llvm-код сгенерированный haskell понять, что делает программа на нем?
                                                                                                                                многие C-подобные языки хоть и могут общаться через C ABI ушли от него довольно далеко
                                                                                                                                , но «ядро» юникс-стайл поддерживают все, можно за минимальное ядро взять си-рантайм…
                                                                                                                                Objective-C строгое надмножество C, но его синтаксис далек от предка
                                                                                                                                , но ничего не мешает также надстроить и остальные… си-интерфейс ( ffi ) — это архаизм, дефект вызванный «слабым» линковщиком, не знающим, какие исходники на каком диалекте написаны, в llvm он не намного интелектуальнее, а еще модула-2 продемонстрировала необходимость интелектуального линковщика для многозадачных приложений, в RSX-11 линковщик знал больше, чем «современные», и можно было писать приложения суммарно превосходящие имеющуюся виртуальную память… ELF даже близко не стоит к необходимым требованиям, нет средств к описанию приложения как микросервисов, раздельных куч, рантаймов, динамическая линковка — организованна как костыль… и все эти недостатки Вы нереносите на язык, а как, например, java, реализация это отдельная «фича» и к языку не должна была иметь никакого отношения, и в с++ рантайм, также, сильно ограничен реализацией на средах унаследованным со времен юникс-вей. Как и сейчас, запихнуть различные runtime можно, просто приложение становится такой микро-OS, которая запускает различные нити и runtime вручную, только нужно линковщику объяснить, что если Вы не используете java, то его runtime прилинковывать не нужно, но остается вопрос с маршалингом, если линковщик «тупой», то «маршилить» должен компилятор, вставляю ненужные заглушки для маршалинга в разные диалекты/языки/runtime.
                                                                                                                                • 0
                                                                                                                                  в с++ рантайм, также, сильно ограничен реализацией на средах унаследованным со времен юникс-вей
                                                                                                                                  Страуструп писал что это было сделано специально.

                                                                                                                                  А как вы относитесь к Оберону?
                                                                                                                                  • 0
                                                                                                                                    Прошу прощения, я вспомнил про де старые публикации, потому, что эти конфликты комитетов по стандартизации случились не в первые, были войны стандартов (между европейским и американским комитетами стандартизации разных языков), особенно ярые бои фортранов (закончившиеся тем, что каждый компьютер имел несколько диалектов, или хотя б свой собственный, "уникальный и неповторимый"), после стандартизации ады в 198х вылез "багофич" с наследованием зависимостей, решение которой было предложено сразу, но комитет отказался, мотивируя соблюдением принципа "совместимости" (решение ограничивало прозрачность зависимостей), тормозил развитие языка, результат известен.
                                                                                                                                    Было очевидно, что появятся новые языки, и чтобы не повторяли прежних ошибок сделали такое предложение, построенное по аналогии с Дэйкстровскими уровнями абстракции.
                                                                                                                                    Страу(в)струп вероятнее всего был в курсе этих процессов, но принял такую точку зрения. Это его персональное решение, логичное или нет — не важно. Вот действия комитета вызывают вопросы.
                                                                                                                                    Оберон — язык как язык, ничего особенного, если бы кто-то из корпораций взял его, то он разросся бы по масштабов c#, таково историческое развитие, сопротивление Вирта проигнорировали бы, видимо по этому и не отдал. Строить "диалекты" корпорации не хотят, хотя можно заработать на обучающей литературе, продавать DSL на заказ, создавать собственные стандарты. Если только один недостаток — распыление "комьюнити", но оно автоматически происходит, просто люди переходят на другие языки, и не возвращаются.
                                                                                                                                    • 0
                                                                                                                                      Страуструп написал в "Дизайне и эволюции C++" что рантайм специально был сделан на уровне C что бы C++ был таким же переносимым. (Но потом накрутили шаблоны, исключения и рантайм резко стал сложнее.)
                                                                                                                                      Оберон я упомянул потому что он воспринимается как логическое продолжение идей Вирта после Модулы, в том числе продвинутый линковщик, один язык (общего назначения) для прикладного и системного уровня.
                                                                                                                                      PS Последняя часть мне напомнила что C++, Go, D, Rust в том или ином смысле писались как языки общего назначения, а Java вычеркнем потому что это все же VM-язык.
                                                                                                                                      • +3
                                                                                                                                        Но потом накрутили шаблоны, исключения и рантайм резко стал сложнее.

                                                                                                                                        Какое отношение шаблоны вообще имеют к рантайму?
                                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                          • +5
                                                                                                                                            мильоном ненужных реализаций для разных классов.

                                                                                                                                            Ну вообще-то шаблоны реализуются только для тех типов, которые используются. Там просто не может быть "ненужной" реализации.
                                                                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                              • +4
                                                                                                                                                То есть вы предпочитаете писать реализацию вручную для каждого типа? В чём в таком случае будет разница?
                                                                                                                                                • 0
                                                                                                                                                  он имел ввиду дженерики (а-ля C#, которые реализуются в рантайме), хотя дженерики и шаблоны это две большие разницы, которые имеют разный use case.
                                                                                                                                                  • 0
                                                                                                                                                    Я, в общем, так и подумал. Но у С++ есть RTTI, хочется сэкономить размер бинарника — всё в руках разработчика. Правда случаев, когда нужно настолько экономить — один на сто тысячь.
                                                                                                                                                    • 0
                                                                                                                                                      Если я всё правильно понимаю, используя RTTI мы позволим исходнику скомпилиться в случае неправильно указанного типа. В таком случае, я предпочту шаблон и N лишних килобайт в бинарнике, которые будут критичны разве-что в шеллкоде или коде для встраиваемых систем.
                                                                                                                                                      • +2
                                                                                                                                                        Да, позволим. В Java, впрочем, дженерики тоже не страхуют от рантайм-ошибок. Ведь
                                                                                                                                                        new ArrayList.getClass() == new ArrayList.getClass()
                                                                                                                                                        и если вам передадут массив из Object'ов, вы точно так же можете привести типы с ошикой и получить исключение.
                                                                                                                                                        (про необходимость оборачивать int в Integer можно тоже упомянуть, т.к. странно экономить считанные килобайты памяти на бинарнике и при этом использовать языки с рантаймом, сборкой мусора и компиляцией на лету)
                                                                                                                                                        • 0
                                                                                                                                                          Парсер убрал угловые скобки, там разные типы были в ArrayList'e.
                                                                                                                                                          • 0
                                                                                                                                                            Собственно, в большинстве случаев мне было-бы приятнее такие вещи исключать на этапе компиляции, как минимум, чтобы не нагружать QA ненужной работой.
                                                                                                                                                          • 0
                                                                                                                                                            У вас там зря тоже стоит, дженериков нет в плюсах.
                                                                                                                                                            • 0
                                                                                                                                                              У вас там зря тоже стоит, дженериков нет в плюсах.
                                                                                                                                                              Да я знаю. Я имел в виду RTTI в плюсах и дженерики в джаве не страхуют от ошибок приведения типов.
                                                                                                                                                          • 0
                                                                                                                                                            используя RTTI мы позволим исходнику скомпилиться в случае неправильно указанного типа

                                                                                                                                                            Простите, что?