Или вы имеете в виду, что OuterFunc возвращает ссылку на локальную для OuterFunc переменную. В этом случае у меня для вас плохие новости - этот код всегда был UB, при том и в чистом C вы скорее всего получите проезд по стеку.
Потому что, если написать, как в первом примере выше, то можно легко напороться на ситуацию, когда неименованный временный TempObject из первого примера уничтожится, не доходя даже вовнутрь OuterFunc, т.к. его областью видимости почему-то являются круглые скобки, а не фигурные!
C++ так не работает, в данном примере временные объекты будут жить до окончания вызова функции OuterFunc.
А почему почему вы хотите это запрещать? Например многие проекты используют макрос, чтобы задать namespace и inline namespace с версией. С вашим предложением этот функционал перестанет работать
В данном случае никакой новый функционал не добавляется и основная задача предложения - это не сломать старое поведение мароксов в легаси коде (с их обработкой только в препроцессоре)
Но ведь макросы и так можно использовать в именованных модулях в global module fragment и они прорастают ниже в module unit, и за его пределы не экспортируются.
Так зачем делать работу, по обучению AST в макросы?
Приведите пожалуйста примеры, какой именно новый функционал получаем, с данным предложением. Да, заставить макросы работать по правилам C++ - это приятно, но слишком много нюансов и проблем возникает, пока кажется что овчинка не стоит выделки
#define MACRO_LOCAL macro_local
import mod; // В модуле mod видны оба макроса MACRO_GLOBAL и MACRO_LOCAL
никак не сможет работать с модулями. Именованный модуль уже "запечён", и в него ничего больше не прилетает. Такой модуль - это практически иммутабельный бинарный блоб. Что-то схожее предлагалось в https://github.com/cplusplus/papers/issues/2316 и комитет был против
После чего вот прям благодать настала со стандартами C++14 и C++17. Но вот уже с C++20 опять та же
С C++20 основная засада - модули. Остальное всё уже реализовано, но модули - очень большая и многогранная фича, требующая работы над множеством частей C++ (форнтенд и мидленд компилятора, линкеры, системы сборки, библиотеки, ...)
В С++23 и C++26 нет таких "монстров", так что должно всё гладко идти и вендоры быстро наверстают отставание
Оно уже распараллелено, насколько это возможно. Однако, есть критические секции, которые не паралеллятся или плохо паралеллятся
а так ли важна сейчас для C++ именно ISO стандартизация?
Как ни странно - да. C++ чуть ли не единственный современный язык программирования, который можно использовать в приложениях, напрямую влияющих на жизнь человека (самолёты, автомобили, медицинское оборудование, ...). А для такого использования нужна ISO стандартизация.
Без этого - потеряется ощутимая часть пользователей
Но не удивлюсь, если офлайн участники тоже не знают какая там погода - обычно времени на осмотр окресностей нет, график очень плотный, а в больших аудиториях с окнами зачастую напряжёнка
Какой вообще смысл в таких тусовках?
Основной смысл - общий сбор, точка синхронизации и формального голосования. Онлайн тоже есть, но встреча работает эффективнее
Да, со временем :)
... а получить такую сертификацию для программы не на ISO языке в ряде стран вообще невозможно. ISO обязательное условие, но не достаточное
Что касается MISRA и аналогичных стандартов/требований/гайдов - то их делают зачастую всё те же люди из C++ комитета :)
Кстати, следующий релиз GCC (GCC-16) будет по умолчанию использовать стандарт C++20: https://github.com/gcc-mirror/gcc/commit/004438857554f47eb5491d59b067e56fdacf0e74
Увы, не успели к C++26. Буквально в последнее большое окно пытались решить все проблемы и протащить фичу, но она всё ещё оказалась "сыровата"
Ждём в C++29
Я затрудняюсь сейчас примомнить современный язык программирования без линтеров, guidelines и подобных инструментов. Вся индустрия больна?
А подскажите, как сделать лучше? Что упростить?
Или вы имеете в виду, что OuterFunc возвращает ссылку на локальную для OuterFunc переменную. В этом случае у меня для вас плохие новости - этот код всегда был UB, при том и в чистом C вы скорее всего получите проезд по стеку.
C++ так не работает, в данном примере временные объекты будут жить до окончания вызова функции OuterFunc.
Пока новостей нет. Работа идёт в https://wg21.link/p3286 , но там пока очень далеко до финала
А какие именно больные места?
Именно на публичный интерфейс и влияет макрос для namespace, так что сломается :(
А почему почему вы хотите это запрещать? Например многие проекты используют макрос, чтобы задать namespace и inline namespace с версией. С вашим предложением этот функционал перестанет работать
Но ведь макросы и так можно использовать в именованных модулях в global module fragment и они прорастают ниже в module unit, и за его пределы не экспортируются.
Так зачем делать работу, по обучению AST в макросы?
Приведите пожалуйста примеры, какой именно новый функционал получаем, с данным предложением. Да, заставить макросы работать по правилам C++ - это приятно, но слишком много нюансов и проблем возникает, пока кажется что овчинка не стоит выделки
Идея https://github.com/cpp-ru/ideas/issues/622 предлагает экспортировать макросы из global module fragment для именованных модулей. https://github.com/cplusplus/papers/issues/2316 предлагал то же самое
Та часть вашего предложениея, что
никак не сможет работать с модулями. Именованный модуль уже "запечён", и в него ничего больше не прилетает. Такой модуль - это практически иммутабельный бинарный блоб. Что-то схожее предлагалось в https://github.com/cplusplus/papers/issues/2316 и комитет был против
Вроде бы уже всё есть. Можете пожалуйста привести пару примеров, чего не хватает?
Международный комитет выступил против подобной идеи https://github.com/cplusplus/papers/issues/2316
Если хочется продолжить работу - нужна новая, более внушительная, мотивация
С C++20 основная засада - модули. Остальное всё уже реализовано, но модули - очень большая и многогранная фича, требующая работы над множеством частей C++ (форнтенд и мидленд компилятора, линкеры, системы сборки, библиотеки, ...)
В С++23 и C++26 нет таких "монстров", так что должно всё гладко идти и вендоры быстро наверстают отставание
Оно уже распараллелено, насколько это возможно. Однако, есть критические секции, которые не паралеллятся или плохо паралеллятся
Как ни странно - да. C++ чуть ли не единственный современный язык программирования, который можно использовать в приложениях, напрямую влияющих на жизнь человека (самолёты, автомобили, медицинское оборудование, ...). А для такого использования нужна ISO стандартизация.
Без этого - потеряется ощутимая часть пользователей
Не в курсе, я удалённо участвовал :)
Но не удивлюсь, если офлайн участники тоже не знают какая там погода - обычно времени на осмотр окресностей нет, график очень плотный, а в больших аудиториях с окнами зачастую напряжёнка
Основной смысл - общий сбор, точка синхронизации и формального голосования. Онлайн тоже есть, но встреча работает эффективнее