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?

Инфопульс Украина

271,60

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.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          +1
                                          жги исчо...
                                        +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.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            Так и C++ тоже с мутной предисторией.
                                      +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 мы позволим исходнику скомпилиться в случае неправильно указанного типа

                                                                                                                                                                Простите, что?
                                                                                                                                                                  0
                                                                                                                                                                  используя RTTI мы позволим исходнику скомпилиться в случае неправильно указанного типа

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

                                                                                                                                                                  Вы можете привести один тип к другому, и если объект во время исполнения является объектом другого типа, вы получить nullptr или исключение.
                                                                                                                                                                    0
                                                                                                                                                                    А, ну так это не неверно указанный тип, а, скорее, недостаточно полно (в случае даункастов).
                                                                                                                                                                      0
                                                                                                                                                                      Что вы имеете в виду под "недостаточно полно указанный тип"?
                                                                                                                                                                        0
                                                                                                                                                                        Что его надо приводить к нижележащему.
                                                                                                                                                                        Ну вот есть у вас указатель на виджет в окне, вы знаете, что там лежит line edit, но указатель-то не прям на класс line edit'а, а на корневой. Придётся приводить.
                                                                                                                                                                        Есть варианты, но они более редки в коде на C++, насколько я могу судить.
                                                                                                                                                                          0
                                                                                                                                                                          Да, это я и имел в виду.
                                                                                                                                                              +2
                                                                                                                                                              Основная разница дженериков и шаблонов в C++ — отсутствие дженериков в С++.
                                                                                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                                +7
                                                                                                                                                                Вы сейчас придумываете на ходу или можете подкрепить свои утверждения реальными примерами? Ещё раз повторюсь, шаблоны инстанциируются только для тех типов, для которых они используются. Или вы утверждаете, что присутствие шаблонов в коде означает его плохую архитектуру? Архитектура приложения и детали имплементации между собой в данном контексте не связаны.
                                                                                                                                                                  0
                                                                                                                                                                  Memory is overrated, performance is much more valuable.
                                                                                                                                                                    0
                                                                                                                                                                    Обмазываюсь шаблонами, кучей шаблонов, вроде такого, такого, такого или вообще такого, с дебаговой информацией бинарники жирнющие, да, а вот после стрипа — как будто и не было никаких шаблонов. Правильно всё Satus говорит.
                                                                                                                                                            +1
                                                                                                                                                            Извините, несколько раз редактировал комментарий и поэтому шаблоны получились в рантайме) Даже страшно какой срач получился из-за глупой ошибки.
                                                                                                                                    +3
                                                                                                                                    Мне кажется для этой цели и был создан Rust. Хотя от нового мощного C# v2 я бы не отказался. Но язык такой гибкий, что практически любые фичи можно добавлять прямо в него, не перелопачивая всё, а учитывая Rosylin можно самому описывать диалект не просто, а очень просто. Добавление кортежей в шарп на CLRium'е 2015 года заняло ровно 50 строчек кода, если я правильно помню. Прикручивай к этому всему подсветку в студии — и можно выпускать новую версию :)

                                                                                                                                    Поэтому managed-языки имхо будут вскоре очень сильно потеснены шарпом, и влезать туда нет смысла — убьет.
                                                                                                                                    А что касается системного — то уже есть раст, который и задумывался как "более лучший С++".
                                                                                                                                    В таком случае как раз лучше тогда войти в комитет по расту и там ускорять внедрение новых фич.
                                                                                                                                      –3
                                                                                                                                      Rust по какой-то причине (намеренно?) сделан внешне слишком не-сиподобным. В отличие от C# или Java, его синтаксис тяжело воспринимается. Не знаю почему, но это так.
                                                                                                                                      Я воспринимаю все это лишь как попытки и приближения к идеалу. Сейчас хорошо бы, если Rust, Swift, D и Go откусят от С и C++ приличные куски… посуществуют какое-то время все вместе… а там будет видно.
                                                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                          +3
                                                                                                                                          Мне кажется, что он тяжело воспринимается не из-за синтаксиса (его как раз упростили), а из-за того, что компилятор должен убедиться в том, что все в порядке. То есть элементарный код вида
                                                                                                                                          ```csharpConsole.WriteLine("Введите число");
                                                                                                                                          int i = int.Parse(Console.ReadLine());
                                                                                                                                          Console.WriteLine("Вы ввели {0}", i);
                                                                                                                                          Превращается вот в это:
                                                                                                                                          ```rustprintln!("Введите число");
                                                                                                                                          let mut guess = String::new();
                                                                                                                                          io::stdin().read_line(&mut guess)
                                                                                                                                          .expect("Не удалось прочитать строку");
                                                                                                                                          let guess: u32 = guess.trim().parse()
                                                                                                                                          .expect("Пожалуйста, введите число!");
                                                                                                                                          println!("Вы ввели {}", guess);
                                                                                                                                          И тут уже нужно разбираться, что за expect, что за передача с '&' и так далее. Тут проблема не в синтаксисе, а в том, что в этом языке защитное программирование возведено в абсолют и только оно позволяет компилятору грамотно делать свою работу. Пример на шарпе можно также переписать, чтобы оно не бросало исключение, и это будет весьма небольшое изменение (Parse на TryParse), но зачастую на это "забивают", либо дописывают потом "щас будем вводить только число, а когда прототип будет работать, добавим уже нормальную проверку". Да, на расте есть unwrap, но за его использование очень ругают, поэтому весь код обрастает кучей проверок. Для системного программирования это хорошо, ошибок раст не пропустит. Но порог вхождения сильно повышается. Синтаксис этого не меняет, наоборот, синтаксис очень короткий и информативный. Не опускаясь до абсурдности вроде J. Он мог бы быть лучше (возможно), но это явно не самый плохой синтаксис из тех, что мог бы быть. С точки зрения теории принятия решения, оптимальное решение — которое не нравится всем в равной степени. А не то, которой полностью устраивает кого-либо.

                                                                                                                                            +1
                                                                                                                                            Извиняюсь, хабр что-то комментарий переоформил как-то дико.

                                                                                                                                            Console.WriteLine("Введите число");
                                                                                                                                            int i = int.Parse(Console.ReadLine());
                                                                                                                                            Console.WriteLine("Вы ввели {0}", i);

                                                                                                                                            println!("Введите число");
                                                                                                                                            let mut guess = String::new();
                                                                                                                                            io::stdin().read_line(&mut guess)
                                                                                                                                                .expect("Не удалось прочитать строку");
                                                                                                                                            let guess: u32 = guess.trim().parse()
                                                                                                                                                .expect("Пожалуйста, введите число!");
                                                                                                                                            println!("Вы ввели {}", guess);
                                                                                                                                              +4
                                                                                                                                              Здесь основное отличие — паттерн обработки ошибок. А не управление ресурсами, время жизни и т.п.
                                                                                                                                              Rust использует ADT и пакует ошибки как второй вариант результата функции. А у C# возможные ошибки в сигнатуре не фигурируют.
                                                                                                                                              А по поводу защитного программирования — я сейчас, когда пишу на C++, регулярно думаю, что с какой-то фичей из Rust мог бы написать 20 строчек вместо 200.
                                                                                                                                                +2
                                                                                                                                                Дело не в том, что паттерн обработок ошибок другой. А то, что в большинстве реально используемых языков на него можно забить. Ну Unhandled Exception, подумаешь! Очень много кода не проверяет ссылку на null, например, ибо предполагается "получили null — зачем проверять? Все равно при первом же доступе к любому члену или методу выкинется эксепшн". А в расте нужно ВСЕ ВОЗМОЖНЫЕ кейзы прорабатывать. Грубо говоря, если элементарная программка на С++ занимает разработку месяц, из которой сначала пишется прототип за неделю, а потом 3 недели вылавливают баги, то на расте потратишь 3 недели, но все эти 3 недели будешь бороться с компилятором, чтобы он позволил твоему коду запуститься. Да, после запуска с 99% вероятностью код можно сразу пускать в продакшн, багов там нет. Но первичный результат "хоть как-то работает" будет на плюсах почти сразу, а на расте будет "всё или ничего". Либо правильно работающая программа, либо не компилирующаяся. В плюсах весьма вероятно получить работающее решение, но падающее при некоторых хитрых условиях. Компилятор же раста скорчит морду, и программисту придется долго разбираться, что же там не так. И хотя человек не прав, а компилятор — прав, в первом случае у него иллюзия, что он быстро написал, и просто приводил в порядок, а во втором случае ему кажется, что компилятор вставляет палки в колеса, мешает жить и вообще без этих долбаных проверок жилось бы намного лучше.
                                                                                                                                                  +6
                                                                                                                                                  Хотел ответить развёрнуто, но не буду. Аргументы и так известны. Скажу просто. В С++ сделать неправильно просто, а правильно — не просто сложно, а требует иногда борьбы с компилятором. В Rust наоборот, сделать правильно проще, чем неправильно — пусть и порог этого действа повыше. И это есмь хорошо. Потому что лично я устал обрабатывать все краевые и не очень случаи своей головой. И я хочу работать с языком, у которого сравнительно простая и понятная семантика (да-да, borrow checker — это три простых правила и немного тренировки), а не 1500 страниц стандарта, забитые наполовину undefined behavior и implementation defined. Дальше продолжать не буду, дабы не надоедать.
                                                                                                                                                    –3
                                                                                                                                                    Что значит правильно, неправильно? Какое то странное понятие использования инструмента. С++ позволяет сделать так как ты хочешь, а не так как хочет компилятор в случае раста. Ну хочу я написать код который в определённых случаях будет давать UB, но я знаю что буду использовать его только для случаев в которых UB невозможен.
                                                                                                                                                    Просто С++ более требователен к опыту программиста чем другие языки.
                                                                                                                                                      +6
                                                                                                                                                      Мне вот интересно насчёт этого аргумента про "как захочу я, а не компилятор". Сколько у вас реально было кода, в котором нужно было буквально перебирать байты вручную? Действительно ли настолько много, что защита помешала бы буквально во всей программе? Мне например такая "свобода всегда и везде" неудобна. Мне гораздо удобней иметь возможность снять такую защиту ровно там где нужно. И в будущем знать, что если я накосячил, то в первую очередь надо смотреть unsafe блоки. Знать, что эти блоки надёжно изолированы, а не просачиваются в виде указателей повсюду.
                                                                                                                                                      Аналогия из реальной жизни. Почему эти нехорошие электрики закрывают щитки крышкой, а иногда и на замок? Для чего прячут кабели? А для того, чтобы жильцам было удобно ходить, а не приходилось перепрыгивать через оголённые кабели. Прыжок не туда == шашлык.
                                                                                                                                                      Хитрого системного кода мало. Просто системного и прикладного — много. И вот его хотелось бы писать удобно, а не прыгать через раскиданные на полу высоковольтные кабели.
                                                                                                                                                        +1
                                                                                                                                                        Сколько у вас реально было кода, в котором нужно было буквально перебирать байты вручную?

                                                                                                                                                        Очень много, мне повезло, я просто работаю в RnD отделе связанной с графикой и рендерами.
                                                                                                                                                        –1
                                                                                                                                                        Завернул в unsafe, и лепи что хочешь )
                                                                                                                                                      +5
                                                                                                                                                      "получили null — зачем проверять? Все равно при первом же доступе к любому члену или методу выкинется эксепшн".

                                                                                                                                                      В managed языках. А в C++ под linux обычно будет SIGSEGV и хватит. А если в kernelspace, то там свой хендлер для обработки NULL dereference, обычно будет паника.
                                                                                                                                                      Но первичный результат "хоть как-то работает" будет на плюсах почти сразу, а на расте будет "всё или ничего".

                                                                                                                                                      Если не хочется обрабатывать ошибки, то можно спокойно использовать unwrap/expect и при ошибке будет паника, что не сильно отличается от segfault'а.
                                                                                                                                                        +4
                                                                                                                                                        Небольшая поправочка :) unwrap/expect программу уронят гарантированно. А вот если переменную под указатель забыли занулить… А С++ переменные по умолчанию не зануляет.
                                                                                                                                                          0
                                                                                                                                                          А С++ переменные по умолчанию не зануляет.

                                                                                                                                                          Смотря где, конечно. В секции bss зануляет.
                                                                                                                                                            0
                                                                                                                                                            Зануление статиков прописано ЕМНИП в стандарте, тут вы совершенно правы. Я про обычные такие себе стековые переменные.
                                                                                                                                                0
                                                                                                                                                Синтаксис Rust в достаточной степени C-подобен. Просто исправили очевидные просчеты, на счет необязательных фигурных и лишних круглых скобок во вложенных операторах. А с какой стороны тип от имени переменной писать — большая ли разница?
                                                                                                                                              +1
                                                                                                                                              Мне кажется, что наоборот стоит развивать. Чтобы избавиться от этих унаследованных проблем им бы надо поменьше думать об обратной совместимости, безжалостно выкидывая старый некрасивый код из стандартной библиотеки. Да, возникнут проблемы со старым кодом, но так язык начнет развиваться в более лучшую, очищаться от мусора.
                                                                                                                                                +1
                                                                                                                                                а, возникнут проблемы со старым кодом, но так язык начнет развиваться в более лучшую, очищаться от мусора.

                                                                                                                                                и новыми компиляторами никто не будет пользоваться, и т.о. вы только закопаете язык в ещё более глубокую яму: целая гора хорошего, полезного, библиотечного кода написана именно на C++/C, и остаётся актуальным годами, даже если он заброшен авторами. Обратная совместимость компиляторов — это хорошо, особенно для нативного кода. Очень плохо, когда текущий компилятор замусоривается просто потому, что из года в год его стараются сделать как можно более избыточным.
                                                                                                                                                  0
                                                                                                                                                  Убедительно.
                                                                                                                                                    –2
                                                                                                                                                    Я буду пользоваться.
                                                                                                                                                    Ну потрачу пару дней на то, чтобы привести все старые проекты в соответствие с новыми правилами, это не такая уж и большая цена))
                                                                                                                                                    Библиотечный код перепишут создатели библиотек, это тоже не так уж и сложно. Что заброшено авторами — то давно пора на помоечку, все равно там баги никто не исправляет.
                                                                                                                                                      +2
                                                                                                                                                      А у вас останется время на разработку своего продукта, если вы будете постоянно переписывать чужие проекты просто для того, чтобы они скомпилировались?
                                                                                                                                                      А если пулл?
                                                                                                                                                      Библиотечный код перепишут создатели библиотек,

                                                                                                                                                      Спасибо, порадовали. Авторам библиотек порой лень принять пулл-реквест, а вы мне тут заливаете о том, что авторы будут моментально подстраиваться под новый стандарт.
                                                                                                                                                      А вообще, это отличный способ изолировать opensource от всех остальных.
                                                                                                                                                        –3
                                                                                                                                                        opensource на то и opensource, что можно форкнуть.
                                                                                                                                                        к тому же пулреквест — это автору надо думать над задачей, которая лично ему скорее всего и не нужна;
                                                                                                                                                        а приведение библиотеки в соответствие с новым стандартом — это тупая работа: перекомпиляция и исправление ошибок, которые заботливо покажет компилятор; думать не надо, так как вся логика уже известна и продумана, нужно просто поправить синтаксис.
                                                                                                                                                                    –4
                                                                                                                                                                    Другое расширение файла (например "cpp2")
                                                                                                                                                                    А на будущее — #pragma version в начале каждого файла (это кстати полезно для всех разработчиков новых языков)
                                                                                                                                                                    Внести в стандарт требование поддержки всех версий и правила взаимодействия кода между версиями
                                                                                                                                                                    Определить конкретные сроки, в течении которых будут поддерживаться те или иные версии (например 5 лет на одновременное существование двух версий — вполне достаточно)
                                                                                                                                                                    Начиная с какой-то версии языка, некоторая старая версия объявляется неподдерживаемой и новые компиляторы отказываются компилировать старый код.
                                                                                                                                                                    Отвечая на ваш странный вопрос — что делать с Бустом если уберут шаблоны: очевидно переписывать Буст на новые средства без шаблонов (например на синтаксические макросы, если таковые появятся). Поддерживать две версии Буста в течение срока поддержки.
                                                                                                                                                            +2
                                                                                                                                                            Ок. Новый стандарт убирает темплейты. Вопрос: как вы будете теперь будете пользоваться бустом на новом компиляторе?
                                                                                                                                                            Или вы заботливо перепишете весь буст?
                                                                                                                                                                –2
                                                                                                                                                                Зачем убирать темплейты? Убирать нужно инклуды и лексический препроцессор. Вместо этого вводить полноценные модули (без компромиссов со старой системой инклудов), синтаксические макросы (и здесь же синтаксический препроцессор).
                                                                                                                                                                  0
                                                                                                                                                                  Вы не ответили на поставленный вопрос: что вы будете делать, если решат убрать темплейты?
                                                                                                                                                                  p.s. а если уберут инклуды — то что вы будете делать с тем-же бустом или GLFW?
                                                                                                                                                                    0
                                                                                                                                                                    А если уберут операторы if и else?
                                                                                                                                                                    Вопрос бессмысленный. Убирать надо не все подряд, а то что надо — в частности, инклуды и препроцессор.
                                                                                                                                                                    Что делать с бустом? Переделывать на модули, очевидно. Поддерживать две версии какое-то время. В старой — на инклудах — просто фиксить баги, развивать только новую — с использованием новых возможностей. Это нормально, например тот же буст вы сейчас компилятором msvc 6 (98 года) не соберете.
                                                                                                                                                                      +2
                                                                                                                                                                      Вопрос не бессмысленный: я предоставил тот самый случай несовместимости компиляторов разных версий, за которую вы так агитируете. Отвечайте на первый вопрос: что вы будете делать с бустом, если уберут шаблоны? Отмазки "это ведь полезная фича" не рассматриваются: ведь не вы решаете, что войдёт в очередной стандарт.
                                                                                                                                                                0
                                                                                                                                                                Отказ от пулл-реквестов: и какой тут тогда опенсорс, если никто не будет принимать изменения от сообщества? Вы агитируете к стагнации.
                                                                                                                                                        0
                                                                                                                                                        Включающих все лучшее языков и так достаточно. Тот же C# например, в свете последних новостей — думаю, будет развиваться в сторону кроссплатформенности. Это единственное, чего ему не хватало.
                                                                                                                                                          +2
                                                                                                                                                          По сравнению с Scala и F#, он все-таки смотрится слабовато.
                                                                                                                                                            0
                                                                                                                                                            Ну как бы у F# вообще другая парадигма. Зато по сравнению с другими ЯП, C# выглядит современно.
                                                                                                                                                        +11
                                                                                                                                                        Полностью согласен. Я слабо представляю как все это С++ легси поддерживать. Каждая новая версия стандарта добавляет сотню страниц к спецификации языка. Уже сейчас стандарт С++ это кажется что-то около 1500 страниц. Я сомневаюсь что их кто-то осиливает и применяет правильно. Скорее всего большая часть программистов на С++ эту спецификацию даже не читали и пишут как умеют. В итоге код работает не благодаря, а вопреки. А поддержка превращается в ужас.
                                                                                                                                                          +3
                                                                                                                                                          пишут на C with classes, который чудом компилится. Иногда шаблонизируют. Иногда с лямбдами.
                                                                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                              +4
                                                                                                                                                              Спека к языку настолько большая, что рассчитывать на полное знание языка довольно опрометчиво. Достаточно знать не меньше, чем средний интервьювер.

                                                                                                                                                                0
                                                                                                                                                                Очень высокомерно. Таких разрабов большинство, потому что свыше 99% написанного и работающего кода именно так написано и именно так работает. ИМХО, писать прикладной код в строгом соответствии со стандартом — это итальянская забастовка.
                                                                                                                                                                  +1
                                                                                                                                                                  > писать прикладной код в строгом соответствии со стандартом — это итальянская забастовка.

                                                                                                                                                                  Простите, а как вы пишете код, если не в соответствии со стандартом?
                                                                                                                                                                    +1
                                                                                                                                                                    А как вы пишете по-русски, не сверяясь с учебниками? Если момент скользкий — тогда заглядываю в стандарт.