Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Sm0ke, Вы писали:

S>>не задумывались начать составление перечня конкретных таких нюансов языка си++ ? (возможно с указанием недостающих флагов командной строки, атрибутов, и предупреждений)

ЕМ>Задумываться начал много лет назад, но все время казалось, что это очевидные идеи, и их вот-вот реализуют.

Всё же актуальность в перечне никуда не делась. Не смотря на.

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

Тем не менее я бы поучаствовал в их составлении, или хотя бы иметь возможность заревьюить)

p/s очевидно юз кейсы у людей разные, да и восприятие кэп субъективно

Здравствуйте, Sm0ke, Вы писали:

S>Тем не менее я бы поучаствовал в их составлении, или хотя бы иметь возможность заревьюить)

Ну вот чего хочется с самого начала, и что до сих пор толком не реализовано — это предупреждения на все случаи потенциальных проблем. То есть, если компилятор в состоянии из имеющейся у него информации вывести хоть какие-то подозрения — должна быть возможность их получить. Хотя бы по трем уровням — низкий/средний/высокий. И чтоб можно было в коде явно помечать атрибутами "я знаю, что это чревато, но знаю, как обеспечить надежность/безопасность". А для тех, кто не знаком с этим кодом досконально — опции командной строки, отменяющие подавление предупреждений из кода.

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

Еще было бы удобно иметь возможность объявлять, что вот с этого места и до конца области видимости объект становится константным, дабы не городить сложные приемы инициализации "в один присест" и не вводить промежуточных переменных.

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

Пригодилась бы условная трансляция, управляемая языковыми объектами, а не только макросами — по типу if constexpr, но не только для исполняемого кода, а и для определений тоже. В VC++ когда-то сделали __if_exists/__if_not_exists, но потом признали, что не могут обеспечить его работу во всех случаях из-за нелинейности трансляции тех же определений классов. Но это вполне работает по неизменяемым условиям там, где трансляция линейна. Позволяло бы по-разному определять данные в зависимости от известности и размеров типов, атрибутов объектов/функций, наличия/отсутствия фактических параметров в шаблонах и т.п.

Ну и мне тоже пригодились бы удобные средства табличной инициализации объектов класса на этапе компиляции. С возможностью класть в пропущенные значения не только нули, а какие-то явно заданные умолчания, создавать таблицы переменного размера и т.п. Для этого хорошо подошел бы даже несложный макрогенератор по типу того, что есть в MASM/TASM, даже не пришлось бы расширять языковые правила.