Почему С++ отстой до 2020 года

Это не холиварная тема, здесь мы не спорим, какой язык лучше!

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

1) Параллелизм (STL)
2) Файловая система
3) ... Вы думали, что будет еще что-то? Да нет, из фич, которые как-то заметно влияют на разработку, это все. Это все, Карл!

Концепты - пфф, нам и так хорошо - родные и уродливые длинные сообщения об ошибках в шаблонах, а также безобразная магия enable_if в SFINAE, - чего еще желать?
Диапазоны? Можно расслабиться, они без концептов не работают. И Слава Богу, а то пришлось бы осиливать столь сложную вещь!
Модули? Ну ребят, у нас и так все быстро компилируется, особенно если буст подключить. Не зажируем ли? И да, cmake куда лучше пакетного менеджера!
Конкурентность? Дык кто не пишет на низкоуровневых примитивах, тот неосилятор!
Сети, корутины? Кого волнует, идите-ка вы на ...буст.
Рефлексия, контракты? Да зачем? Без них куда проще жить, юзать нечитабельные либы и писать велосипеды!

В общем, С++17 я бы точно не назвал мажорной версией стандарта, поскольку НЕ ВИЖУ, КАКИЕ РЕАЛЬНО НАСУЩНЫЕ ПРОБЛЕМЫ ОН РЕШАЕТ. А сколько шуму-то было после С++11/14! И это печально, потому что следующего шага после С++11 приходится ждать 10 лет, а конкуренты не дремлют.

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

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

У меня все. Если кто-то хочет меня дополнить, исправить, или просто выразить свое мнение и послать в дальние места - велкам!

1

с чего вы взяли что вам что то должны?

0

Сообщение от MousePro с чего вы взяли что вам что то должны?

Тема не обо мне, а о развитии С++. Поэтому вопрос считаю неконструктивным и некорректным.

0

ct0r, Откуда информация, что конкретно точно войдет в С++17 и что не войдет?

0

ForEveR,
http://usingstdcpp.org/2016/03... ksonville/
https://www.reddit.com/r/cpp/c... ing_draft/

4

ct0r, тема слабости! Не сдавайтесь! Боритесь! Всегда были конкуренты - так почему не ушли к ним давно? А то, что вам что-то должны тоже согласен - нужно больше ссылок на реквесты, что вы писали для С++17 и которые не одобрили. Ах, да - вы ничего не писали, но хотите лучшего. Как-то так)

1

Да, ожидал от C++17 большего количества нововведений. А почему столько предложений решили отбросить или отложить не пишут?

1

Сообщение от rikimaru2013 Не сдавайтесь! Боритесь!

Кому не сдаваться? С чем бороться?

Сообщение от rikimaru2013 Всегда были конкуренты - так почему не ушли к ним давно?

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

Сообщение от rikimaru2013 А то, что вам что-то должны тоже согласен - нужно больше ссылок на реквесты, что вы писали для С++17 и которые не одобрили. Ах, да - вы ничего не писали, но хотите лучшего

Еще раз: какое отношение имеют мои личные достижения к объективному состоянию С++?

Сообщение от S_el А почему столько предложений решили отбросить или отложить не пишут?

Какую-то инфу можно нарыть по ссылкам, что я дал.
Еще по корутинам: http://www.open-std.org/jtc1/s... 158r0.html
По концептам: http://honermann.net/blog/?p=3
Ну и вот тут можно в целом ознакомиться с текущим состоянием:
http://meetingcpp.com/index.ph... r-c17.html
http://meetingcpp.com/index.ph... tions.html

3

ct0r, Что ж. Действительно печально. Будем ждать следующего за С++17 стандарта...

0

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

0

Обидно, особенно в свете статьи Страуструпа от апреля 2015, и на основе которой я в прошлом году и создал тему про С++17.
Тут сейчас чел прошелся по ней и все расписал, мне добавить нечего: https://www.reddit.com/r/cpp/c... ook_march/

У меня нет никаких претензий к людям, которые имплементят фичи - они молодцы! (многие это делают добровольно, бесплатно, в одиночку, в свободное время!!).
Но Intel, Google, Microsoft, etc - стыд и срам! Где помощь, где материальная поддержка??

0

