Ich versuche gerade Makros mit einer variablen Anzahl von Parametern zu erstellen. Im Internet bin ich unter anderem auf folgende Lösung gestoßen, die auch funktioniert:

#include <iostream>

using namespace std;

#define XXX_X(x,A,B,FUNC, ...)  	FUNC
#define XXX(...)                    XXX_X(,##__VA_ARGS__,\
                                          XXX_2(__VA_ARGS__),\
                                          XXX_1(__VA_ARGS__),\
                                          XXX_0(__VA_ARGS__)\
                                         )

#define XXX_0()                     cout << "no Arg" << endl;
#define XXX_1(A)                   	cout << "Arg 1: " << A << endl;
#define XXX_2(A,B)                 	cout << "Arg 1: " << A <<  "  Arg 2: " << B << endl;

int main ()
{
	XXX();
	XXX(1);
	XXX(4, 6);

	return 0;
}

'__VA_ARGS__' fasst, so wie ich es verstanden habe, alle Argumente zusammen. Allerdings kann ich die Auflösung des Makros (bzw. der Makrokette) nicht nachvollziehen. Rufe ich z.B. folgende Zeile auf:

XXX(1);

so würde ich es wie folgt ersetzen:

XXX_X(,1, XXX_2(1),XXX_1(1), XXX_0(1))

Hier bin ich mir schon nicht sicher, warum das Makro 'XXX_X' mit ',##' beginnt. Ohne funktioniert es jedenfalls nicht mehr. Außerdem bin ich mir auch nicht sicher, wie das Makro weiter aufgelößt wird, so dass dann 'XXX_1(A)' angewendet wird. Auch Zeile '#define XXX_X(x,A,B,FUNC, ...) FUNC' verstehe ich nicht so ganz. .

Kann mir jemand einen Tipp geben, wie das aufgelöst wird? Ich möchte ja schon gerne verstehen.

viele Grüße,
SBond

Und kann das mal jemand nach C++ verschieben? Schankedön.

#define RETURN_IF_FAILED(func)					\
{												\
	func;										\
	if (getStatuscode() != NO_ERROR)			\
	{											\
		return -1;								\
	}											\
}

#define RETURN_IF_FAILED(func, returnValue)		\
{												\
	func;										\
	if (getStatuscode() != NO_ERROR)			\
	{											\
		return returnValue;						\
	}											\
}

Ich möchte also ein Makro 'RETURN_IF_FAILED' nutzen, den ich einen optionalen Rückgabewert geben kann:

RETURN_IF_FAILED(meineBeispielFunktion());
RETURN_IF_FAILED(meineBeispielFunktion(), MeinRückgabewertBeiFehler);

Gruß,
SBond

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Ich möchte also ein Makro 'RETURN_IF_FAILED' nutzen, [...]

Nein. Möchtest Du nicht!
Du möchtest ein Problem lösen.
Offensichtlich mit C++.

Makros wie 'RETURN_IF_FAILED' kenne ich noch aus Frameworks, mit denen ich mal kurzfristig zu tun hatte. Daher wollte ich so etwas auch in meinem Code zur Verfügung stellen. Nur weiß ich nicht, wie ich optionale Parameter realisiere. Der Code im 1. Post funktioniert z.B. unter g++ problemlos, aber nicht unter vc++.

Wie könnte man das Problem in meinen 2. Post am besten angehen. Wären hier das arbeiten mit Exceptions besser?

Edit: wie ich gerade sehe, finden Makros hier nicht viele Freunde. Sind Makros wirklich so schlimm?

Edit 2: Ja exceptions sehen schon mal sehr interessant aus und werde ich morgen in meinen Quellcode integrieren. Danke für den Tipp. Allerdings ist es für eine lokale Fehlerbehandlung in den einzelnen Funktionen ggf. nicht ideal. ...bin mir da nicht sicher.

viele Grüße,
SBond

Momentan setze ich für meine Masterarbeit ein Protokoll zur sicheren Zeitübertragung um. Habe mich daher für C++ entschieden, um dahingehend auch Wissen anzusammeln. Für die Entwicklung nutze ich drei externe Bibliotheken, für die ich Wrapper schreibe, um diese besser nutzen zu können.

hier mal ein Ausschnitt aus einer Klasse:

int Asn1Wrapper::setAny(ANY_t &destination, const unsigned char &source, int num)
{
	// check parameters
	if (num <= 0)
	{
		setStatuscode(NTS_ERR__INVALID_PARAMETER);
		return RETURN_ERROR;
	}

	// delete existing content
	clearAny(destination);

	// allocate and zero-initialize memory
	destination.buf = (unsigned char*)calloc(1, num);

	// check memory
	if (destination.buf == NULL)
	{
		setStatuscode(NTS_ERR__NO_MEMORY);
		return RETURN_ERROR;
	}

	// save new values
	memcpy(destination.buf, &source, num);
	destination.size = num;

	// return success
	setStatuscode(NTS_ERR__NO_ERROR);
	return RETURN_NO_ERROR;
}

