PYFUNC(ConCommand, hook)
{
	char szName[32] = { '\0' };
	PyObject *pyCallback = NULL;

	Msg("String Adress: %x\n", (unsigned long)szName); // Adresse valid (12b9e0)

	if (!pPython->getArgs(pyArgs/*durch Makro PYFUNC erstellt*/, 2, 0, 3/*nächstes Argument: String*/, szName, 9/*nächstes Argument: Callback*/, pyCallback))
	{
		return (PyObject*)NULL;
	}

	//...
}

//CPython *pPython = new CPython;

bool CPython::getArgs(PyObject *pyArgs, int iNeeded, int iOptional, ...)
{
	int iCount = (iNeeded + iOptional) * 2;
	char szParse[21] = { '\0' };

	for (int i = 0; i < iNeeded; i++)
	{
		strcat(szParse, "O"); // erst alle benötigten Argumente
	}

	strcat(szParse, "|"); // Trenner zum anzeigen, dass Argumente ab hier optional sind

	for (int i = 0; i < iOptional; i++)
	{
		strcat(szParse, "O"); // restliche Argumente
	}

	char szError[64] = { '\0' };
	PyObject *pyArgList[20];

	// an Pythoninstanz abgeben zum auswerten
	if (!PyArg_ParseTuple(pyArgs, szParse, &pyArgList[0], &pyArgList[1], &pyArgList[2], &pyArgList[3], &pyArgList[4], &pyArgList[5], &pyArgList[6], &pyArgList[7], &pyArgList[8], &pyArgList[9], &pyArgList[10], &pyArgList[11], &pyArgList[12], &pyArgList[13], &pyArgList[14], &pyArgList[15], &pyArgList[16], &pyArgList[17], &pyArgList[18], &pyArgList[19]))
	{
		PyErr_SetString(PyExc_TypeError, pTools->format("failed to parse all arguments (%i required, %i optional)", szError, iNeeded, iOptional));
		return false;
	}

	int Next = 0;

	va_list vaParameters;
	va_start(vaParameters, iCount);

	Msg("Loop: Start\n");

	for (int i = 0, k = 0; i < iCount; i++)
	{
		Msg("Loop: %i ", i);

		if (i % 2 == 0)
		{
			Msg("- Next: ");

			Next = va_arg(vaParameters, int);
			Msg("%i\n", Next); // hier kommt völliger Nonsense, irgendwelche Zahlen über 1 Million
			// funktioniert ebenso wenig: Next = *va_arg(vaParameters, int*);
		}
		else
		{
			PyObject *pyArg = pyArgList[k++];

			//...
			else if (Next == 3)
			{
				char *pszString = va_arg(vaParameters, char*);

				//Msg("Debug: %s\n", x); <- crasht
				Msg(" - Parse String: %x\n", (unsigned long)x); // Adresse führt irgendwo ins nirvana, stimmt jedenfalls NICHT

				//...
			}
			//...
			else if (Next == 9)
			{
				PyObject *pyValue = va_arg(vaParameters, PyObject*);

				Msg(" - Parse Callback: %x\n", (unsigned long)pyValue); // ebenfalls völliger Unsinn

				//...
			}
		}

		// ...
	}

	va_end(vaParameters);

	return true;
}

Die Ausgabe der Debugnachrichten sieht so aus:

String Adress: 12b9e0
Loop: Start
Loop: 0 - Next: 279340096 // sollte 3 sein
Loop: 1 - Parse String: 10a98c40 (sollte 12b9e0 sein)
Loop: 3 - Next: 279427952 // sollte 9 sein
Loop: 4 - Parse Callback: 10c83880 (sollte jedenfalls was anderes sein)

Danke!

Ich meine, warum nutzt Du auch "var args" und warum nutzt Du char-Arrays mit den C-Stringfunktionen? Das ist alles inhärent fehleranfällig.