ct0r, мне кажется, что с какого-то момента будут просто вынуждены кидать обратную совместимость с Си. Иначе всё очень сложно

0

Сообщение от ct0r Но Intel, Google, Microsoft, etc - стыд и срам! Где помощь, где материальная поддержка??

Так вроде никто из перечисленных ставку на плюсы не делает.
Дальше ИМХО, учитывая что за ситуацией последние года три я слабо слежу.
Компилятор и стандартную библиотеку пилят в основном команды из Силанг и гцц. А на стандарт больше всего влияют Страусята, у которых взгляд на развитие языка немного свой, но напористости не отнимать. Вот комитет и решил, что все хотелки Страусят реально делать будут, мягко говоря, без большого энтузиазма и очень долго.

1

Сообщение от ZaMaZaN4iK мне кажется, что с какого-то момента будут просто вынуждены кидать обратную совместимость с Си

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

0

Сообщение от Nick Alte Ради обратной совместимости уже нагорожено несколько слоёв костылей

приведите пример.

0

Сообщение от hoggy приведите пример.

Это пожалуйста:
- final и override - "идентификаторы со специальным значением", а не ключевые слова;
- в initializer_list допустимо размещать только значения одинаковых типов, и именно initializer_list порождается из независимых фигурных скобок (а по-хорошему, в язык надо было вводить tuple вместе с литералами на уровне core);
- ещё одна завязка языковой конструкции на библиотеку: range-based for зависит от std::begin() и std::end();
- заточенность STL на итераторы и индуцированное распространение этой концепции по проектам ещё долго не позволит полноценно перейти на диапазоны;
- откровенно корявая схема именования в стандартной библиотеке (сейчас уже не моден kernigan_and_ritchie_name_style, нынче народ всё больше в camelCase творит);
- ситуация с препроцессором: макросы, инклюды, вот эти все вне-языковые штуки так просто разгрести и перейти на модули не выйдет;
- наследие Си (сырые указатели, malloc/free, форматированный ввод-вывод с variadic-аргументами, C-style cast), которые ещё к тому же и записываются лаконичнее, да ещё и могут перехлёстываться с вещами из C++ - сколько новичков пыталось удалить выделенный через new указатель функцией free;
- метапрограммирование, осуществляемое через побочные эффекты, Карл! И SFINAE ещё весьма умеренный пример, наверняка кто-то из присутствующих тоже видел тот мозгоразрывающий хтонический ужас, который позволял благодаря перегрузкам хранить в compile-time состояние. А ведь поддержка того же SFINAE внедряется в стандартную библиотеку, пишутся всякие mpl... Структура-метафункция считается чем-то нормальным. Называйте меня капризным, но метапрограммирование должно быть явным и интенциональным. А если его не удаётся сделать таковым, то кого нам надо поблагодарить? Обратную совместимость.

3

Сообщение от Nick Alte final и override - "идентификаторы со специальным значением", а не ключевые слова;

1.
в чем "костыльность",
причем здесь "легаси",
и чем таким "идентификаторы со специальным значением" принципиально отличаются от "ключевых слов".
?

Сообщение от Nick Alte в initializer_list допустимо размещать только значения одинаковых типов

данный тип данных специально рассчитан на такое поведение.

в чем "костыльность",
причем здесь "легаси"
?

Сообщение от Nick Alte ещё одна завязка языковой конструкции на библиотеку: range-based for зависит от std::begin() и std::end();

ложь.

любой пользовательский тип, который определил функции-члены begin/end
может быть участником данной конструкции.

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

очевидно, что здесь нет места ни костылям,
ни тем более легаси.

Сообщение от Nick Alte - заточенность STL на итераторы и индуцированное распространение этой концепции по проектам ещё долго не позволит полноценно перейти на диапазоны;

к сожалению, я не знаю,
что означает символ "диапазоны" в данном контексте.

Сообщение от Nick Alte - откровенно корявая схема именования в стандартной библиотеке (сейчас уже не моден kernigan_and_ritchie_name_style, нынче народ всё больше в camelCase творит);

субъективная оценка.
очевидно, что субъективные оценки не имеет ни малейшего отношения ни к костылям,
ни к легаси.

