3. Stilfrage: Zuweisungen in if-Klammern

Stilfrage: Zuweisungen in if-Klammern

  • E

    volkard schrieb:

    dann versuche ich zaghaft für die beiden fast identischen dinge eine inlinefunktion
    zu bauen:

    bool findAndEvaluate(Container* cont,Item const& item)
{
	int second=Container->Find(item);
	if(second==-1)
		return false;
	m_QuestManager.Evaluate(&m_Inventory,first,&m_Room->RoomItems,second);
	return true;
}
...
if(findAndEvaluate(&Room->RoomItems,in))
	return m_ID;
if(findAndEvaluate(&Room->Exits,in))
	return m_ID;
cout<<"There is no "<<in<<"!\n";                    
return m_ID;

    oder je nach gusto auch

    if(findAndEvaluate(&Room->RoomItems,in) || findAndEvaluate(&Room->RoomItems,in))
	return m_ID;
cout<<"There is no "<<in<<"!\n";                    
return m_ID;

    hmm, ich finde ehrlich gesagt folgendes lesbarer als deine Idee mit der neuen Inline-Fkt....

    if((second=m_Room->RoomItems.Find(in))!=-1)		//search in RoomItems
		m_QuestManager.Evaluate(&m_Inventory,first,&m_Room->RoomItems,second);
else if((second=m_Room->Exits.Find(in))!=-1)	//search in Exits
	m_QuestManager.Evaluate(&m_Inventory,first,&m_Room->Exits,second);
else											//not found
	cout<<"There is no "<<in<<" in this room!\n";							

	return m_ID;

    Die drei returns waren in der Tat redundant und resultierten aus Cpy&Paste 😉
    Und hier finde ich auch die Zuweisung innerhalb der if-Klammern durchaus sinnvoll. Aber die Idee mit den Zeigern war auch gut. Mal sehen, was sich da machen lässt...
    edit: cpp-Code formatiert

    0
  • ?

    IMHO will man aber meistens nicht auf ein ungültiges x prüfen, sondern darauf ob foo() funktioniert hat oder nicht. Das finde ich viel natürlicher und flüssiger zu lesen.

    Wie ich bereits gesagt habe soll foo eine Ausnahme werfen oder einen gültigen Wert zurück geben und somit stellen sich solche Probleme erst gar nicht.

    0
  • B

    Wenn es sich nicht um eine außergewöhnliche Situation handelt, sollte man auch keine Ausnahme einsetzen.

    0
  • V

    ethereal schrieb:

    Aber die Idee mit den Zeigern war auch gut. Mal sehen, was sich da machen lässt...

    naja, vorteil ist, daß der ungültige zeiger nach false auswertet, was erlaubt:

    if(Bla* bla=find(...))
   tuwas(bla);

    vortiel von integern ist aber die leichte relokierbarkeit der daten. also wenn dein array mal wachsen muss und deswegen woanders platz nimmt, sind alle langlebigen zeiger ins array rein kaputt. die indizes aber sind alle noch ok.
    da könnte man sich noch überlegen, ne klasse Index zu basteln. und der op[] nimmt nicht mehr size_t oder int, sondern Index. Index hat natürliche nen umwandlungkonstruktor von int und size_t, damit normale schleifen auch nch gehen und man keinen unterschied merkt. aber Index könnte nen operator bol haben, der nur bei -1 false ausgibt. also nur im falle von "dieser index ist ungültig".

    0
  • O

    erstmal zu den exceptions: ich bin dagegen, bei jedem funktionsfehlschlag den programmfluss mittels exception zu unterbrechen, stellt euch mal vor,in der std::map würde find ne exception werfen, wenn das element nicht gefunden wurde,anstatt dem üblichen end-iterator. was ich damit sagen will:

    std::map<int,int> a;
