Нужен совет о том, как интерпретировать AUTOSAR. Я работаю над реализацией стандартной библиотеки C ++, совместимой с AUTOSAR, и к моему вопросу применимы три разных правила:
Rule M2-10-3 (required, implementation, automated)
A typedef name (including qualification, if any) shall be a unique
identifier
Rule A2-11-2 (required, implementation, automated)
A “using” name shall be a unique identifier within a namespace.
Rule A2-11-3 (required, implementation, automated)
A “user-defined” type name shall be a unique identifier within a namespace.
К сожалению, во всех трех этих правилах указано «пространство имен», но не указывайте также "область видимости класса". Проблема заключается в том, что псевдонимы, определенные в шаблонах (простые псевдонимы, такие как type, reference, pointer, et c ...), которые многократно используются, могут потенциально нарушать это правило. Если это так, то стандартное программирование c практически невозможно, так как понятие «концепция» больше не работает, так как каждый класс должен будет определять псевдоним по-своему. Например, псевдонимы std::array * value_type и iterator должны быть определены как что-то вроде array_value_type и array_iterator, чтобы они не сталкивались с псевдонимами std::vector, что потребовало бы быть названным как что-то вроде vector_value_type и vector_iterator. Хотя в некоторых случаях это нормально, в обобщенной функции c, которая должна получить value_type элементов в контейнере, вам нужно будет сделать что-то вроде decay_t(decltype(data())), чтобы получить тип, поскольку вы не можете использовать псевдонимы. так как у них разные имена.
Это также означало бы, что Стандартная библиотека C ++ будет в WILD нарушать это правило, поскольку все контейнеры и type_traits интенсивно используют псевдонимы с одинаковыми именами. M2-10-3 гласит «включая квалификацию, если таковая имеется», которая будет включать в себя область действия класса Проблема в том, что A2-11-2 и A2-11-3 не включают такой язык.
ИМО, что они пытаются сказать (основываясь на их ссылках), что typedef не должен скрывать другой typedef. Другими словами, typedef, определенный во внешней области видимости, не должен иметь того же имени, что и typedef, определенный во внутренней области видимости. Подобно тому, как имя переменной не должно скрывать другое имя переменной во внешней области видимости. Для псевдонимов областей действия это правило все еще требуется (т.е. не следует определять typedef type глобально, а затем также иметь псевдоним области класса с именем type, поскольку один скрывает другой), но наличие array::value_type и vector::value_type будет будьте в порядке, поскольку их имена (включая их квалификации) уникальны и не скрывают псевдонимы во внешней области видимости.
Прав ли я в своем толковании этого правила или мне необходимо документально подтвердить необходимость исключения из этих трех правил? Хотя я мог бы гарантировать, что каждая черта типа, используемая для SFINAE, которая определяет type, имеет уникальное имя (например, add_const будет иметь add_const_type), это было бы довольно серьезным изменением, если вы не используете _t варианты этих типов черт и другие обобщенные c функции для контейнеров становятся намного более сложными, так как вы не можете полагаться на C::value_type, так как имя должно быть другим.
Также обратите внимание, что я использую Perforce Helix QA C для анализа stati c, который не согласуется с моей интерпретацией выше и требует уникальных имен для всех псевдонимов, включая область видимости класса.