Kontrollstruktur unless?
-
so, da ich im prinzip die diskussion aufflammen habe lassen, und seit meinem posting im prinzip nicht mehr viel neues außer beleidigungen gekommen sind, hier wieder ein versuch, das wörterwerfen wieder durch eine diskussion zu ersetzen. ist ja alles halb so schlimm.
Vevusio schrieb:
außerdem hab ich gesagt das unless macro wäre nur dann gerechtfertigt wenn man es wirklich oft benutzen muss aus irgend einem grund in einem programmbereich
#define int main{...
#define ..was du geschrieben hast, wir müssen anscheinend eine andere auffassung von oft haben weil ich ein "int main(int argc...)" nicht sonderlich oft in einem programm drin stehen habe
natürlich war das nur ein beispiel, dass man mit dem präprozessor im prinzip sehr viel für menschen verständlicher machen kann. nur stellte ich damit die frage in den raum, für wen was wie verständlich ist. für jemanden, der nicht programmiert, wären solche makros sehr wohl verständlich. für jemanden, der jedes geschwungene klammernpaar durch ein begin und ersetzen will, wäre das verständlich. kurz: was verständlich ist, hängt davon ab, für wen. mehr bedeutet die aussage zunächst nicht.
aus rein praktischen gründen ist es allerdings verständlicher, als C++ programmierer anzunehmen, dass was immer ich programmiere, von einem C++ programmierer gelesen wird.
hier habe ich mit einem nicht ganz korrekten umkehrschluss vielleicht für verwirrung gesorgt:
if(highJump) versteht man nicht als gelehrter c++ programmierer, das versteht man als egalwas programmierer und auch als nicht programmierer
es ging nicht darum die syntax zu verstehen sondern die logik, es möglichst einfach zu machen über den code zu lesen
ich stimme dir vollkommen zu. es geht nicht darum, dass ein C++ programmierer etwas verstehen soll, sondern darum, dass ein C++ programmierer zuviel versteht. in wahrheit also einigt man sich auf einem coding-standard (den sprachstandard) nicht, um etwas zu verstehen, sondern um bestimmte bedeutungen ausschließen zu können (am ende bleibt im günstigen fall eine übrig). wenn ich als C++ programmierer (und ich schreibe ja für C++ programmierer) ein konstrukt lese wie "unless", dann verstehe ich das zwar, aber darum geht es nicht: es bedeutet mehr als nur "unless", denn ich weiß, was sich dahinter alles verbergen kann: eine funktion, ein makro, und was sich hinter einem makro verbergen kann, das kann ich nicht einmal dann mit sicherheit sagen, wenn ich das makro sehe, weil es immer überschrieben werden kann. das ist einfach ein zuviel an bedeutung, und dieses zuviel wird in anderen fällen durch eine wohldefinierte (standard-)bedeutung reduziert. if ist immer if und nie ein makro, nie eine funktion, nie irgendetwas, das ich nicht verstehe.
muss nicht unter umständen verständlich sein, aber wenn man es auf if(canJump) runterbricht weiss man in dem if ist irgend eine jumping behandlung (ob da jetzt character.Jump() oder sonst was drinsteht was darauf auch hinweisen würde oder ein kommentar zusätzlich zu dem if, das ist wieder was anderes)
und auch wenn sich if(!highGravity) von selbst erklärt muss man kurz dort anhalten und "äh wenn gravity nicht true ist geht er in das if hinein. hm hm", es ist nichts weltbewegendes aber macht den code ein klein wenig schwerer lesbar
und spätestens bei
if(!noCollisionFound && !(highGravity || !staminaNotEmpty))
so nen ausdruck wenn man keine eindeutigen hinweise hat worauf man abfragt eigentlich zu knacken ist richtig scheiße, auch wenn er sich natürlich "von selbst erklärt", ist ja einfache aussagenlogik, aber trotzdem wäre eine hilfsvariable nötig
natürlich. vielleicht habe ich es nicht klar genug gesagt, aber in dem punkt, vorhandene sprachmittel zum herunterbrechen und verständlich-machen (im rahmen eines bestimmten bezugssystems) zu nutzen, stimme ich dir voll und ganz zu.
-
Tachyon schrieb:
Eine ulkige Aussage im Hinblick darauf, dass Du in Deinen gesamten Ergüssen hier NUR Aussagen triffst ohne jemals Argumente dazu zu liefern.
Dir ist glaube ich echt nicht mehr zu helfen.
-
So. Das ganze ist ja ein richtiger Flamewar geworden.
Egal, ich stelle mich mal (komplett?) auf die Seite von 'f, und führe folgendes Argument an: BOOST_FOREACH.
PS: Ich gelande zum Eindruck, dass einige der Poster hier das Wissen von 'f extrem unterschätzen und dadurch vorschnelle Schlüsse ziehen.
-
Tachyon schrieb:
Da haben die Entwickler die Contraint- und Type-Checks des Compilers abgeschaltet.
Wo hast du denn das her?
-
Bashar schrieb:
Tachyon schrieb:
Da haben die Entwickler die Contraint- und Type-Checks des Compilers abgeschaltet.
Wo hast du denn das her?
Jo, stimmt, in der Form Blödsinn. Die haben die auftretenden Exceptions nicht behandelt.
boost::BOOST_FOREACH wird ziemlich sicher nicht seinen Weg in C++0x finden. Zumindest nicht in der Form. Dafür wird es wohl ein echtes Keyword bekommen.
-
Bashar schrieb:
Tachyon schrieb:
Da haben die Entwickler die Contraint- und Type-Checks des Compilers abgeschaltet.
Wo hast du denn das her?
Weiß nicht wo er das herhat, aber um das zu korrigieren: Es wurden vielmehr die Laufzeitüberprüfungen abgeschaltet, was zu einem unbemerkten Überlauf führte.
-
Tachyon schrieb:
Bashar schrieb:
Tachyon schrieb:
Da haben die Entwickler die Contraint- und Type-Checks des Compilers abgeschaltet.
Wo hast du denn das her?
boost::BOOST_FOREACH wird ziemlich sicher nicht seinen Weg in C++0x finden. … Dafür wird es wohl ein echtes Keyword bekommen.
I rest my case.
'f, wir haben uns ein Bier verdient.
(Abgesehen davon möchte ich noch zu Protokoll geben, dass ich 'unless' auch nicht mag. Aber die Argumentation, die hier dagegen geführt wurde, war echt daneben.)
-
FOR_EACH wird ziemlich sicher nicht seinen Weg in C++0x finden
weil es in C++0x ein for für ranges gibt (wie ein for-each), das im prinzip rein als textersetzung implementiert werden kann.
Konrad Rudolph schrieb:
Egal, ich stelle mich mal (komplett?) auf die Seite von 'f, und führe folgendes Argument an: BOOST_FOREACH.
es ging ja ursprünglich um das unless. natürlich ist die argumentation nicht hart, wenn ich schon schreibe:
me, myself schrieb:
vielleicht habe ich es nicht klar genug gesagt, aber in dem punkt, vorhandene sprachmittel zum herunterbrechen und verständlich-machen (im rahmen eines bestimmten bezugssystems) zu nutzen, stimme ich dir voll und ganz zu.
da muss man eben abwägen. ich persönlich finde BOOST_FOREACH zwar nicht ganz so hübsch, aber gerechtfertigt, wenn man sich die alternative ansieht. in c++0x wird das ganze sowieso auf eine (ähnliche) elegante weise gelöst.
das liefert aber keine begründung dafür, z.b. unless zu definieren (und wenn, dann höchstens UNLESS) - oder andere, seltsame konstrukte, wie BEGIN und END über makros einzuführen.
das eine ist eine frage des geschmacks, das andere eine frage der sinnhaftigkeit.
-
queer_boy schrieb:
ich persönlich finde BOOST_FOREACH zwar nicht ganz so hübsch, aber gerechtfertigt, wenn man sich die alternative ansieht. in c++0x wird das ganze sowieso auf eine (ähnliche) elegante weise gelöst.
das liefert aber keine begründung dafür, z.b. unless zu definieren (und wenn, dann höchstens UNLESS) - oder andere, seltsame konstrukte, wie BEGIN und END über makros einzuführen.
Nö. In der Doku von Boost.Foreach wird explizit auf die Möglichkeit hingewiesen, in eigenen Quelldateien folgende Definition einzuführen:
#define foreach BOOST_FOREACHVerwende ich am laufenden Band.
das eine ist eine frage des geschmacks
Programmierer führen mir zu oft „Geschmack“ als Argument an. Programmieren ist in erster Linie eine Technik/Wissenschaft und keine Kunst. „Geschmack“ ist meist nur ein Mangel empirischer Daten.
Abgesehen davon muss man natürlich Vor- und Nachteile abwägen und an diesem Punkt würde ich 'unless' eben auch durchfallen lassen (anders als 'foreach'), weil es quasi keinen Nutzen bringt. Ich bezweifle stark, dass 'unless(x)' gegenüber 'if (not x)' auch nur den geringsten Lesbarkeitsvorteil bringt. Neue Sprachmittel einzuführen sollte man schon gut begründen können.
-
Konrad Rudolph schrieb:
Ich bezweifle stark, dass 'unless(x)' gegenüber 'if (not x)' auch nur den geringsten Lesbarkeitsvorteil bringt.
meiner meinung nach eher das gegenteil. ich würde jedes mal "WTF?" denken. ist auch eine sache der gewohnheit.
makros sollten wirklich nicht als ersatz für schlüsselwörter herhalten. ich hatte mal den fall, dass jemand "elif" als "else if" definierte. hat keinen spaß gemacht damit zu arbeiten.
-
ich meinte: ich finde BOOST_FOREACH nicht so hübsch (denn das ganze ist trotzdem nur ein hack, das fehlende sprachfunktionalität ersetzt) - explizit im vergleich zu C++09s for(each). du kannst hier sagen, dass du foreach hübsch genug findest, um es zu verwenden (und wenn es bloß deinen code kürzer macht). die gründe sind zwar praktische, aber letzten endes ist genau das geschmackssache. ist ja nicht so, dass man das nicht begründen kann; nur darüber zu streiten löst einen flamewar aus.
-
Tachyon schrieb:
Bashar schrieb:
Tachyon schrieb:
Da haben die Entwickler die Contraint- und Type-Checks des Compilers abgeschaltet.
Wo hast du denn das her?
Jo, stimmt, in der Form Blödsinn. Die haben die auftretenden Exceptions nicht behandelt.
Wenn ich den Link, den du gegeben hast, richtig interpretiere, wurde die Exception sehr wohl behandelt. Leider durch Einleitung der Selbstzerstörung.