try{
    (*a.find(5))=6;
}
catch(std::end& b){//ein typ der die exception auswerfende map liefern kann
    b->map.insert(5,6);
}

    wer sowas gut findet hat echt ein medizinisches problem 😮 .
    disclaimer: etwaige syntax fehler dürfen ausgeschnitten und in ein album geklebt werden, mir wurscht.

    nun zum hauptthema:
    for mit if zu vergleichen ist imho kindisch, weil die beiden strukturen sogut wie garnichts gemeinsam haben. If hat ein anwendungsgebiet, for ein andres, und je nach anwendungsgebiet sind die schreibweisen natürlich anders.
    Im ersten argument einer for schleife würde ich nie einen vergleich schreiben, dafür aber jederzeit eine zuweisung, bei nem if ist es halt genau umgekehrt.

    so nun mal ans problem:

    x=foo()

    das ist uns allen klar, das ist eine zuweisung

    if(foo())

    testet, ob foo() korrekt verläuft

    if(x)

    testet ob der wert von x korrekt ist

    if(!(x = foo()))

    das ist imho nicht eindeutig:
    entweder foo liefert nicht den korrekten wert und die zuweisung läuft gut ab,
    oder die zuweisung versagt
    oder beides ist korrekt.
    auf jedenfall kann man im fehlerfall bei komplexen datentypen nicht davon ausgehen, dass wenn der if block übersprungen wurde, auch foo() versagt hat.
    das programm wäre also, wenn man den fehelrfall in einem elseblock abfangen würde,und nur von fehlern bei foo() ausgeht, nach der bearbeitung im ernstfall in einem inkonsistenten zustand.

    das ist natürlich worst case, aber immerhin ein weiterer punkt,den es zu beachten gilt.

    ps: und wenn ihr jetzt mit exception in der zuweisung kommt: JUHU der perfekte schlangencode

    try{
    if(!(x = foo()){

    //Setzt hier 40 zeilen code ein

    }
    else
    {

    //hier nochmal 20
    }
catch(bad_alloc& a){
    //usw
}

    dagegen ist das schon viel schöner:

    try{
x=foo();
}
catch(bad_alloc& a){
    //JUHU ich kann direkt und übersichtlich direkt auf den fehler reagieren
}
if(x){
    //boah ich komm hier sogar in den if block rein, trotz exception
}
else
{
}
    0
  • B

    Wie kommt ihr eigentlich darauf (ist ja jetzt schon der zweite), dass eine Zuweisung fehlschlagen kann und dann einen symbolischen Ungültig-Wert zurückgibt? Handelsübliche Zuweisungsoperatoren geben *this per Referenz zurück, wie soll das also funktionieren?

    Fehlschlagen eines Zuweisungsoperators ist fast gleichbedeutend mit dem Fehlschlagen eines Konstruktors und sollte durch eine Exception angezeigt werden.

    0
  • O

    lies weiter, da hab ich nochwas zu exceptions geschrieben

    und ja, zuweisungen können jederzeit fehlschlagen, überall dort, wo ein new fehlschlägt,oder sonstwas unvorhergesehenes passiert.
    und es ist fakt, dass man in if(x=foo()!=0) nicht mehr rechtzeitig auf diesen fall reagieren kann, der if block ist vorbei und man hat den salat.

    0
  • B

    Hmm? Eben sagtest du noch, if (!(x=foo()) könne auch so interpretiert werden, dass auf Fehlschlag der Zuweisung geprüft wird. Jetzt widersprichst du dem und wiederholst eigentlich genau was ich gesagt habe. Sinn?

    Fakt ist, dass Fehlschlagen von Zuweisungen nicht so wie oben angezeigt wird, so dass der Code auch nicht mißverstanden werden kann.

    0
  • N

    Bashar schrieb:

    Handelsübliche Zuweisungsoperatoren geben *this per Referenz zurück

    bei einem 'new'. aber sonst geben handelsübliche zuweisungsoperatoren das zurück, was im 'return' -statement steht oder eben der ausdruck rechts vom =.

    Bashar schrieb:

    Fehlschlagen eines Zuweisungsoperators ist fast gleichbedeutend mit dem Fehlschlagen eines Konstruktors und sollte durch eine Exception angezeigt werden.

    gerade wenn man exceptions verwendet, kann eine zuweisung fehlschlagen. beispiel:

    int foo (int a)
{
	if (a == 0)
		throw 1;
	return 0x5678;
}

if (x = foo(0)) 
{  
   ...

    die zuweisung schlägt fehl. ohne 'throw' wär das nicht passiert (es sei denn, die funktion stürzt ab)

    0
  • I

    net schrieb:

    bei einem 'new'.

    ?

    aber sonst geben handelsübliche zuweisungsoperatoren das zurück, was im 'return' -statement steht

    Und das ist nun mal *this

    oder eben der ausdruck rechts vom =.

    ???
    Was gibt das hier wohl zurück:

    Integer i;
i = 2;

    einen int oder einen Integer?

    0
  • O

    falsch, ich hab gesagt, dass man nicht herausbekommen kann, was fehlgeschlagen ist, da ist ein großer unterschied. der rückgabewert von dem op= ist etweder das, was bei foo rauskommt, oder irgendein krummer fehlerwert(natürlich nur, wenn keine exception geworfen wird).

    das beispiel ansich ist verschärft:
    einerseits sollten operatoren im fehlerfall exceptions werfen-soweit sind wir uns einig. Andererseits darf in diesem speziellen fall KEINE exception geworfen werden, weil wir sonst keine chance mehr hätten, an den if block zu kommen. Das exceptionhandling könnte also nicht das leisten, was es eigentlich sollte-und zwar das programm in einem guten zustand zu halten.

    nun haben wir 3 möglichkeiten:
    1.foo() wirft beim fehlschlag auch eine exception,und gibt keinen fehlercode zurück. Bei manchen funktionen klappt das-bei funktionen wie find nicht, weil der fehlschlag dort nicht unbedingt eine ausnahme sein muss. Diese version wäre imho durchführbar,würde aber zu enorm häßlichem und aufgeblähten code führen
    2. es wird weder vom operator noch von foo eine exception geworfen.
    die if abfrage behandelt nur das, was komplett richtig ist, der rest wird zur weiterverarbeitung und aufdröselung in den else teil verschoben.
    Ist eigentlich nur ein c-like exception handling. Manchmal bietets vorteile, manchmal nicht, kommt sehr stark auf die implementation an.

    3. man testet nur x und zieht den rest aus der if abfrage raus. Ok meine favorisierte lösung,man ist was rückgabewerte/exceptions angeht absolut frei, im idealfall kann man das programm normal weiterführen, also ich finds gut^^

    0
  • B

    net: *Mööp* Sie sind raus!

    otze schrieb:

    falsch, ich hab gesagt, dass man nicht herausbekommen kann, was fehlgeschlagen ist, da ist ein großer unterschied. der rückgabewert von dem op= ist etweder das, was bei foo rauskommt, oder irgendein krummer fehlerwert(natürlich nur, wenn keine exception geworfen wird).

    Nein, der Rückgabewert ist nie ein krummer Fehlerwert. Falls ja, soll der Schreiber des op= 20 Stockschläge bekommen.

    das beispiel ansich ist verschärft:
    einerseits sollten operatoren im fehlerfall exceptions werfen-soweit sind wir uns einig. Andererseits darf in diesem speziellen fall KEINE exception geworfen werden, weil wir sonst keine chance mehr hätten, an den if block zu kommen.

    Was wollen wir im if-Block? Wenn die Zuweisung fehlschlägt, ist die Programmausführung in einem fehlerhaften Zustand, der erstmal bereinigt werden muss. Und zwar irgendwo in einem catch, nicht im if.

    Wenn du die Exception lokal behandeln willst, setzt du die Zuweisung halt allein vor die if-Bedingung und schließt sie in try..catch ein. Das ist aber nicht die Regel, normalerweise behandelt man Exceptions nichtlokal.

    0
  • N

    interpreter schrieb:

    net schrieb:

    bei einem 'new'.

    ?

    ach nee, auch nicht. bei einem 'new' bekommt man einen pointer auf das neu erzeugte objekt zurück. aber auch keinen *this.

    interpreter schrieb:

    aber sonst geben handelsübliche zuweisungsoperatoren das zurück, was im 'return' -statement steht

    Und das ist nun mal *this

    int f()
{
   return 1234;
}

    was hat die rückgabe mit *this zu tun?

    interpreter schrieb:

    Was gibt das hier wohl zurück:

    Integer i;
i = 2;

    einen int oder einen Integer?

    schwer zu sagen. was ist 'Integer'? eine klasse? ein typedef? ein #define?
    müsste ein einfacher datentyp sein, wegen der zuweisung mit der 2. aber das = könnte auch ein überladener operator sein... keine ahnung

    0
  • B

    net schrieb:

    ach nee, auch nicht. bei einem 'new' bekommt man einen pointer auf das neu erzeugte objekt zurück. aber auch keinen *this.

    Falls du's nicht gemerkt hast, es geht um Zuweisungsoperatoren und was sie zurückgeben, nicht was new zurückgibt.

    net schrieb:

    int f()
{
   return 1234;
}

    was hat die rückgabe mit *this zu tun?

    Ist das ein Zuweisungsoperator?

    net schrieb:

    keine ahnung

    Stell das erstmal ab, bevor du die Diskussion durcheinander bringst. Sehr fruchtbar ist es jedenfalls nicht, wenn man immer zwischendurch deine Missverständnisse ausbügeln muss.

    0
  • S

    net schrieb:

    int f()
{
   return 1234;
}

    was hat die rückgabe mit *this zu tun?

    In diesem Fall nichts, aber was hat dein Beispiel mit op= zu tun? Ein Zuweisungsoperator, sei es ein Copy oder ein anderer, gibt immer eine Referenz auf sich selbst (=das Objekt) zurück, deshalb sind solche Verkettungen möglich:

    int a = 5, b = 5;
int c = a = b = 2;

    und die dazugehörige Implementierung:

    T& operator=(const T&) { return *this; }
    0
  • N

    Shlo schrieb:

    In diesem Fall nichts, aber was hat dein Beispiel mit op= zu tun?

    da haben wir wohl etwas aneinander vorbei geschrieben 😉

    0
  • O

    Bashar schrieb:

    Wenn du die Exception lokal behandeln willst, setzt du die Zuweisung halt allein vor die if-Bedingung und schließt sie in try..catch ein. Das ist aber nicht die Regel, normalerweise behandelt man Exceptions nichtlokal.

    das sag ich doch die ganze zeit:

    hier zb

    3. man testet nur x und zieht den rest aus der if abfrage raus. Ok meine favorisierte lösung,man ist was rückgabewerte/exceptions angeht absolut frei, im idealfall kann man das programm normal weiterführen, also ich finds gut^^

    oder hier

    dagegen ist das schon viel schöner:

    try{
x=foo(); 
} 
catch(bad_alloc& a){ 
    //JUHU ich kann direkt und übersichtlich direkt auf den fehler reagieren 
} 
if(x){ 
    //boah ich komm hier sogar in den if block rein, trotz exception 
} 
else 
{ 
}

    ansonsten kommts bei mir häufiger vor, dass ich exceptions lokal behandeln muss, und zwar überall dann, wenn ich darauf bestehen muss, dass das programm normal weiterlaufen muss.

    0
  • I

    net schrieb:

    int f()
{
   return 1234;
}

    was hat die rückgabe mit *this zu tun?

    Was hat jetzt diese Funktion mit dem op= zu tun? Der Ass.Op gibt nun mal quasi immer *this zurück.

    Was gibt das hier wohl zurück:

    Integer i;
i = 2;

    einen int oder einen Integer?

    schwer zu sagen. was ist 'Integer'? eine klasse? ein typedef? ein #define?
    müsste ein einfacher datentyp sein, wegen der zuweisung mit der 2. aber das = könnte auch ein überladener operator sein... keine ahnung

    Wir sprechen hier über Zuweisungsoperatoren. Tja, was wird Integer dann wohl sein?

    0
  • D

    Bashar schrieb:

    Wie kommt ihr eigentlich darauf (ist ja jetzt schon der zweite), dass eine Zuweisung fehlschlagen kann

    ich hatte den ersten Einwand von Helium als Witz verstanden, bzgl. der Leute, die der Syntax nicht ganz mächtig sind 😉

    Ob ich nun a = b; if(a) oder if(a=b) schreibe, hat mit Exceptions doch überhaupt rein gar nichts zu tun. Ob eine Funktion einen Fehlercode zurückgibt oder eine Exception wirft, hängt vom Sinn der Funktion ab. Ist ja kein Java hier, wo selbst ein EOF als Exception ankommt.

    Irgendwie ist das hier in die falsche Richtung gedriftet.

    0
  • C

    Irgendwie ist das hier in die falsche Richtung gedriftet.

    Jo. So richtig witzig find ich, dass sobald man in einem Thread das Wort "Stil" auch nur erwähnt, diese Threads immer in biblischen Ausmaßen expandieren.

    Witzig witztig... 🙂

    0
Anmelden zum Antworten