Stilfrage: Zuweisungen in if-Klammern

In diesem Punkt teile ich seine Meinung auch nicht. Ich sehe keinen Vorteil darin? Haben wir wieder eine Zeile Code gespart?
Ich unterstelle ja niemanden, deswegen lauter Fehler zu machen. Aber es reicht ein einziges mal und man kann sich mit nem hässlichen hard-to-find-bug rumplagen. Und was bringt es? Nichts.

Ich kann sowas lesen, wenn jemand unbedingt so programmieren möchte. Aber selber schreibe ich das ausführlich hin.

randa

Jester schrieb:

randa schrieb:

Er argumentiert plausibel und hat recht.

Geiles Argument!

damit Meinte ich, das die Argumente, die Stroustrup gegen einen bestimmten Stil einbringt, einleuchten.

Edit: Hab mich verlesen. Ja, im Stroustrup steht, das eine Deklaration in der if - Anweisung in Ordnung ist.
Jedoch weiß ich das irgendwo stand, das Zuweisungen in Deklarationen missverständlich sein können.

Shlo

randa schrieb:

und du gehörst zu denen:

if (x=(y=z?y==f():z=4)=p++) cout << "Hello World"
else cout << "Verschissen";

Siehst du, ich habe Recht.

net 0

Bashar schrieb:

IMHO hilft es auf lange Sicht ungemein, wenn man seine 'Intuition' der Sprache anpasst...

wozu sind denn die sprachen da? damit man es als mensch leichter hat. man solte es sich und anderen nicht unnötig schwer machen und zu 'obfuscated' coden.
es bringt keinen weiter, wenn man einen c++ -parser im kopf hat und dementsprechen code schreibt. der compiliert zwar fehlerfrei aber kaum einer kann ihn lesen.

Shlo

net schrieb:

allein wegen der gültigkeit von 'i' ist es besser in der for-anweisung aufgehoben

Bei Deklaration in einer if-Anweisung ist es nicht anders:

if (int a = foo())
    //...

Hier möchte ich, dass der Gültigkeitsbereich von a von der Deklarationsstelle bis zum Ende der Bedingung reicht. Anhand deiner Argumentation nehme ich an, dass du in einem solchen Fall lieber sowas schreiben würdest:

{
    int a = foo();

    if (a)
        //...
}

was ich natürlich für Blödsinn halte.

Bashar

net schrieb:

man solte es sich und anderen nicht unnötig schwer machen und zu 'obfuscated' coden.

Zuweisungen in Bedingungen sind aber nicht 'obfuscated', sondern gängige Praxis.

net 0

Shlo schrieb:

{
    int a = foo();

    if (a)
        //...
}
was ich natürlich für Blödsinn halte.

ja, es sieht doof aus aber wär eine alternative wenn man die gültigkeit von 'a' einschränken will. würde ich fast dem 'if (int a=foo())' vorziehen.
(jetzt bin ich bestimmt unten durch bei dir)

Walli

OMG, das machst du hoffentlich nicht konsequent...

{
  int i;
  for(i=0; i!=100; ++i)
    foo(i);
}

Grauenhaft!

Jetzt vergleicht ihr Äpfel mit Birnen. :p

net 0

MaSTaH schrieb:

OMG, das machst du hoffentlich nicht konsequent...
{
  int i;
  for(i=0; i!=100; ++i)
    foo(i);
}

nein, nicht in for-schleifen weil da kann's bei oberflächlicher betrachtung nicht so leicht zu verwechslungen führen (== statt zuweisung). aber das schrieb ich schon irgendwo hier

interpreter

Dass dieser Stil in der Vergangenheit wohl oft zu schwer auffindbaren Fehlern geführt hat, sieht man doch am Design neuer Sprachen. Genau _das_ ist der Grund, warum z.B. in Java oder C# sowas _nicht_ mehr erlaubt ist:
if(i = foo())

randa

Grauenhaft!

Es hat ja auch niemand von der for-Schleife geredet, sondern von if und der verwechslung mit ==.

Vellas

Hi!

interpreter schrieb:

