Принять в стандарт С++ расширения gcc C и gcc C++

NeoProgramming
NeoProgramming

Расширения Си: https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html

Расширения С++: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Extensions.html

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

Моя статья на Хабре https://habr.com/post/315676/ , там достаточно подробно все расписано. Впрочем, если модераторы посчитают нужным, можно просто вставить текст оттуда.

 

7
рейтинг
13 комментариев
yndx-antoshkka

Давайте по каждой конкрентой фиче проходиться отдельно. Всё сразу не примут, часть расширений - опасные и от них отказываются, часть уже принята в C++20/C++17.

Давайте начнём с ТОП-5 вещей, которые вы бы хотели видеть в C++. Что по вашему мнению самое полезное из этих расширений https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Extensions.html ?

yndx-antoshkka
Обновлено 
Antervis

yndx-antoshkka, target - автодиспатч по архитектурам. Очень приятная штука

Antervis
yndx-antoshkka

Antervis, учтите, что придётся стандартизировать имена популярных архитектур. Вы готовы взяться за черновик?

yndx-antoshkka
Antervis

yndx-antoshkka, а имена архитектур точно необходимо стандартизировать? Дело даже не в том, что их много, а в том, что target также поддерживает dispatch по наборам инструкций. Во-первых, стандартизация всяких AVX512VPOPCNTDQ будет попросту отставать по времени от потребности, а во-вторых, архитектуры как правило являются суперсетами других архитектур.
Разве нельзя обойтись правилами компиляции и выбора перегрузок? Навскидку, можно сформулировать как-то так: Функция компилируется в соответствии со всеми переданными target'ами. Если компилятор не знает указанную архитектуру (в конкретном режиме) - пропустить компиляцию функции, выдать диагностическое сообщение. Во время выполнения выбирается наиболее подходящая перегрузка по архитектуре, по принципу наиболее полного набора target'ов и его сабсетов.

Antervis
yndx-antoshkka

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

yndx-antoshkka
Antervis

yndx-antoshkka, а к стандарту вообще есть приложения с более коротким циклом обновления?

Antervis
yndx-antoshkka

Antervis, можно начать с таргетов не привязанных к конкретным платформам. Например native (текущая платформа), basic (текущие настройки компилятора), all (нагенерить для всех возможных платформ)

yndx-antoshkka
Antervis

yndx-antoshkka, вряд ли платформонезависимые варианты all/basic/default/native помогут для значимого процента юзкейсов. А можно сослаться на какой-то другой документ с перечислением существующих платформ/архитектур, их иерархий и наименований?

Antervis
yndx-antoshkka

Antervis, да, можно сослаться. Главное чтобы такой документ нашёлся.

yndx-antoshkka
iksk810

Элвис-оператор было бы неплохо принять. Мелочь, а приятно. )

iksk810
Игорь Шаповал

Хотелось бы чтобы приняли switch c диапазоном значений

switch (number) {
case 1 ... 5:
    // code
    break;
default:
    // code
} 
Игорь Шаповал
Игорь Шаповал

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

Игорь Шаповал
yndx-antoshkka

Игорь Шаповал, что-то подобное обсуждается вот тут http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1308r0.html . Я сильно против этого предложения - выглядит по уродски, читать не удобно.

yndx-antoshkka
Другие идеи
Группа создана, чтобы собирать предложения к стандарту C++, организовывать их внутренние обсуждения, помогать готовить их для отправки в комитет и защищать на общих собраниях в рабочей группе по С++ Международной организации по стандартизации (ISO).
Все предложения