Optionale Parameter?

MFK

Optionator schrieb:

Ich will, dass der Benutzer alle Parameter (die alle einen FESTEN TYPEN haben) der Funktion durchgeht und sich fuer jeden einzelnen ueberlegt, ob er ihn setzen will oder nicht.

Wenn jemand ernsthaft dazu gezwungen ist, mit diesem API zu arbeiten (und denjenigen bedaure ich jetzt schon), wirst du damit rechnen müssen, dass er sich einen flexibleren und benutzerfreundlicheren Wrapper drumherum bastelt. Ich jedenfalls würde das tun.

SeppJ

Optionator schrieb:

Bei einer Ellipse sieht er nicht mal Typen und kann 3 Billionen Parameter irgend eines Typs uebergeben. Aber ICH bin stur, ne?

Gerade bei einer Ellipse muss er sich doch Gedanken machen, eben WEIL so viel schiefgehen kann. Da in der Schnittstelle selbst keine Hilfestellung zu finden ist, muss schließlich genau dokumentiert sein, welche Parameter in welcher Reihenfolge kommen und man muss ständig die Anleitung daneben liegen haben.

Wobei ich es genau deshalb eben nicht nehmen würde. Aber ich verstehe einfach nicht, wie du nicht sehen kannst, dass dies genau das ist was du beschreibst.

Mit dieser "API" arbeiten wir intern und wir wollen das so. Das brauch ich jetzt nicht gross erlaeutern, da ihr den kompletten Kontext sowieso nicht kennt.

@BigNeal: Das "Problem" ist doch offensichtlich. Ein foo(ON, 2, OFF, OFF, OFF, ON. 33.3f) waere deutlich schoener als ein foo(ON, 2, OFF, "", OFF, 0.0f, OFF, 0, ON, 33.3f);

Wenn ich sowas vorgesetzt bekomme, dann sind die einzigen Gedanken die ich mir mache, dort überall no rein zu schreiben, um das Standardverhalten zu bekommen, welches ich auch ohne unnötige Parameter erwarten würde. Wenn mir das Standardverhalten nicht zusagt, muss ich auf jeden Fall in die Doku schauen und die interessanten Parameter raus suchen und entsprechend setzten. Auch hier stört mich das ewige no, no, no eher, als das es etwas bringen würde. Kurzum entweder ich will einen Parameter verändern, dann mache ich dass selbstständig oder nicht, dann interessiert mich auch nicht die Liste. Wenn die Parameter zur Ausführung notwendig sind, dann kannst du das auch vorher abtesten, ob alle gesetzt wurden. Den Anwender aber zu zwingen sich mit Optionen auseinander zu setzten, die ihn gar nicht interessieren, macht keinen Sinn.
Übrigens ist die Variante nicht nur nervig, sondern auch extrem Fehleranfällig. Weil du Parameter gleichen Typs leicht an die falsche Stelle schreiben kannst.

MFK

Optionator schrieb:

Mit dieser "API" arbeiten wir intern und wir wollen das so.

Was macht ihr denn, wenn man erst zur Laufzeit weiß, ob man einen Parameter setzen will? Ist man dann zu einem

if(willsetzen)
   aufruf
else
   aufruf_mit_anderer_signatur_weil_1_parameter_weniger

gezwungen? Oder ist das nur für den interaktiven Einsatz gedacht?

Optionator schrieb:

Ein foo(ON, 2, OFF, OFF, OFF, ON. 33.3f) waere deutlich schoener als ein foo(ON, 2, OFF, "", OFF, 0.0f, OFF, 0, ON, 33.3f);

Wenn du das wirklich schön findest, dann mach es doch einfach mit Überladung. Du brauchst dann eben 2^n Überladungen für n Parameter. Aber eine fiese Schnittstelle sollte auch fies zu inplementieren sein.

Paul Müller schrieb:

Wenn ich sowas vorgesetzt bekomme, dann sind die einzigen Gedanken die ich mir mache, dort überall no rein zu schreiben, um das Standardverhalten zu bekommen, welches ich auch ohne unnötige Parameter erwarten würde. Wenn mir das Standardverhalten nicht zusagt, muss ich auf jeden Fall in die Doku schauen und die interessanten Parameter raus suchen und entsprechend setzten. Auch hier stört mich das ewige no, no, no eher, als das es etwas bringen würde. Kurzum entweder ich will einen Parameter verändern, dann mache ich dass selbstständig oder nicht, dann interessiert mich auch nicht die Liste. Wenn die Parameter zur Ausführung notwendig sind, dann kannst du das auch vorher abtesten, ob alle gesetzt wurden. Den Anwender aber zu zwingen sich mit Optionen auseinander zu setzten, die ihn gar nicht interessieren, macht keinen Sinn.
Übrigens ist die Variante nicht nur nervig, sondern auch extrem Fehleranfällig. Weil du Parameter gleichen Typs leicht an die falsche Stelle schreiben kannst.

