Vírgula na macro C / C ++

Digamos que temos uma macro como esta

#define FOO(type,name) type name

Que poderíamos usar como

FOO(int, int_var);

Mas nem sempre tão simplesmente:

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

Claro que poderíamos fazer:

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

o que não é muito ergonômico. As incompatibilidades do tipo Plus devem ser tratadas. Alguma ideia de como resolver isso com macro?

Porque colchetes também pode representar (ou ocorrem em) os operadores de comparação <, >, <=e >=, a expansão macro não pode ignorar vírgulas dentro de colchetes como ele faz entre parênteses. (Isso também é um problema para colchetes e colchetes, embora eles geralmente ocorram como pares equilibrados.) Você pode colocar o argumento da macro entre parênteses:

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

O problema é então que o parâmetro permanece entre parênteses dentro da expansão da macro, o que impede que seja lido como um tipo na maioria dos contextos.

Um bom truque para contornar isso é que em C ++, você pode extrair um nome de tipo de um nome de tipo entre parênteses usando um tipo de função:

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);

Como a formação de tipos de função ignora parênteses extras, você pode usar esta macro com ou sem parênteses, onde o nome do tipo não inclui uma vírgula:

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

Em C, é claro, isso não é necessário porque os nomes dos tipos não podem conter vírgulas fora dos parênteses. Portanto, para uma macro de linguagem cruzada, você pode escrever:

#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

Se você não pode usar parênteses e não gosta da solução SINGLE_ARG de Mike, basta definir uma COMMA:

#define COMMA ,

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

Isso também ajuda se você deseja sequenciar alguns dos argumentos da macro, como em

#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);
}

que imprime std::map<int , int> has typeid name "St3mapIiiSt4lessIiESaISt4pairIKiiEEE".

Se o seu pré-processador for compatível com macros variadas:

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

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

Caso contrário, é um pouco mais tedioso:

#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);

Basta definir FOOcomo

#define UNPACK( ... ) __VA_ARGS__

#define FOO( type, name ) UNPACK type name

Em seguida, invoque-o sempre com parênteses em torno do argumento de tipo, por exemplo

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

É claro que pode ser uma boa ideia exemplificar as invocações em um comentário sobre a definição da macro.

Existem pelo menos duas maneiras de fazer isso. Primeiro, você pode definir uma macro que leva vários argumentos:

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

se você fizer isso, poderá acabar definindo mais macros para lidar com mais argumentos.

Em segundo lugar, você pode colocar parênteses em torno do argumento:

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

se você fizer isso, poderá descobrir que os parênteses extras bagunçam a sintaxe do resultado.

Isso é possível com P99 :

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

O código acima remove efetivamente apenas a última vírgula da lista de argumentos. Verifique com clang -E(P99 requer um compilador C99).

A resposta simples é que você não pode. Este é um efeito colateral da escolha de <...>argumentos de modelo; o <e >também aparecem em contextos desequilibrados, de forma que o mecanismo da macro não pode ser estendido para tratá-los como faz com os parênteses. (Alguns dos membros do comitê defenderam um token diferente, digamos (^...^), mas não conseguiram convencer a maioria dos problemas de uso <...>.)