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

@ct0r · Регистрация: 19.08.2012

Студворк — интернет-сервис помощи студентам

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

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

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

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

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

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

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

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

@ct0r · 11.03.2016, 16:06 **[ТС]**

Сообщение от NotNot

и отличается оно от плясок с enable_if, собственно, отсутсвием enable_if

О том и речь. Для падавана выглядит просто как изменение синтаксиса.

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
template <typename ResourceType>
concept bool NotClonable() {
  return !requires (ResourceType resource) {
    { resource.clone() } -> void;
  };
}
 
struct Helper { void clone() { std::cout << "Helper.clone\n"; } };
struct ResourceC { void clone() { std::cout << "ResourceC.clone\n"; } };
struct Resource {};
 
template<typename T>
struct Base {};
 
template<typename T> requires NotClonable<T>()
struct Base<T> {
    Helper helper;
};
 
template<typename T>
struct Foo: Base<T> {
    void clone() {
        constexpr if (NotClonable<T>()) {
            this->helper.clone();
        } else {
            res.clone();
        }
    }
    T res;
};
 
int main() {
    Foo<ResourceC> f1;
    Foo<Resource> f2;
    f1.clone();
    f2.clone();
}

@Fulcrum_013 · 11.03.2016, 21:25

Сообщение от hoggy

"улучшенного с++"

Лучшее враг хорошего.
Вобщем мораль сей басни - когда то давно Вирт назвал С макроассемблером а не языком высокого уровня. Керниган и Ритчи по этому поводу просто покрутили пальцем у виска. А молодой Страуструп когда узнал о таком высказывании воспринял это как обиду. И понеслась шаблономазня с целью сделать типа безопасность как в паскале. При этом смотря его выступления видно что он напрочь забыл кое какие элементарные вещи. К примеру такие что Move simantic и т.п. неприменимы если адреса получателя фиксирован (сплошь и рядом если получателем выступает мапировная в ОЗУ память девайса),причем архитектуру получателя в таком случае переделать нельзя. что итерация вектора через итераторы внешним сравнивателем-переборщиком с передачей в него лямбды которая сравнивает значения в разы тормознее простого фора за счет кучи Indirect Call на каждой итерации, и т.д. и т.п. Что шаблонмазня не по месту только снижает читабельность, при этом куча дел которые эти шаблоны почти делают решается простыми расширениями синтаксиса.
Ну и как бы похоже было напрочь забыто то, что для того чтобы указатели были безопасными умными должны быть объекты которые их используют а не сами указатели. В силу принципа суперпозиции (комбинация оптимальных элементов не гарантирует оптимальность комбинации)

@Nick Alte · 11.03.2016, 22:42

Сообщение от hoggy

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

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

@hoggy · 11.03.2016, 23:19

Сообщение от ct0r

можно как-то так написать

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
template<typename T> requires NotClonable<T>()
struct Base<T> {
    Helper helper;
};
template<typename T>
struct Foo: Base<T> {
    void clone() {
        constexpr if (NotClonable<T>()) {
            this->helper.clone();
        } else {
            res.clone();
        }
    }
    T res;
};

от чего будет наследование, если концепт зафейлится?

@ct0r · 12.03.2016, 16:32 **[ТС]**

Сообщение от hoggy

от чего будет наследование, если концепт зафейлится?

Всегда выбирается самая ограниченная специализация. То есть вначале идет попытка отнаследовать от класса, удовлетворяющего NotClonable. Допустим, она фэйлится. Следующая попытка - от неограниченного пустого класса (который ты почему-то не указал в коде, хотя у меня он был):

C++
1
2
template<typename T>
struct Base {};

И теперь все окей.

Или в чем был вопрос?

Добавлено через 16 часов 20 минут
У Саттера в блоге появился новый пост.
Если хотите проникнуться мыслью, что не все так уж плохо, то читать

http://herbsutter.com/2016/03/... s-meeting/

@NotNot · 12.03.2016, 17:24

Сообщение от ct0r

http://herbsutter.com/2016/03/... s-meeting/

in the paper that proposed constexpr_if the committee changed the syntax to if constexpr at the meeting

C++
1
if constexpr (condition) ...

Таак, если condition константное выражение тогда.., а не, design by committee же, если condition истина тогда.. и т.д.

Что за фигня вообще?

@ct0r · 12.03.2016, 17:52 **[ТС]**

Сообщение от NotNot

Что за фигня вообще?

Да нормально. Я думаю, что if constexpr предпочтительнее constexpr if, потому что:
1) if - по сути обычный if, зачем ему прилагательное constexpr? Что такое constexpr'ный if? Это у которого условие constexpr, или который вообще может вернуть constexpr значение?
2) делается акцент на том, что именно условие должно быть constexpr
3) когда мы просто просматриваем код, мы ищем управляющие конструкции в начале строки. За if constexpr глаз цепляется лучше. if - главная информация, constexpr - второстепенная
4) когда мы глазами идем в коде от } или else, мы ищем на том же отступе if, а не constexpr

