Кома в макросі C / C ++

Скажімо, у нас є такий макрос

#define FOO(type,name) type name

Якими ми могли б користуватися

FOO(int, int_var);

Але не завжди так просто:

FOO(std::map<int, int>, map_var); // error: macro "FOO" passed 3 arguments, but takes just 2

Звичайно, ми могли б зробити:

 typedef std::map<int, int> map_int_int_t;
 FOO(map_int_int_t, map_var); // OK

що не дуже ергономічно. Плюс несумісність має бути вирішена. Будь-яка ідея, як вирішити це за допомогою макросу?

Оскільки кутові дужки можуть також представляти (або відбуваються в) оператори порівняння <, >, <=і >=, макро розширення не може ігнорувати коми всередині кутові дужки , як це відбувається в круглих дужках. (Це також проблема квадратних дужок і дужок, навіть якщо вони зазвичай бувають врівноваженими парами.) Макро аргумент можна вкласти в круглі дужки:

FOO((std::map<int, int>), map_var);

Проблема полягає в тому, що параметр залишається в скобках усередині макророзширення, що не дозволяє його читати як тип у більшості контекстів.

Приємний фокус для вирішення цього полягає в тому, що в C ++ ви можете витягти ім'я типу з імені типу в скобках, використовуючи тип функції:

template<typename T> struct argument_type;
template<typename T, typename U> struct argument_type<T(U)> { typedef U type; };
#define FOO(t,name) argument_type<void(t)>::type name
FOO((std::map<int, int>), map_var);

Оскільки формуючі типи функцій ігнорують додаткові дужки, ви можете використовувати цей макрос із дужками або без них, де ім'я типу не містить кома:

FOO((int), int_var);
FOO(int, int_var2);

Звичайно, це не обов'язково, оскільки імена типів не можуть містити коми поза дужок. Отже, для міжмовного макросу ви можете написати:

#ifdef __cplusplus__
template<typename T> struct argument_type;
template<typename T, typename U> struct argument_type<T(U)> { typedef U type; };
#define FOO(t,name) argument_type<void(t)>::type name
#else
#define FOO(t,name) t name
#endif

Якщо ви не можете використовувати дужки, і вам не подобається рішення SINGLE_ARG Майка, просто визначте COMMA:

#define COMMA ,

FOO(std::map<int COMMA int>, map_var);

Це також допомагає, якщо ви хочете впорядкувати деякі аргументи макросу, як у

#include <cstdio>
#include <map>
#include <typeinfo>

#define STRV(...) #__VA_ARGS__
#define COMMA ,
#define FOO(type, bar) bar(STRV(type) \
    " has typeid name \"%s\"", typeid(type).name())

int main()
{
    FOO(std::map<int COMMA int>, std::printf);
}

який друкує std::map<int , int> has typeid name "St3mapIiiSt4lessIiESaISt4pairIKiiEEE".

Якщо ваш препроцесор підтримує різні макроси:

#define SINGLE_ARG(...) __VA_ARGS__
#define FOO(type,name) type name

FOO(SINGLE_ARG(std::map<int, int>), map_var);

Інакше це трохи стомливіше:

#define SINGLE_ARG2(A,B) A,B
#define SINGLE_ARG3(A,B,C) A,B,C
// as many as you'll need

FOO(SINGLE_ARG2(std::map<int, int>), map_var);

Просто визначте FOOяк

#define UNPACK( ... ) __VA_ARGS__

#define FOO( type, name ) UNPACK type name

Потім завжди викликайте круглі дужки навколо аргументу типу, наприклад

FOO( (std::map<int, int>), map_var );

Звичайно, може бути хорошою ідеєю приклади викликів у коментарі до визначення макросу.

Існують як мінімум два способи зробити це. Спочатку ви можете визначити макрос, який приймає кілька аргументів:

#define FOO2(type1, type2, name) type1, type2, name

якщо ви зробите це, ви можете виявити, що в кінці кінців визначаєте більше макросів для обробки більшої кількості аргументів.

По-друге, навколо аргументу можна поставити круглі дужки:

#define FOO(type, name) type name
F00((std::map<int, int>) map_var;

якщо це зробити, ви можете виявити, що додаткові дужки накручують синтаксис результату.

Це можливо з P99 :

#include "p99/p99.h"
#define FOO(...) P99_ALLBUTLAST(__VA_ARGS__) P99_LAST(__VA_ARGS__)
FOO()

Наведений вище код ефективно знімає лише останню кома у списку аргументів. Перевірте clang -E(P99 вимагає компілятора C99).

Проста відповідь полягає в тому, що ви не можете. Це побічний ефект вибору <...>аргументів шаблону; , <а >також з'являються в неврівноваженому контексті, тому макромеханізм не можна розширити для обробки, як він обробляє дужки. (Скажімо (^...^), деякі члени комітету стверджували, що це не так , але вони не змогли переконати більшість проблем із використанням <...>.)