Es ist genau das Gegenteil der Fall. Im Moment haben wir staendig Fehler, weil sich Entwickler zu wenig Gedanken ueber Pipeline States machen. Drum haben wir uns entschiedene eine OPTIONALE Hilfsfunktion anzubieten, mit der man die wichtigsten States setzen kann. Dies dient nur dazu die ewig auftretenden Fluechtigkeitsfehler zu vermeiden, im dem sich jeder Entwickler genau ueberlegt, welchen Zustand bestimmte wichtige States haben sollen.

Is mir schon oft in diesem Forum aufgefallen, dass immer gleich ein paar Superkluge (so sehen sie sich zumindest selber) daherkommen und meinen sie muessten einen belehren und sagen was gut ist und nicht. Obwohl sie meistens keinerlei Ahnung von den eigentlichen Gruenden haben. Es gibt nicht nur ON und OFF etc. In Wirklichkeit ist es deutlich komplexer, aber ich habe es eben auf den KERN des Problems vereinfacht. Spart euch in Zukunft vielleicht mal die Metatipps und ewigen Belehrungen und versucht einfach nur die FRAGE an sich zu beantworten.

SeppJ

Optionator schrieb:

Is mir schon oft in diesem Forum aufgefallen, dass immer gleich ein paar Superkluge (so sehen sie sich zumindest selber) daherkommen und meinen sie muessten einen belehren und sagen was gut ist und nicht. Obwohl sie meistens keinerlei Ahnung von den eigentlichen Gruenden haben. Es gibt nicht nur ON und OFF etc. In Wirklichkeit ist es deutlich komplexer, aber ich habe es eben auf den KERN des Problems vereinfacht. Spart euch in Zukunft vielleicht mal die Metatipps und ewigen Belehrungen und versucht einfach nur die FRAGE an sich zu beantworten.

Lieber nicht. Es ist mir schon oft in diesem Forum aufgefallen, dass immer jemand nach einer ganz genauen Lösung sucht die Sie für die einzig mögliche halten. Obwohl sie meistens keinerlei Ahnung von den verfügbaren Sprachmitteln haben. Die wenigen Fälle, die tatsächlich mal genau diese eine Lösung suchen, können auch mit ein paar Metatipps leben.

Caligulaminus

Also ich würde Ellipse sagen...

Etwa so:

foo(bool b, ...)
{
	va_list va;
	va_start(va, b);
	if(b)
		float1=va_arg(va, float);
	if(va_arg(va, bool))
		int1=va_arg(va, int);
	if(va_arg(va, [s]float[/s]bool))
		float2=va_arg(va, float);
	/* ..... */
	va_end(va);
}

Oder halt in 'ne Schleife...

Shade Of Mine

Optionator schrieb:

Im Moment haben wir staendig Fehler, weil sich Entwickler zu wenig Gedanken ueber Pipeline States machen. Drum haben wir uns entschiedene eine OPTIONALE Hilfsfunktion anzubieten, mit der man die wichtigsten States setzen kann.

Schreit nach einem simplen Config-Objekt.
Wozu muss ich OFF setzen? Ich setze nur die Sachen die ich brauche, alles andere ist OFF. Siehe Tachyons Post auf Seite 2.

Dein Ansatz ist einfach falsch. Deshalb sind alle Lösungen nur krüppelig.

nurf

Shade Of Mine schrieb:

Optionator schrieb:

Im Moment haben wir staendig Fehler, weil sich Entwickler zu wenig Gedanken ueber Pipeline States machen. Drum haben wir uns entschiedene eine OPTIONALE Hilfsfunktion anzubieten, mit der man die wichtigsten States setzen kann.

Schreit nach einem simplen Config-Objekt.
Wozu muss ich OFF setzen? Ich setze nur die Sachen die ich brauche, alles andere ist OFF. Siehe Tachyons Post auf Seite 2.

Dein Ansatz ist einfach falsch. Deshalb sind alle Lösungen nur krüppelig.

Mr. Optionator tritt hier anonym auf und trollt rum.
Sieht mir fast so aus wie die 1000. Kiddie-Grafik-Engine, die im Endeffekt eine einzige Krüppelei zu sein scheint.

DocShoe

Muss es unbeding eine Funktion sein? Geht nicht vielleicht ein Function Object, das die entsprechenden Parameter als member besitzt und nur den operator() überlädt?

Als Nonsens Lösung könnte ich noch

std::map<std::string, boost::any>

vorschlagen, fehlt noch in der Sammlung

hustbaer

struct OptionalStatesSet
{
    boost::optional<temperature> temp;
    boost::optional<temperature> temp2;
    boost::optional<int> blah;
    boost::optional<foo> blubb;
    boost::optional<bar> blobber;
    // ...
};

void SetSomeStates(OptionalStatesSet const& states);

void Foo()
{
    OptionalStatesSet states;
    states.temp = 123;
    states.temp2 = 10000;
    SetSomeStates(states);
}

