Die Abhilfemaßnahme in Frage lautet:
#define EXPAND(x) x
#define F(x, ...) X = x and VA_ARGS = __VA_ARGS__
#define G(...) EXPAND(F(__VA_ARGS__))
Die Idee ist, dass angesichts einer bestehenden variadische Makro F()
:
#define F(x, ...) X = x and VA_ARGS = __VA_ARGS__
stattdessen gewünschten variadische Wrapper Makro wie in diesem Fall des Schreibens, ...
#define G(...) F(__VA_ARGS__)
... schreiben Sie G()
mit der Verwendung der zusätzlichen EXPAND()
Makro. Die tatsächliche Definition von F()
ist nicht der Punkt, und insbesondere spielt es für dieses Beispiel keine Rolle, dass die Makroexpansion keinen gültigen C-Code erzeugt. Sein Zweck besteht darin, das Verhalten des Präprozessors in Bezug auf Makroargumente zu demonstrieren. Insbesondere zeigt es, dass, obwohl MSVC __VA_ARGS__
zu einem einzelnen Token in einem Variadic-Makro erweitert, das um eine doppelte Erweiterung erzwungen werden kann.
beispielsweise die Abhilfe Definition verwendet wird, der Vorprozessor erste erweitert ...
G(1, 2, 3)
... bis ...
EXPAND(F(1, 2, 3))
... wo die 1, 2, 3
als behandelt wird einzelnes Token. Diese Tokenisierung spielt jedoch keine Rolle mehr, wenn der Präprozessor erneut nach zusätzlichen Ersetzungen sucht: Er sieht die 1
, 2
, 3
als separate Argumente für das Makro F()
und erweitert diese, um das Argument für das Makro EXPAND()
zu erzeugen, das es einfach durch es ersetzt.
Wenn Sie es seltsam finden, dass dies wie vorgesehen funktioniert, aber die Version ohne EXPAND()
nicht funktioniert (in MSVC), haben Sie Recht.
Ich denke, der verknüpfte Beitrag ist nicht korrekt. Ich denke, die richtige Lösung ist 'G (...) F (EXPAND (__ VA_ARGS__))' – LPs
@LPs, dachte ich auch, aber versuchen Sie es. –
@JohnBollinger Ich bin zu Linux drin, um MSVC in die Hände zu bekommen :). Ernsthaft, ich habe keine MSVC, um es zu testen. Lassen Sie OP versuchen Sie es – LPs