@hoggy · 12.03.2016, 17:59

Сообщение от ct0r

Я думаю, что if constexpr предпочтительнее constexpr if, потому что:

очевидно жеж, constexpr можно ставить и справа, и слева.
двойной профит: пиши, как удобно,
и есть повод, что б похоливарить.

@NotNot · 12.03.2016, 21:43

Сообщение от ct0r

Да нормально

Сообщение от ct0r

4) когда мы глазами идем в коде от } или else, мы ищем на том же отступе if, а не constexpr

Ну как нормально, непонятно ещё что они с constexpr_else в итоге сделали. Как бы такого не получилось

C++
1
2
3
4
5
6
7
if constexpr (A) {
  ...
} constexpr_else if constexpr (B) {
  ...
} constexpr_else {
  ...
}

Или такого

C++
1
2
3
4
5
6
7
if constexpr (A) {
  ...
} else constexpr if constexpr (B) {
  ...
} else constexpr {
  ...
}

Сообщение от ct0r

1) if - по сути обычный if, зачем ему прилагательное constexpr? Что такое constexpr'ный if? Это у которого условие constexpr, или который вообще может вернуть constexpr значение?

Ну, я на `constexpr if ...` смотрю/смотрел как на constexpr if-statement, т.е if-statement который чекается во время компиляции.

Сообщение от ct0r

4) когда мы глазами идем в коде от } или else, мы ищем на том же отступе if, а не constexpr

Но в то же время после if мы ожидаем (условие), а не constexpr. А после else можно и while и for и switch написать, и будет оно вполне к месту.

Сообщение от ct0r

2) делается акцент на том, что именно условие должно быть constexpr

Но constexpr то не условие, а сам if. То что условие constexpr должно быть это уже следствие.

Сообщение от ct0r

3) когда мы просто просматриваем код, мы ищем управляющие конструкции в начале строки. За if constexpr глаз цепляется лучше. if - главная информация, constexpr - второстепенная

У меня как-то глаз за constexpr цепляется, а if пытается не заметить. Но вообще, чуть подумав, согласен: "Да нормально".

@ct0r · 23.03.2016, 21:52 **[ТС]**

NotNot, уточнение. Было так:

C++
1
2
3
4
5
6
7
constexpr if (...) {
...
} constexpr else constexpr if (...) {
...
} constexpr else {
...
}

Стало так:

C++
1
2
3
4
5
6
7
if constexpr (...) {
...
} else if constexpr (...) {
...
} else {
...
}

И вот еще:

The proposal was also modified to allow the construct outside of templates; the semantics for such uses is that the branch not taken is fully type-checked, but entities referenced in it are not odr-used, and return statements contained in it do not contribute to return type deduction.

@NotNot · 23.03.2016, 22:08

ct0r, да, я это тоже видел.

The proposal was also modified to allow the construct outside of templates

Было бы довольно странно, если б это было запрещено.

@tapochka · 24.03.2016, 03:39

одного вот только не могу понять: что все так на sfinae с enable_if то взъелись?)

@Kastaneda · 24.03.2016, 09:57

Не по теме:

Сегодня на хабре статья промелькнула на эту же тему, картинка понравилась :)

@Nick Alte · 27.03.2016, 13:05

Сообщение от tapochka

одного вот только не могу понять: что все так на sfinae с enable_if то взъелись?

Я взъелся после того, как мне пришлось активно им попользоваться в одном своём проекте. Неудобно. Плюс сравнение с тем, как это делается в D, добавило контраста.

@tapochka · 28.03.2016, 21:55

Сообщение от Nick Alte

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

хм, значит в том числе с помощью вашей статьи я со сфинае разбирался)

@jdzvk · 29.03.2016, 12:58

Не по теме:

если концепт зафейлится

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

Но это скорее к коду операционки каким то боком еще может касаться,
а вот кода непосредственно прикладного софта абсолютно нет

да-да. именно 'абсолютно'. это своего рода шафл(shuffle). не в смысле шок(shuck), а в смысле "попытка раздавать, не имея карт")
*con text by prof. v.k.muller, 1960, seventhns edition.*enlarged