Сообщение от Nick Alte - ситуация с препроцессором: макросы, инклюды, вот эти все вне-языковые штуки так просто разгрести и перейти на модули не выйдет;

если утрировать, то ожидаемые модули - суть узаконенная виндузятная #pragma comment( lib, "mylib" )
реализовать которую виндузятному компилятору не помешали ни инклюды, ни макросы.

следовательно ваш тезис ошибочный.

Сообщение от Nick Alte наследие Си (сырые указатели, malloc/free, форматированный ввод-вывод с variadic-аргументами, C-style cast), которые ещё к тому же и записываются лаконичнее, да ещё и могут перехлёстываться с вещами из C++ - сколько новичков пыталось удалить выделенный через new указатель функцией free;

то есть, вы полагаете костылями главные киллер-фичи языка,
который изначально проектировался с прицелом их поддерживать:
обратная совместимость с сишкой, и эффективность,
что означает сочетание экономичности и быстродействия?

видимо вы не отдаете отчета в том, какую глупость сморозили.
взгляните на язык "D": глупость в действии.

вопрос с легаси остается открытым:
приведите конкретный пример, который иллюстрирует,
как требование обратной совместимости с языком си
мешает дальнейшему развитию языка с++

Сообщение от Nick Alte - метапрограммирование, осуществляемое через побочные эффекты, Карл!

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

в настоящий момент метапрограмминг развивается,
как в рамках функциональной парадигмы
(std::enable_if, концепты с++17, и тп),
так и в рамках императивной парадигмы.
(constexpr)

1.
в чем "костыльность",
2.
причем здесь "легаси",

Сообщение от Nick Alte Называйте меня капризным

меня не интересуют ваши капризы.
меня интересуют объективные оценки и факты.

1

Сообщение от hoggy в чем "костыльность", причем здесь "легаси", и чем таким "идентификаторы со специальным значением" принципиально отличаются от "ключевых слов".

Нельзя завести переменную с именем for. Переменные override и final завести можно. Но если поставить эти слова в особенное место, они начинают иметь особое значение. Почему так было сделано именно для этих слов? Просто из каприза? Квота на ключевые слова закончилась?

Сообщение от hoggy данный тип данных специально рассчитан на такое поведение.

Данный тип - не просто тип, он специальный "волшебный тип", на который завязаны некоторые случаи brace initializers. У него есть специальный private-конструктор, предназначенный для вызова компилятором. В результате имеем ряд неудобств при использовании brace initializers. При чём тут "легаси", я пояснил: нормальное введение tuple в сам язык нарушило бы совместимость, пришлось обходиться вот таким вот компромиссом.

Сообщение от hoggy ложь. любой пользовательский тип, который определил функции-члены begin/end может быть участником данной конструкции.

А вот тут вы уже бросаетесь чересчур категоричными обвинениями, не разобравшись в вопросе. Функции-члены begin/end вызываются именно из глобальных функций std::begin, std::end, на которые завязана эта форма for. У массива этих функций вообще нет, а range-based for с массивами работает. И будет работать с другими типами, для которых специализируют std::begin и std::end. Конструкция языка привязана к библиотечным функциям. Так же, как в случае brace initializers конструкция языка привязана к библиотечному типу.
Готов принять ваши извинения за несправедливое обвинение во лжи.

Сообщение от hoggy к сожалению, я не знаю, что означает символ "диапазоны" в данном контексте

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

Сообщение от hoggy если утрировать, то ожидаемые модули - суть узаконенная виндузятная #pragma comment( lib, "mylib" )

А если оглянуться не на "ожидаемые в C++ модули", а на модули в других языках, которые вообще прекрасно обходятся без вне-языковых конструкций? Легаси в виде препроцессора (и использующих его библиотек) порождает массу проблем, о которых уже говорено-переговорено, и прагмами эти проблемы не решить. Так что вывод про "ошибочность" моего тезиса, выдвинутый на основании "а нам ничего такого хорошего не обещали", довольно нелогичен.

Сообщение от hoggy возникло, в результате побочных эффектов при обобщенном программировании. перспективы были оценены и узаконены.

Сообщение от hoggy о есть, вы полагаете костылями главные киллер-фичи языка, который изначально проектировался с прицелом их поддерживать: обратная совместимость с сишкой, и эффективность, что означает сочетание экономичности и быстродействия?