So.
Zwingt natürlich auch niemanden sich über sämtliche Member in "OptionalStatesSet" Gedanken zu machen. Dafür hat man aber ne schöne Übersicht was es alles für States gibt, wo man sehr schnell nachsehen kann. Wenn man das will. Und wenn man nicht will schreibt man sowieso scheiss Code.
Was ich an der Variante gut finde: man sieht beim Aufruf wie der Wert heisst, und nicht nur an welcher Stelle einer Parameterliste er steht.

Ansonsten:

void SetSomeStates(boost::optional<int> const& s1, boost::optional<int> const& s2 /* uswusf */);

Das Dumme an der Lösung ist jetzt wieder, dass man beim Aufruf einen Haufen Zahlen/Werte stehen hat, ohne dass dabei ersichtlich ist was sie bedeuten. Je mehr Werte, desto schlimmer. Parameter durchzählen wird ab spätestens 5-6 Parametern *sehr* lästig.

Jetzt kannst du dir aussuchen von welcher Variante du annimmst dass sie zu weniger Fehlern/Aufwand/... führen wird.

Ich würde in den meisten Fällen die Variante mit der struct vorziehen.

Jockelx

Die struct-Lösung hätte ich auch vorgeschlagen, nur wieso sind deine Member boost::optional?

Edit: Ach so, schon gut, er will keine default-Werte, sondern wissen ob was gesetzt wurde.

Shade Of Mine

hustbaer schrieb:

Zwingt natürlich auch niemanden sich über sämtliche Member in "OptionalStatesSet" Gedanken zu machen.

Laesst sich easy zur runtime checken und asserten.

hustbaer

Shade Of Mine schrieb:

hustbaer schrieb:

Zwingt natürlich auch niemanden sich über sämtliche Member in "OptionalStatesSet" Gedanken zu machen.

Laesst sich easy zur runtime checken und asserten.

Naja "easy" ist Ansichtssache. Es geht auf jeden Fall nicht mehr mit einfach nur boost::optional .

Er möchte ja erlauben dass bestimmte Werte nicht gesetzt werden. Er will nur dass der Programmierer "gezwungen" wird sich darüber Gedanken zu machen welche Werte er nun setzen soll und welche nicht.

Natürlich geht es trotzdem, aber eben wie gesagt nicht direkt mit boost::optional . Man müsste eine eigene Klasse machen die einerseits "optional" (nullable) Semantik hat und sich zusätzlich merkt ob sie jemals zugewiesen wurde. Ist natürlich alles keine Hexerei, aber wie gesagt: "easy" ist Ansichtssache

314159265358979

Wie schon gesagt wurde, dein Vorhaben ist Schwachsinn.

nurf schrieb:

Shade Of Mine schrieb:

Optionator schrieb:

Im Moment haben wir staendig Fehler, weil sich Entwickler zu wenig Gedanken ueber Pipeline States machen. Drum haben wir uns entschiedene eine OPTIONALE Hilfsfunktion anzubieten, mit der man die wichtigsten States setzen kann.

Schreit nach einem simplen Config-Objekt.
Wozu muss ich OFF setzen? Ich setze nur die Sachen die ich brauche, alles andere ist OFF. Siehe Tachyons Post auf Seite 2.

Dein Ansatz ist einfach falsch. Deshalb sind alle Lösungen nur krüppelig.

Mr. Optionator tritt hier anonym auf und trollt rum.
Sieht mir fast so aus wie die 1000. Kiddie-Grafik-Engine, die im Endeffekt eine einzige Krüppelei zu sein scheint.

Sagt das Kiddie, das im Profil zu seinem Billigspiel verlinkt. Welch Ironie

Habs mittlerweile mit optional geloest. Klappt wunderbar und ich hab genau das, was ich wollte. Endlich muss man ueber alle wichtigen Params nachdenken.

Schon lustig, wie viele Leute mit Null Ahnung sich hier als Design Gurus aufspielen.

hustbaer

Optionator schrieb:

Habs mittlerweile mit optional geloest. Klappt wunderbar und ich hab genau das, was ich wollte. Endlich muss man ueber alle wichtigen Params nachdenken.

ROFL
Ja, wennst glaubst...

Schon lustig, wie viele Leute mit Null Ahnung sich hier als Design Gurus aufspielen.

Mhm

Tachyon

hustbaer schrieb:

[...]

Lass Dich doch nicht auf sein Niveau herab. Dazu ab besten folgende Regel: Diskutiere nicht mit Idioten... Sie ziehen dich auf ihr Niveau herunter und schlagen dich dort mit Erfahrung!

Tachyon schrieb:

hustbaer schrieb:

[...]

Lass Dich doch nicht auf sein Niveau herab. Dazu ab besten folgende Regel: Diskutiere nicht mit Idioten... Sie ziehen dich auf ihr Niveau herunter und schlagen dich dort mit Erfahrung!

Wie wahr.
Noch schlimmer sind eigentlich nur Idioten, die meinen sie wuessten alles und muessten andere staendig belehren. Obwohl sie keinerlei Ahnung vom Kontext haben.