bool CPython::getArgs(PyObject *pyArgs, int iNeeded, int  iOptional, ...)
{
    int iCount = (iNeeded + iOptional) * 2;
    [...]
    va_list vaParameters;
    va_start(vaParameters, iCount);

Das kann ja schonmal nicht stimmen. Müsste doch eigentlich

va_start(vaParameters, iOptional);

heißen, nicht?

kk

Aber das iCount ist schon richtig. Denn es gibt ja für jeden erwarteten Parameter der Python Funktion zwei Werte, die ich annehme. Einmal der Typ des erwarteten Parameters (z.B. 3 aka String) und dann die Adresse zur Variable. Also muss man die Anzahl der Parameter mal 2 nehmen. iNeeded gibt nur an, dass z.B. zwei Parameter benötigt, und z.B. 0 weitere Optional sind (iOptional).

Gruß

Wieso selbst Schuld? Es gibt keine (mir bekannte) Möglichkeit, dass anders komfortabel und ohne Makros zu lösen.

Arrays, Vectoren, Listen, Maps...

Money for nothing chicks for free

Gruß

Gruß

Die erwarteten Parameter sind wie gesagt variabel und ich kann deshalb nicht einfach einen Vektor nehmen. Und da sie zur Compilezeit feststehen ist das auch gar nicht nötig.

Templates, Operatorüberladung, Funktoren, Referenzenrückgabe?

Gruß

Aber das iCount ist schon richtig.

nein, siehe va_start(). Da musst du das letzte Argument vor den "..." übergeben.

Ich kann nicht verstehen was daran gefährlich ist, solange man es richtig anwendet.

Haargenau! Wieso machst du es dann nicht?

theliquidwave schrieb:

Aber das iCount ist schon richtig. Denn es gibt ja für jeden erwarteten Parameter der Python Funktion zwei Werte, die ich annehme. Einmal der Typ des erwarteten Parameters (z.B. 3 aka String) und dann die Adresse zur Variable. Also muss man die Anzahl der Parameter mal 2 nehmen. iNeeded gibt nur an, dass z.B. zwei Parameter benötigt, und z.B. 0 weitere Optional sind (iOptional).

Lies mal die Dokumentation, was als zweites Argument von va_start benötigt wird:
http://www.cplusplus.com/reference/clibrary/cstdarg/va_start/

Das ist nur einer der vielen Gründe, wieso dies eine schlechte Lösung ist. Du hast es grad selber bewiesen

theliquidwave schrieb:

Dann müsste ich ja 10 Templateklassen erstellen, die jeweils 1, 2, 3, 4, 5, 6, 7, 8, 9 oder 10 Parameter annehmen kann. Sowas nenne ich weder elegant noch komfortabel.

Mit Makros aber durchaus machbar. Und zukünftig dann durch variadic Templates ersetzbar.

Grüssli

Danke!

Und zukünftig dann durch variadic Templates ersetzbar.

Wenn dein Compiler Variadic Templates nicht unterstützt könntest du zb. auf gcc umsteigen, dieser Compiliert folgenden code einwandfrei:

template<class Type>
void Print( Type Arg )
{
    std::cout<< Arg <<"\n" ;
}

template<class Type, class...Types>
typename
std::enable_if< sizeof...(Types)<10 , void > // Maximal 10 args
::type Print( Type Arg , Types...Args )
{
    std::cout<< Arg <<"\n" ;
    Print(Args...); // Rekrusion
}

int main()
{
    Print("eins",2,3,4,5);
}

Gruss
Speed

Wenn dein Compiler Variadic Templates nicht unterstützt könntest du zb. auf gcc umsteigen, ...

Und so ein Umstieg ist einfach und problemlos möglich
Wenn wir es zudem ganz genau nehmen, sind variadic Templates noch gar nicht als Standard definiert

Also bevor man vorschnell den Kompiler wechselt und die ganze Entwicklungsumgebung womöglich gleich mit, sollte man sich überlegen, ob ein bis zwei Jahre zusätzliches Warten, vielleicht nicht besser wäre.

Grüssli

Speed schrieb:

Wenn dein Compiler Variadic Templates nicht unterstützt könntest du zb. auf gcc umsteigen, ...

Und so ein Umstieg ist einfach und problemlos möglich
Wenn wir es zudem ganz genau nehmen, sind variadic Templates noch gar nicht als Standard definiert

Also bevor man vorschnell den Kompiler wechselt und die ganze Entwicklungsumgebung womöglich gleich mit, sollte man sich überlegen, ob ein bis zwei Jahre zusätzliches Warten, vielleicht nicht besser wäre.

Grüssli

Sind Variadic Templates nicht im C++09-Standart eingeführt worden?
Glaubst du das Compilerhersteller-die es Bereits eingeführt haben das anschließend wieder, raus nehmen werden?
Naja wie auch immer...

Meistens ist es dem Kunden egal, Wie Man etwas macht - er will Ergebnisse sehen.
Und mit Konstrukten wie diesen kann man m.E. viel schneller und effizienter Programmieren.
Wenn der Trendsteller nicht in all zu großen Gruppen und das Projekt nicht weit fortgeschritten(Leider ist der meiste Code nicht von Compiler zu Compiler portabel, besonders wenns sich um GUI-IDEs handelt) ist, meine ich, dass sich ein Umstieg Lohnt. Deswegen versuche ich stets, solche "Compiler-features" auszunutzen...

Gruss
Speed

Edit: wieso wird Standart Zensiert?
Edit2 : wieso macht er es lowwercase?
Edit3 : @Dravere : wie hast du es hingekriegt?

Einfach richtig schreiben, dann wirst du auch nicht zensiert.

Sind Variadic Templates nicht im C++09-stan**** eingeführt worden?

Witzbold, C++0x ist noch nicht verabschiedet. Wenn alles gut geht, dann können wir den Standard Ende 2011 erwarten. Ja, variadic Templates werden mit sehr hoher Wahrscheinlichkeit drin sein, wüsste jedenfalls nicht, wieso man sie aus dem aktuellen Draft rausnehmen sollte, aber man weiss ja nie

Spee schrieb:

Wenn der Trendsteller nicht in all zu großen Gruppen und das Projekt nicht weit fortgeschritten(Leider ist der meiste Code nicht von Compiler zu Compiler portabel, besonders wenns sich um GUI-IDEs handelt) ist, meine ich, dass sich ein Umstieg Lohnt. Deswegen versuche ich stets, solche "Compiler-features" auszunutzen...

1. Trendsteller? (wahrscheinlich Thread-Ersteller gemeint?)
2. Man kann Code so programmieren, dass er vollkommen protabel ist. Da sind auch GUIs gar kein Problem, man muss sich nur entsprechender Frameworks bedienen.
3. "Compiler-Features" sollte man mit Vorsicht geniessen. Sie machen den Code eben unportabel. Zum Teil sogar zwischen Kompilerversionen des gleichen Herstellers. Der Standard dagegen ändert sich nur sehr selten und bleibt meistens rückwärtskompatibel.
4. Du vergisst irgendwie, dass man beim Wechsel des Kompilers oft auch noch andere Dinge wechseln muss. Zum Beispiel Debugger, Linker, Build-Tools, IDE usw.
Auch sollte man nicht unterschätzen, was man an Know-How verliert, wenn man diese Umstellung durchführt.

Also nur wegen variadic Templates den Kompiler zu wechseln, halte ich für grob verkehrt. In einem kleinen privaten Projekt, mag dies vielleicht noch möglich sein, in einer Firma aber definitiv ein absolutes No-go. Ich würde es aber nicht mal einem privaten empfehlen, nur wegen variadic Templates einen anderen Kompiler zu nehmen, zumal es sowieso noch nicht Standard ist.

Speed schrieb:

Edit: wieso wird stan**** Zensiert?
Edit2 : wieso macht er es lowwercase?
Edit3 : @Dravere : wie hast du es hingekriegt?

Schau mal im Duden nach, wie man Standard schreibt.

Grüssli

Dravere schrieb:

Auch sollte man nicht unterschätzen, was man an Know-How verliert, wenn man diese Umstellung durchführt.

das sollte wohl nicht das problem sein

Die erwarteten Parameter sind wie gesagt variabel und ich kann deshalb nicht einfach einen Vektor nehmen. Und da sie zur Compilezeit feststehen ist das auch gar nicht nötig.

Irgendwie sieht der Code so aus, als ob immer ein PyObject draus wird.

Dravere schrieb:

Auch sollte man nicht unterschätzen, was man an Know-How verliert, wenn man diese Umstellung durchführt.

das sollte wohl nicht das problem sein

Dann bist du der Meinung, dass wenn jemand sehr gut mit dem MSVC Debugger umgehen kann, er sofort auch ohne Probleme mit dem GDB umgehen kann?
Oder wenn er mit VS entwickelt, er sofort auch die Code::Blocks oder KDevelop IDE in und auswendig kennt?
usw.

Mit einem Werkzeug sammelt man Erfahrung, welche man nicht einfach so auf ein anderes Werkzeug übertragen kann. Die Einarbeitung in das andere Werkzeug kostet wieder Zeit, Nerven und Geld. Womöglich hat man dann sogar Werkzeuge zur Hand, welche für die eigentliche Aufgabe völlig ungeeignet sind.
Und das alles nur, weil man variadic Templates wollte

Grüssli

#include <iostream> // Bloß zur Demonstration
#include <string>   // Bloß zur Demonstration

#include <list>
#include <boost/any.hpp>

class foo
{
private:
  std::list<boost::any> args;
  template<typename T> friend foo& operator<<(foo & lhs, T rhs);
public:
  static void execute(){};
}; 

template<typename T> foo& operator<<(foo & lhs, T rhs)
{
  lhs.args.push_back(rhs);
  return lhs;
}

template<> foo& operator<<(foo & lhs, void (*rhs)())
{
  if (rhs==foo::execute)
    { 
      std::cout<<"Funktion aufgerufen mit " << lhs.args.size() << " Parametern.\n";
      unsigned counter=0;
      for(std::list<boost::any>::iterator i = lhs.args.begin();i!=lhs.args.end();++i )
        {
          std::cout<<++counter<<". Parameter hat typeid "<<i->type().name()<<".\n";
          // Hierhin kann Code um auf den Parametertypen zu reagieren
        }
      lhs.args.clear();
    }
  return lhs;
}

foo seppj_out;

int main()
{
  seppj_out<<1<<2<<std::string("Test")<<foo::execute;
  seppj_out<<1.<<2.<<foo::execute;
}

Man fühle sich frei, nach Belieben Templatespezialisierungen, Überladungen oder Fallunterscheidungen hinzuzufügen.

Ausgabe bei GCC(genaue Ausgabe von typeid ist nicht standardisiert):

Funktion aufgerufen mit 3 Parametern.
1. Parameter hat typeid i.
2. Parameter hat typeid i.
3. Parameter hat typeid Ss.
Funktion aufgerufen mit 2 Parametern.
1. Parameter hat typeid d.
2. Parameter hat typeid d.

Was hat boost::any mit der Standardbibliothek zu tun? Und warum machst du so ein komisches Zeugs drum rum?

boost::any hat gar nichts damit zu tun, ich wollte bloß nicht so viel tippen für ein einfaches Beispiel. Das "komische Zeugs" ist der Kern der Idee: Erst füttert man das Funktionsobjekt mit den Parametern, dann führt man die Funktion aus.

Da man in der Praxis wohl kaum mit beliebigen Parameterarten arbeiten wird, würde man in einer echten Umsetzung eher eine Überladung anstatt eines Templates benutzen und einen spezialisierten Container für jeden Argumententyp anstatt eines allgemeinen Containers wie boost::any.

ayayayaaa schrieb:

Was hat boost::any mit der Standardbibliothek zu tun? Und warum machst du so ein komisches Zeugs drum rum?

boost::any hat gar nichts damit zu tun, ich wollte bloß nicht so viel tippen für ein einfaches Beispiel. Das "komische Zeugs" ist der Kern der Idee: Erst füttert man das Funktionsobjekt mit den Parametern, dann führt man die Funktion aus.

der wollte doch nur beliebige argumente übergeben, da hätte eine std::listboost::any args gereicht.