Киллер-фичами они были тогда, когда C++ отвоёвывал место в мире, перетягивая народ из Си. Эти времена давно прошли, и теперь эти фичи киллерят безопасность и надёжность. В C++ очень многие из этих фич попросту рекомендуют не использовать, предлагая взамен более безопасные и не менее эффективные: ссылки, smart-указатели, контейнеры, C++ style cast и прочая, и прочая.

Сообщение от hoggy видимо вы не отдаете отчета в том, какую глупость сморозили. взгляните на язык "D": глупость в действии.

Ну раз вас не интересуют мои капризы, будьте так добры, избавьте и нас от своих в высшей степени субъективных оценок по поводу "глупости" как моей, так и Брайта с Александреску. Хотя у D есть немало своих крайне существенных недостатков (и, кстати, некоторые из них вытекают из совместимости с C/C++), многое там сделано куда правильнее и лучше, чем в C++.

По поводу метапрограммирования через побочные эффекты:

Сообщение от hoggy возникло, в результате побочных эффектов при обобщенном программировании. перспективы были оценены и узаконены.

В том-то и беда, что эти "хитрые загогулины" были приняты как есть вместо того, чтобы узаконить явное описание того, что достигается при их помощи. В результате написание, а тем более расшифровка более-менее нетривиальных вещей превращается в мозгоразрывающее упражнение. Кому мы скажем за это спасибо? Совместимости с кодовой базой.
Да, метапрограммирование развивается, но "загогулины"-то до сих пор остались, и когда их переведут в явное описание и переведут ли вообще... Тот самый enable_if, который попросту обёртка над уродливой SFINAE, эту уродливость прячет лишь отчасти.

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

Чтобы у читающих эти слова не возникло недопонимания, хочу подчеркнуть, что это не ворчание-бурчание впустую, и даже не критика C++. Я не утверждаю, что описанные моменты были ошибочными решениями. Это просто перечисление объективно возникших особенностей, продиктованных сложившейся ситуацией - необходимостью сохранять совместимость, огромную важность которой отрицать нельзя. Но нельзя и закрывать глаза на существующие трудности и уверять себя, что их попросту не существует. Так что не надо по прочтении этого текста набрасываться на меня как на врага, C++ не нуждается в том, чтобы его от меня защищали.

3

Сообщение от Nick Alte Нельзя завести переменную с именем for. Переменные override и final завести можно.

ну и что? какое это имеет значение на практике?

вы считаете, что for костыльный,
потому что нельзя создавать переменный с такими именами?
или что override костыль, потому что можно?

Сообщение от Nick Alte Данный тип - не просто тип, он специальный "волшебный тип"

какое это имеет значение на практике?

Сообщение от Nick Alte В результате имеем ряд неудобств при использовании brace initializers.

о каких таких неудобствах идет речь?

http://rextester.com/NMTF25067

Сообщение от Nick Alte А вот тут вы уже бросаетесь чересчур категоричными обвинениями, не разобравшись в вопросе. Функции-члены begin/end вызываются именно из глобальных функций std::begin, std::end, на которые завязана эта форма for. У массива этих функций вообще нет, а range-based for с массивами работает. И будет работать с другими типами, для которых специализируют std::begin и std::end.

ок. пусть так.

при чем здесь легаси?
в чем костыльность?

Сообщение от Nick Alte Конструкция языка привязана к библиотечным функциям.

не привязана.

http://rextester.com/QCJ68826

как видите, для работы цикла никакие
библиотечные функции не нужны.

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

Сообщение от Nick Alte Да range же, то, над чем так упорно вкалывает Эрик Ниблер

я не знаю никаких ни "range же", ни Эриков Нилберов.

Сообщение от Nick Alte А если оглянуться не на "ожидаемые в C++ модули", а на модули в других языках, которые вообще прекрасно обходятся без вне-языковых конструкций?

1.
мне не понятно, что такое "вне-языковые конструкции".
это какой то бред.
любая валидная с точки зрения языка конструкция является "языковой"
по отношению к нему.

2.
утрируя про виндузятную прагму я акцентрировал ваше внимание
на принципе их реализации, а не на дизайне.