Vorweg: calloc() benutze ich hier bewusst, da die Lib in C geschrieben ist und gelegentlich einen realloc() anwendet. Ich denke das Mischen von new und realloc ist keine gute Idee. Was man hier auch gut sieht, ist dass ich mit Fehlerflags nicht sparsam bin. Der Grundgedanke ist erstmal, dass ich später jeden Fehler loggen kann. Nun war meine Überlegung, wie ich das ganze Verkürzen kann, da ich ja vor jedem return einen Statuscode setze. Meine Lösung war erstmal Makros. Ich habe mich da unter anderem an einem Framework und OpenSSL orientiert, da ich einfach nichts besseres gefunden habe und wissen wollte, wie größere Softwareprojekte mit Fehlerbehandlung umgehen. Nach dem einsetzen der Makros ändert sich mein Code wie folgt:

int Asn1Wrapper::setAny(ANY_t &destination, const unsigned char &source, int num)
{
	// check parameters
	if (num <= 0)
	{
		RETURN_ERROR(NTS_ERR__INVALID_PARAMETER);
	}

	// delete existing content
	RETURN_IF_FAILED(clearAny(destination));

	// allocate and zero-initialize memory
	destination.buf = (unsigned char*)calloc(1, num);

	// check memory
	RETURN_IF_POINTER_NULL(destination.buf, NTS_ERR__NO_MEMORY);

	// save new values
	memcpy(destination.buf, &source, num);
	destination.size = num;

	// return success
	RETURN_SUCCESS;
}

Hinter dem Makro RETURN_IF_FAILED verbirgt sich folgendes:

#define RETURN_IF_FAILED(func)				\
{											\
	int statusCode = 0;						\
	registerFunc(#func, "in"); 				\
	func;									\
	statusCode = getStatuscode();			\
	registerFunc(#func, "out", statusCode); \
	if (statusCode != NTS_ERR__NO_ERROR)	\
	{										\
		return -1;							\
	}										\
}

Kurze Erläuterung zur gedachten Funktionsweise:
Meine Überlegung war, ob ich alle meine Funktionen mit diesen Makros ausstatte. Das Makro RETURN_IF_FAILED könnte ich nämlich leicht zum Loggen der Funktionen erweitern (so wie bereits im Code). Die Funktion 'registerFunc()' ist momentan noch leer. Diese registriert mit Hilfe des Makros RETURN_IF_FAILED den Aufruf und das Verlassen einer Funktion. Werden mehrere Funktionen kaskadiert aufgerufen, so lassen sich die Funktionsaufrufe verfolgen. In etwa so:

call function_1
	call function_2
		call function_3
		exit function_3, exitcode
	exit function_2, exitcode
	call function_4
		call function_3
		exit function_3, exitcode
	exit function_4, exitcode
exit function_1, exitcode

...gut das würde ich dann als Baumansicht mit einem Log-Auswertungsprogramm darstellen. Beim Makro RETURN_IF_FAILED gibt es allerdings ein Problem, wenn ich einen benutzerdefinierten Rückgabewert anstatt '-1' senden möchte. Dafür müsste mein Makro sinngemäß so aussehen: RETURN_IF_FAILED(func, <optionalReturnValue>). ...gut auf die Verfolgung der Funktionsaufrufe kann ich eigentlich auch verzichten, aber die Fehler möchte ich schon gerne loggen.

...Möglicherweise ist mein Lösungsansatz nicht so prall. Ich bin mir auch nicht sicher, wie eine saubere Alternative aussehen könnte. Exception sind schon interessant, aber wahrscheinlich nicht für einfache Fehler wie ein ungültiger Parameter sinnvoll. ....ich hätte nicht gedacht, dass mir eine Fehlerbehandlung so viel Kopfzerbrechen bereiten kann

Was kann ich tun?

@SeppJ: nochmals danke für die Links. Hatte ich gestern bereits gelesen, wobei insbesondere der zweite Link mich noch zu sehr fordert.

viele Grüße,
SBond.

Ich denke der richtige Weg ist in meinem Fall die C++ error exception. So nimmt die eingangs gestellte Frage ein ganz anderes Ende. Abschließend hätte ich noch eine kleine Frage, die sich mir noch nicht beantwortet hat: Wenn ich in ein einem try{}-Block z.B. eine Funktion aufrufe die einen throw wirft, wie kann ich im catch{}-Block herausfinden, ob ich eventuell noch dynamischen Speicher freigeben muss, die in irgendeiner kaskadierten Subfunktion mal alloziert wurde?

Wenn ich in ein einem try{}-Block z.B. eine Funktion aufrufe die einen throw wirft, wie kann ich im catch{}-Block herausfinden, ob ich eventuell noch dynamischen Speicher freigeben muss, die in irgendeiner kaskadierten Subfunktion mal alloziert wurde?

Gar nicht.
Versuch es, wie Volkard vorschlägt. Stichwort ist: RAII.