Чего не хватает в С++

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

Объекты-значения

Большинству объектов не нужен скурпулёзный учёт вызванных конструкторов, потому что обычно объекты нужны, чтобы хранить значения, а не выполнять код конструкторов. Например:

auto a = b + c;f(a);

Здесь незачем требовать от объекта вызов конструктора перемещения, потому что и так понятно, что этот объект больше нигде не нужен. Всякие RVO и NRVO надо оставить для классов, отмеченных специальным тегом, raii или типа того, а от всех остальных перестать требовать, чтобы они уговаривали компилятор не копировать лишний раз. Не так просто с ходу придумать пример, где бы эти лишние вызовы конструкторов были бы нужны. Может даже концепцию “значения” стоит распространить на вычисление выражений, string("asd") + string("fgh") — здесь ни к чему дёргать конструкторы с деструкторами. А ещё, возможно, так constexpr сможет получаться автоматически.

Очистка стека

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

void f(){...long_name(long_expression);...}

получается такой код:

void f(){...{auto a = long_expression;long_name(a);}...}

В 4 раза больше строк, а хотелось бы только в 2. Опять таки, на объекты с тегом raii это не должно распространяться. Хотя тут ещё надо прикинуть, не приведёт ли это к путанице, а ещё есть опасность, что функция сохранит ссылку на объект и следующая функция этой ссылкой воспользуется.

Деманглинг имён

Сколько можно собирать Qt? Как меняется версия компилятора, так и собирай по новой, и у разных компиляторов разные dll, поэтому их нельзя установить в систему, каждой программе приходится таскать с собой. Но это тоже не простое изменение, у разных компиляторов разные стандартные библиотеки с разными структурами данных, для начала надо их унифицировать.

Библиотека компонентов

Это чуть ли не самое очевидное изменение. Почему у питона есть стандартные прикладные библиотеки типа json, xml и т.д., а когда хочешь прочитать json на C++, надо бегать искать нормальную библиотеку и пытаться подключить. Уже бы сделали standard application library или типа того, чтобы в винду потом складывать sal_crt.dll, sal_xml.dll, sal_json.dll и т.д. В sal_crt проксировать вызовы msvcrt, и тогда не надо будет напрягаться с поддержкой на разных версиях винды. За одно сдуются размеры бинарников, если все будут использовать одни и те же библиотеки. И здесь незачем гнаться за мегаскоростью и т.п., надо сделать стандартный интерфейс с модульной нарезкой, а если кому нужна хитрая мегабыстрая обработка с вызовом мегакривых функций, тогда пусть подключает сторонние библиотеки. Ну и конечно, сами библиотеки должны быть сишными (с нормальными именами функций то есть), глядишь, и другие языки на них пересядут. Пишешь pic install requests и получаешь библиотеку requests с помощью Pack Installer C — удобно же?

Код, запускаемый на этапе компиляции

Рефлексию пытаются добавить костыльными способами, вместо того чтобы прямо сказать, чего хотел автор. Как это могло бы выглядеть:

Заполнение на этапе компиляции

float cos_table[100];compile_time {for (int i = 0; i < 100; ++i)cos_table[i] = std::cos(i);}// вычисление на этапе компиляцииstruct crc_string {int value;crc_string(char* v) {compile_time{this->value = crc(v);}}}

Контейнеры с типами, чтобы не мучать компилятор шаблонами с переменным числом аргументов

compile_time {auto parser_types = { int, float, std::string };}template <class T>void f(T t){compile_time {// проверка наличия типа в спискеif (parser_types.contain(T))... //какие-то проверки// просмотр членов классаif (t.members.contain("some_member_name"))...}}

Кодогенерация

void g(int t_id, char* value){switch(type_id(T)) {compile_timefor (c : parser_types) {execution_time { // строки в блоке добавить в кодcase type_id(c):some_func<T>(value);break;}}}}

Не знаю правда, как это потом отлаживать, но с шаблонами же справились.