дизайн там будет вполне себе типичный для модулей:
#import bla bla bla

Сообщение от Nick Alte Легаси в виде препроцессора (и использующих его библиотек) порождает массу проблем

он не добавляет никаких новых проблем.
мы прекрасно живем с препроцессором сегодня.

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

Сообщение от Nick Alte Так что вывод про "ошибочность" моего тезиса, выдвинутый на основании "а нам ничего такого хорошего не обещали", довольно нелогичен.

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

позвольте я объясню вам весь "ужас" препроцессорного легаси:

среди настоящих ценителей искусства
данный ужасс имеет название "не шаблонный шаблон"
а по научному "нарушение ODR"

для иллюстрации достаточно иметь проект из 3х файлов:



такую ситуацию стандарт трактует как UB

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

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

вот точно так же они забьют болт и случае с модулями.
упоролся на макросах? ну сам себе злобный буратино.

препроцессор - не помеха модулям.

Сообщение от Nick Alte Киллер-фичами они были тогда, когда C++ отвоёвывал место в мире, перетягивая народ из Си.

вы очень ошибаетесь.

я даже не знаю, как можно объяснять такие очевидные вещи.
гляньте область применения плюсов сегодня.
ему всякие там шарпики/жавы в спину дышат.
и почему это все таки выбирают плюсы?

Сообщение от Nick Alte В C++ очень многие из этих фич попросту рекомендуют не использовать, предлагая взамен более безопасные и не менее эффективные

верно.
ключевой момент "не менее эффективные".

с++ развивается, и предлагает не менее эффективные,
но более развитые решения.

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

Сообщение от Nick Alte избавьте и нас от своих в высшей степени субъективных оценок по поводу "глупости" как моей, так и Брайта с Александреску.

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

я понятия не имею кто такой Брайт.
и понятия не имею, на кой черт вы сюда сейчас Александресску припахали.

Сообщение от Nick Alte В том-то и беда, что эти "хитрые загогулины" были приняты как есть вместо того, чтобы узаконить явное описание того, что достигается при их помощи. В результате написание, а тем более расшифровка более-менее нетривиальных вещей превращается в мозгоразрывающее упражнение. Кому мы скажем за это спасибо? Совместимости с кодовой базой.

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

исключительно у ребят,
которые не осилили функциональную парадигму.

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

(все фантазии на эту тему в итоге приводили
к пресловутой функциональщине, и громоздкости)

однако не существует технических препятствий для внедрения
каких то альтернативных технологий.

например декларативный стиль:
https://msdn.microsoft.com/ru-... y9xh3.aspx

либо императивный:
см. развитие технологии constexpr,
и вывода типов:
auto foo(auto)

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

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

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

фразы вида:

Сообщение от Nick Alte а сюда входит совместимость не только с Си, но и с кодовой базой разной степени устарелости, которая по-прежнему должна компилироваться, и совместимость с уже принятыми ранее решениями, на которых уже кодовая база наработана и которые нельзя так просто взять и отменить

больше смахивают на бла бла бла, но примерами не являются точно.
-------------------------------------------------------------------------------------------

вот таким мог бы быть грамотный пример костыльного-легаси:

локали/фасетки стандартной библиотеки .

костыль: потому что из-за ограничений в архитектуре
не способны обеспечить полноценную работу
с текстом на разных языках

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

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

правильно было бы оперировать понятием "строка" (нормализованная/ненормализованная),
а не "символ".

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

вот и приходится пользоваться сторонними инструментами.

2

Сообщение от Nick Alte Конструкция языка привязана к библиотечным функциям.

Это, на само деле, началось уже давно. Например, поведение "замещаемых" библиотечных 'operator new' всегда было особым, ибо никакого механизма "замещения" функций в ядре языка нет.

Но сейчас это явление достигло такого гигантского размаха, что все уже понятно: язык С++ осознанно и целенаправленно стирает границу между свойствами ядра языка (core language) и свойствами стандартной библиотеки. Я не буду говорить, что это плохо. Просто язык становится все менее и менее "честным", т.е. он приобретает большое количество интегрированного библиотечного поведения, навязанного свыше, а не создаваемого пользователем.

Эта деталь - фундаментальное расхождение в дизайне языков С и С++.

1