Здравствуйте !
Предлагаю в этой теме собирать предложения/пожелания к стандарту Си++.
Отдаю себе отчёт, что это никак не повлияет на комитет ISO, но просто интересно, чего людям не хватает.

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

Начнём.

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


2. В std::string добавить функции преобразования числа в строки и обратно. Типа такого

и т.п.
Объясню: почти наверняка у каждого есть скелет в шкафу свои обёртки над stringstream или sprintf... Почему бы не сделать это централизовано...

3. Позаимствовать у До-диеза unescape строки (не знаю, как это правильно называется), чтобы не нужно было вставлять в строку бэкслэши. Типа такого



Это сообщение отредактировал(а) borisbn - 13.4.2011, 10:32

Там уже есть модульность?

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



В dubug-компиляции выполняет весь код выше, а в релизе компилятор должен игнорировать конструкцию debug{}.

TIT, а чем условная компиляция не подходит?

а что это ? можно с примером, чтоб понятней было ?

TIT, а чем это "вкуснее", чем


Это сообщение отредактировал(а) borisbn - 13.4.2011, 09:33

ну и что делать компилятору если он видит foo(1, 2, 3);
Тройка уходит в х (и возникает ошибка "недостаточно параметров") или у? И почему?

Добавлено через 1 минуту и 14 секунд
нечто менее убогое чем директива #include препроцессора. Например вроде юнитов Паскаля

Предлагаю сделать стандартными контейнеры QT и часть типов -- QString, QVariant. Как вспомню еще - дополню)

не... вызов должен быть такой

а твой вариант должен выдавать ашипку



есть нечто подобное в ActiveX (type-library и т.п.), но в итоге всё сводится к генерации h-ников и тем же #include'ам

в общем нету.

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


не-не, активикс и не плюсоспецифичен


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

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

а если нужно, например, указать диапазон [min;max], и в большинстве случаев min=0...
Сейчас приходится либо менять их местами (полный бред)

либо не использовать параметр по-умолчанию

а хотелось бы так



Это сообщение отредактировал(а) borisbn - 13.4.2011, 10:34

Хотелось бы модульность и управляемые квалификаторы доступа, хотя бы на уровне наборов классов.
Пример - есть некая сущность, которая управляется набором классов. Есть некий класс, представляющий эту сущность (он и использует для работы вышеупомянутый набор классов). Хотелось бы сделать у каждого класса из этого набора интерфейсы, доступные для других классов этого же набора, но не доступные снаружи. Этакий friend, но не на все потроха класса, а лишь на явно заданную часть методов.

Это можно сделать и в текущем С++, но это будет либо громоздко, либо накладно, либо недостаточно избирательно   

xvr, не совсем понял, абстрактые интерфейсы ?
Можешь привести примерчик, как бы это выглядело ?

borisbn, 


Выглядит как-то криво чессслово. Уж тогда лучше как в python к примеру

1. побольше возможностей для compile-time проверок.
Например ключевое слово override как в C# значительно бы помогло при работе с виртуальными функциями. Также неплохо было бы иметь что-то вроде sealed.
Еще неплохо было бы иметь compile-time спецификацию исключений вместо того недоразумения, что есть сейчас.

2. параллельные алгоритмы
3. эффективная реализация thread-safe контейнеров
4. thread-pool
5. нормальный и не тормозной аналог sprintf-а.
6. добавить в стандарт библиотеку работы с сетью (возможно asio)
7. сериализация и отражения

пока это, потом еще дополню.

...естественно я это пишу с учетом наличия нового стандарта.

Это сообщение отредактировал(а) azesmcar - 13.4.2011, 14:06

Пример (прямо из текущего проекта).

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

Корень всего модуля - класс File. Ему дают имя ELF файла, он его читает и делает набор экземпляров классов Section.
Один экземпляр Section описывает 1 секцию кода. Он содержит собственно образ кода, таблицу релокаций и таблицу символов (это еще один класс - Symbols).

Очевидно, что у всех этих классов есть 2 набора интерфейсов - для чтения и разбора исходного ELF файла и для доступа к результатам разбора.

Второй набор интерфейсов является public интерфейсом всего модуля, а первый набор (чтение ELF файла) нужен только для начального чтения файла (он весь покрывается единственным public методом File::open() )

Проблема как раз в 1м наборе интерфейсов. Он должен быть public для всех классов, входящих в модуль (File, Section, Symbols) и private для внешнего мира.

Вот этого и не хватает