Dass dieser Stil in der Vergangenheit wohl oft zu schwer auffindbaren Fehlern geführt hat, sieht man doch am Design neuer Sprachen. Genau _das_ ist der Grund, warum z.B. in Java oder C# sowas _nicht_ mehr erlaubt ist:
if(i = foo())

In C# ist das sehr wohl noch erlaubt. Allerdings benötigst du anschließend noch einen expliziten Vergleich:

int i;
if((i = foo())!=0) Console.WriteLine("Hello World!");

Code-Hacker

interpreter schrieb:

Dass dieser Stil in der Vergangenheit wohl oft zu schwer auffindbaren Fehlern geführt hat, sieht man doch am Design neuer Sprachen. Genau _das_ ist der Grund, warum z.B. in Java oder C# sowas _nicht_ mehr erlaubt ist:
if(i = foo())

Ich kann mich jetzt täuschen, aber ich glaube, es ist immer noch erlaubt, wenn man ein bool zuweist. Es wird nur kein Pointer oder ein int implizit in ein bool konvertiert, zum Glück.

volkard

ethereal schrieb:

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

wohingegen bei der ersten Möglichkeit alle ifs/elses schön auf eine Ebene liegen.
Was zieht man da vor?

was für ne frage?
da kannste genausogut anhand von zerbies code nachweisen, daß oo nix taugt oder anhand
von camarcks code nachweisen, daß goto gut ist.
also erstmal überlege ich, welchen sinn es macht, daß return m_ID dreimal da steht.

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<<"!\n";                    
}
return m_ID;

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;

aber die short-cirquit-auswertung in so seiteneffektigen aufrufen zu verwenden,
finde ich nicht fein.
oder

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

da hat man ja furchtbar viele möglichkeiten. man sollte sich überlegen, ob die -1 eine
gute wahl war, um anzuzeigen, daß da nix gefunden wurde. warum wurden keine zeiger
verwandt?

merke: gute spieleprogrammierer haben keinen stil.

Bashar

interpreter schrieb:

Dass dieser Stil in der Vergangenheit wohl oft zu schwer auffindbaren Fehlern geführt hat, sieht man doch am Design neuer Sprachen. Genau _das_ ist der Grund, warum z.B. in Java oder C# sowas _nicht_ mehr erlaubt ist:
if(i = foo())

Ist das per se nicht erlaubt, oder ist es nicht erlaubt weil es keine implizite int-nach-boolean-Konvertierung gibt?

Ansonsten würde ich Java/C# nicht unbedingt als Maßstab nehmen ... die Designentscheidungen in diesen Sprachen wurden maßgeblich von Überlegungen, wie man möglichst viele Anfänger und Manager von sich überzeugt, geprägt.

Vellas

Hi!

Bashar schrieb:

Ist das per se nicht erlaubt, oder ist es nicht erlaubt weil es keine implizite int-nach-boolean-Konvertierung gibt?

So wie er es geschrieben hat ist es nicht erlaubt, da hier eine <Typ> nach boolean-Konvertierung stattfand. In C# muss immer explizit mit einem Wert verglichen werden, sofern es sich nicht um den Typ bool handelt, da geht dann sehr wohl dies:

bool richtig = true;
if(richtig) Console.WriteLine("Richtig");
else Console.WriteLine("Falsch");

Code-Hacker

Bashar

Also dann: Wer unbedingt will, dass die Zuweisung eine Anweisung und kein Ausdruck ist, kann sich ja mal im Pascal-Lager(+Ada, +Eiffel) umsehen.

DrGreenthumb

Bei

if(!(x = foo()) ...

lese ich, "Wenn foo() nicht funktioniert, mach dies und das". Gut.
Wenn dort aber steht

x = foo();

if(!x) ...

muss ich viel mehr denken. Erstmal wird x der Rückgabewert von foo() zugewiesen. Dann erst sehe ich, dass x evtl. ungültig sein kann und darauf reagiert wird.

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.

Helium

Bei

if(!(x = foo()) ...

lese ich, "Wenn foo() nicht funktioniert, mach dies und das". Gut.

Vielleicht lesen andere daraus: Wenn die zuweisung an x nicht funktioniert.