Новые блоги и статьи Все статьи Все блоги /
Алиса нашла кучу ошибок компиляции и запуска в проекте, который без проблем компилировался и запускался))) anaschu 30.06.2026 Я пока посмеюся, но завтра проверю. А вообще интерсно. Дал алисе файл, в котором точно нет ошибок компиляции и запуска, и попросил их найти. Нашла кучу))) Критические ошибки, мешающие компиляции и. . .	сукцессия 16. Общий обзор, в основном что бы другие ии поняли anaschu 29.06.2026 # Передаточный документ: модель микоризной сукцессии (для нового чата) Этот документ предназначен для того, чтобы новый чат Claude мог продолжить работу без необходимости заново разбираться в. . .	сукцессия 15 неявная схема anaschu 29.06.2026 Алиса Калибровка параметров симбиотической модели: технический обзор Содержание: Введение Постановка проблемы Технические аспекты реализации Процесс внедрения изменений	сукцессия 14. Обновленная схема модели anaschu 28.06.2026 ГЛОБАЛЬНАЯ ОПИСАТЕЛЬНАЯ СПЕЦИФИКАЦИЯ ЭКОСИСТЕМНОЙ МОДЕЛИ «SOIL CHEMISTRY & MYCORRHIZA 2. 0» https:/ / ibb. co/ NnkGpfMd Представленная интегрированная схема описывает непрерывную нелинейную. . .
сукцессия 13. Питон модель трехзонного мицелия, пока что в основном арбускулярного anaschu 28.06.2026 ## Разработка агентной модели микоризной сукцессии: от выявления артефактов к созданию комплексной системы ### Аннотация Представлено исследование по разработке агентной модели микоризной. . .	сукцессия 12. краткий список проверок модели перед запуском. anaschu 27.06.2026 Скрытые отказы в моделях систем динамики (SD-models) экологических систем: два случая из практики Контекст Разбирался прототип модели систем динамики (SD-модели) микоризной сукцессии: пять. . .	Сукцессия 11. Проверка орудий перед войной: разработка через тестирование anaschu 27.06.2026 Как не дать модели соврать самой себе: проверки для симуляции микоризной сукцессии Введение Когда вы строите математическую модель живой системы — грибов, растений, почвы — главная опасность. . .	10 сукцессия. Питон код войны грибов и растений anaschu 27.06.2026 import numpy as np class PlantAgent: def __init__(self, name, strategy, initial_biomass): self. name = name self. strategy = strategy # "greedy" (широколиственные) или. . .

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367

	Почему С++ отстой до 2020 года 07.03.2016, 11:58. Показов 9765. Ответов 55 Метки нет (Все метки) Это не холиварная тема, здесь мы не спорим, какой язык лучше! Ну что, недавно собирался комитет стандартизации, который обсуждал будущее - С++17. И в итоге? Что же будет добавлено в столь долгожданный стандарт после релиза С++14, который был минорым и лишь доводил до ума фичи С++11? 1) Параллелизм (STL) 2) Файловая система 3) ... Вы думали, что будет еще что-то? Да нет, из фич, которые как-то заметно влияют на разработку, это все. Это все, Карл! Концепты - пфф, нам и так хорошо - родные и уродливые длинные сообщения об ошибках в шаблонах, а также безобразная магия enable_if в SFINAE, - чего еще желать? Диапазоны? Можно расслабиться, они без концептов не работают. И Слава Богу, а то пришлось бы осиливать столь сложную вещь! Модули? Ну ребят, у нас и так все быстро компилируется, особенно если буст подключить. Не зажируем ли? И да, cmake куда лучше пакетного менеджера! Конкурентность? Дык кто не пишет на низкоуровневых примитивах, тот неосилятор! Сети, корутины? Кого волнует, идите-ка вы на ...буст. Рефлексия, контракты? Да зачем? Без них куда проще жить, юзать нечитабельные либы и писать велосипеды! В общем, С++17 я бы точно не назвал мажорной версией стандарта, поскольку НЕ ВИЖУ, КАКИЕ РЕАЛЬНО НАСУЩНЫЕ ПРОБЛЕМЫ ОН РЕШАЕТ. А сколько шуму-то было после С++11/14! И это печально, потому что следующего шага после С++11 приходится ждать 10 лет, а конкуренты не дремлют. Почему так получилось? Ну потому что С++ слишком сложен, а поэтому добавление или исправление вещей, которые реально нужны и важны занимают слишком много времени и усилий. На рынке С++ по-прежнему будет скатываться в свои ниши - в ниши, где производительность критична. А С++ разработчики по-прежнему будут жить с С++ без удовольствия, частенько похаживая на сторону к другим языкам. У меня все. Если кто-то хочет меня дополнить, исправить, или просто выразить свое мнение и послать в дальние места - велкам! 1

@tapochka 42 / 42 / 17 Регистрация: 25.04.2014 Сообщений: 499
	24.03.2016, 03:39
	одного вот только не могу понять: что все так на sfinae с enable_if то взъелись?) 0

@Kastaneda
	24.03.2016, 09:57
	Не по теме: Сегодня на хабре статья промелькнула на эту же тему, картинка понравилась :) 0