Обычный ответ на этот вопрос заключается в том, что стандартный C ++ decltype обладает той же функциональностью, что и __typeof__
,
Что не соответствует действительности. В то время как decltype может принимать выражение только в качестве аргумента, __typeof__
также может принимать имя типа.
Как бы странно это ни казалось, у меня есть реальный вариант использования, и мне нужно перенести что-то, что я не написал с платформы, используя это расширение, на платформу без расширения. И выражение, и тип передаются макросом, поэтому переписанная версия должна принимать оба.
Упрощенный пример псевдокода:
// from header.h
#define MYMACRO(a) \
\
/* long code */ \
\
using MyTypeA = decltype(some_processing_of #a) \
using MyTypeB = __typeof__(a); \
\
/* long code */ \
\
using MyType = std::conditional_t< \
is_string_literal_test \
, MyTypeA \
, MyTypeB >; \
\
/* long code */ \// from use_case1.cpp
struct S {};
MYMACRO(S)// from use_case2.cpp
MYMACRO("some text")// example of __typeof__ in GCC that compiles
struct S {};
using T1 = __typeof__(S);
using T2 = __typeof__("some text");
Вопрос не в дизайне окружающего приложения, а в моделировании расширения __typeof__ в спецификации, заданной реализацией в GCC.
Хотя вариант использования немного уже, чем полная спецификация __typeof__. Вместо всех общих выражений достаточно, если он работает со строковыми литералами. Что не облегчает работу с шаблонами и / или попытками SFINAE.
Конечно, для своих внутренних целей я могу написать MYMACROA для строковых литералов и MYMACROB для типов, я бы не стал возражать против этого. Но он не имеет пользовательского опыта исходного решения, использующего расширение __typeof__. И именно поэтому я заинтересован в этом.
Задача ещё не решена.
Других решений пока нет …