Kontrollstruktur unless?

[Tachyon]

'f schrieb:

Tachyon schrieb:

Es gibt genügend Gründe dafür, dass ist Sprachen, in denen es um hohe Betriebssicherheit der Software geht, komplett auf einen Präprozessor verzichtet wird.

Haha, hast du gerade C++ mit hoher Betriebssicherheit in Verbindung gebracht?

Ich sagte, solche Sprachen verzeichten komplett auf einen Präprozessor und führte Ada an. Verzichtet C++ auf einen Präprozessor? Ich denke nicht. Lesen hilft verstehen.

'f schrieb:

Tachyon schrieb:

Und in C++ wurden Templates und inline Funktionen bestimmt auch nur so aus Spaß eingeführt.

Templates und inline Funktionen decken alle Einsatzmöglichkeiten von Makros ab?

Unter C++ leider nicht, da z.B. Interfaces nicht über einen entsprechenden Mechanismus eingefügt werden, sondern durch textuelle Ersetzung (#include).
Es ging aber auch nicht um alle Einsatzmöglichkeiten, sondern um das völlig überflüssige definieren von redundanten pseudo Schlüsselwörtern.

'f schrieb:

Tachyon schrieb:

Man man man, wenn ihr Euch eine eigene Programmiersprache bauen wollt, dann macht das von Grund auf, aber missbraucht nicht den C-Präprozessor dafür.

Inwieweit unterscheidet sich unless denn von selber definierten Funktionen, Typen, etc.?

Btw, was wäre denn deiner Meinung nach kein Missbrauch des CPP?

Dir ist offensichtlich nichtmal der Unterschied zwischen Daten, Funktionen und Kontrollstrukturen bewusst.
Unless wäre eine selbst definierte Kontrollstruktur, die mit textueller Ersetzung etwas nachbildet, dass sich ohne weiteres auch mit if direkt im Code, verständlich für jeden der die Sprache kennt, implementieren lässt.
Man kann hier natürlich gerne als unregistrierter Unwissender auf irgendwelchen Leuten rumbashen, aber vielleicht solltest Du mal ein paar Bücher z.B. von Bjarne Stroustrup oder Scott Meyers lesen, bevor Du hier mit Deiner grandiosen Unwissenheit glänzt. Das Nachbilden von Kontrollstrukturen kommt in der Regel von irgendwelchen Leuten, die von einer anderen Programmiersprache her kommen, und meinen ein bestimmtes Schlüsselwort (aus der alten Sprache) wäre unbedingt erforderlich (in der Regel um irgendwelchen Code 1:1 portieren zu können) anstatt sich mit der Sprache auseinanderzusetzen und etwas vernünftiges zu generieren. Solche Leute sind leider hoffnungslose Anachronisten.

[asc]

'f schrieb:

Haha, hast du gerade C++ mit hoher Betriebssicherheit in Verbindung gebracht?

Sauber geschriebener C++ Code hat auch eine hohe Betriebssicherheit. Und schlecht geschriebene Software mag von der ein oder anderen Sprache etwas abgefangen werden, wenn ich mir aber z.B. die Abstürze diverser Anwendungen ansehe hat Betriebssicherheit nichts, aber auch garnichts mit der Sprache zu tun (ob nun C++, VB, C#, Java, ...).

Ich hoffe dir ist überhaupt bewusst wieviel Software in C++ geschrieben wurden ist (und wie alltäglich man mit dieser in Einsatz kommt).

'f schrieb:

Templates und inline Funktionen decken alle Einsatzmöglichkeiten von Makros ab?

Nein, aber fast alle sinnvollen.

'f schrieb:

Inwieweit unterscheidet sich unless denn von selber definierten Funktionen, Typen, etc.?

Ich würde sagen es macht grundsätzlich keinen Sinn in einer Sprache weitere Befehle mit Makros nachzubauen, da man den Code schlechter lesbar macht. Manche mögen "unless" als sinnvoll erachten, ich halte es eher für "useless", da man effektiv wie bei der Ungarischen Notation eine neue Sprache lernen muss.

Und der Vergleich mit Funktionen, eigenen Typen und Makros ist hinfällig: Makros sind kein direktes Sprachmittel und werden nicht so unterstützt wie ersteres. Mit eigenen Funktionen und eigenen Typen schafft man nicht noch nette Nebeneffekte wie das gerne von mir angeführte max-Makro (z.B. in windows.h) wenn man nichttriviale und auswertbare ausdrücke diesem Makro übergibt.

'f schrieb:

Btw, was wäre denn deiner Meinung nach kein Missbrauch des CPP?

Verwendung der C++ Sprachmittel, Vermeidung des Präprozessor wo er nicht (wie bei Include) unbedingt notwendig ist.

cu André
P.S: @Tachyon war keine Absicht

[Tachyon]

asc schrieb:

Tachyon schrieb

Puh, ich habe das nicht geschrieben. Bitte ändern.

['f]

Tachyon schrieb:

Ich sagte, solche Sprachen verzeichten komplett auf einen Präprozessor und führte Ada an. Verzichtet C++ auf einen Präprozessor? Ich denke nicht. Lesen hilft verstehen.

Dann solltest du vielleicht mal die Relevanz deines Einschubs erklären. Oder willst du auch Pointer, Arrays, praktisch alles was sich in C++ finden lässt verbieten weil man damit Schindluder treiben kann?

Tachyon schrieb:

Unter C++ leider nicht, da z.B. Interfaces nicht über einen entsprechenden Mechanismus eingefügt werden, sondern durch textuelle Ersetzung (#include).

Tja, dann muss man wohl auf solche Hacks verzichten und einfach alles in eine Quellcodedatei packen, hm?

Tachyon schrieb:

Es ging aber auch nicht um alle Einsatzmöglichkeiten, sondern um das völlig überflüssige definieren von redundanten pseudo Schlüsselwörtern.

Es ging auch um Makros allgemein. Und was meinst du denn mit "redundanten pseudo Schlüsselwörtern"?

Wenn du meinst dass unless redundant ist, sollten wir dann nicht while[c] und [c]do ... while meiden und uns komplett auf for konzentrieren? Oder besser noch alles mit if und goto regeln?

Tachyon schrieb:

Dir ist offensichtlich nichtmal der Unterschied zwischen Daten, Funktionen und Kontrollstrukturen bewusst.

Wer im Glashaus sitzt, sollte Typen nicht mit Daten gleichsetzen.

Tachyon schrieb:

Unless wäre eine selbst definierte Kontrollstruktur, die mit textueller Ersetzung etwas nachbildet, dass sich ohne weiteres auch mit if direkt im Code, verständlich für jeden der die Sprache kennt, implementieren lässt.

Selbst definierte Datentypen, Funktionen, Templates, etc., lassen sich auch direkt im Code, verständlich für jeden der die Sprache kennt, implementieren. Und nun?

Tachyon schrieb:

Man kann hier natürlich gerne als unregistrierter Unwissender auf irgendwelchen Leuten rumbashen, aber vielleicht solltest Du mal ein paar Bücher z.B. von Bjarne Stroustrup oder Scott Meyers lesen, bevor Du hier mit Deiner grandiosen Unwissenheit glänzt. Das Nachbilden von Kontrollstrukturen kommt in der Regel von irgendwelchen Leuten, die von einer anderen Programmiersprache her kommen, und meinen ein bestimmtes Schlüsselwort (aus der alten Sprache) wäre unbedingt erforderlich (in der Regel um irgendwelchen Code 1:1 portieren zu können) anstatt sich mit der Sprache auseinanderzusetzen und etwas vernünftiges zu generieren. Solche Leute sind leider hoffnungslose Anachronisten.

Ich kann mich auch gerne einloggen wenn dich das glücklich macht
Deine Theorie ist im übrigen komplett falsch, allerdings, genau wie der Umstand dass du mir Unwissenheit vorwirfst, scheinbar allein weil du anderer Meinung bist, Zeugnis deiner beschränkten Vorstellungskraft und Verbohrtheit.

[Tachyon]

Gut, dass Du mit Deinen Meinungen hier alleine bist.

Ich hoffe übrigens, dass, falls Du überhaupt schon alt genug bist um zu Arbeiten, Dein Code Dir vor irgendwelchen Reviews oder Code Quality Checks um die Ohren fliegt. Sonst bist Du schneller wieder draußen als Dir lieb ist (oder die Firma ist ihren Namen nicht Wert).

Und noch eine ganz unbedarfte Frage hinterher:

Was meinst Du, soll jemand der Deinen Code liest denken was hier passiert?

unless(boolscher_wert)
{
    //zeugs
}

Rufst Du eine Funktion auf die einen boolschen Wert als Argument erwartet und öffnest anschließend einen neuen Scope? Oder ist es doch ein Makro? Und wann ja, was tut das Makro? Oh, da muss man erstmal nachsehen.
Ist natürlich viel einleuchtender als

if(!boolscher_wert)
{
    //zeugs
}

wo sofort jedem ohne rumsuchen klar wird, dass hier etwas passieren soll, wenn der boolsche Ausdruck falsch ist.

}

[LordJaxom]

'f schrieb:

Dann solltest du vielleicht mal die Relevanz deines Einschubs erklären. Oder willst du auch Pointer, Arrays, praktisch alles was sich in C++ finden lässt verbieten weil man damit Schindluder treiben kann

?
Es geht hier gerade ausschließlich um den Präprozessor. Kennst Du überhaupt den Unterschied zwischen Präprozessor und Compiler?

['f]

asc schrieb:

Sauber geschriebener C++ Code hat auch eine hohe Betriebssicherheit.

Ja, durchaus. Allerdings nicht einmal annähernd so sicher wie viele andere Sprachen, inklusive und insbesondere Ada.

Und die Verwendung von Makros ist in C++ nicht prinzipiell unsicher, genauso wenig wie eigene Kontrollstrukturen (in Sprachen welche vernünftige Möglichkeiten dazu bieten).

asc schrieb:

'f schrieb:

Templates und inline Funktionen decken alle Einsatzmöglichkeiten von Makros ab?

Nein, aber fast alle sinnvollen.

asc schrieb:

Ich würde sagen es macht grundsätzlich keinen Sinn in einer Sprache weitere Befehle mit Makros nachzubauen, da man den Code schlechter lesbar macht. Manche mögen "unless" als sinnvoll erachten, ich halte es eher für "useless", da man effektiv wie bei der Ungarischen Notation eine neue Sprache lernen muss.

Und der Vergleich mit Funktionen, eigenen Typen und Makros ist hinfällig:

Nein, er ist keineswegs hinfällig: "Manche mögen Bibliotheken dritter als sinnvoll erachten, ich halte es eher für 'useless', da man effektiv wie bei der Ungarischen Notation eine neue Sprache lernen muss."

asc schrieb:

'f schrieb:

Btw, was wäre denn deiner Meinung nach kein Missbrauch des CPP?

Verwendung der C++ Sprachmittel, Vermeidung des Präprozessor wo er nicht (wie bei Include) unbedingt notwendig ist.

CPP = C preprocessor

['f]

Tachyon schrieb:

Gut, dass Du mit Deinen Meinungen hier alleine bist.

Ich hoffe übrigens, dass, falls Du überhaupt schon alt genug bist um zu Arbeiten, Dein Code Dir vor irgendwelchen Reviews oder Code Quality Checks um die Ohren fliegt. Sonst bist Du schneller wieder draußen als Dir lieb ist (oder die Firma ist ihren Namen nicht Wert).

Ein Haufen Fehlschlüsse gepaart mit Beleidigungen ersetzen noch lange kein Argument.

['f]

LordJaxom schrieb:

'f schrieb:

Dann solltest du vielleicht mal die Relevanz deines Einschubs erklären. Oder willst du auch Pointer, Arrays, praktisch alles was sich in C++ finden lässt verbieten weil man damit Schindluder treiben kann

?
Es geht hier gerade ausschließlich um den Präprozessor. Kennst Du überhaupt den Unterschied zwischen Präprozessor und Compiler?

Uh. Was soll mir denn dieser schwachsinnige und offensichtlich falsche Kommentar näher bringen?

[Tachyon]

'f schrieb:

Ja, durchaus. Allerdings nicht einmal annähernd so sicher wie viele andere Sprachen, inklusive und insbesondere Ada.

Aussage, kein Argument.

'f schrieb:

Und die Verwendung von Makros ist in C++ nicht prinzipiell unsicher, genauso wenig wie eigene Kontrollstrukturen (in Sprachen welche vernünftige Möglichkeiten dazu bieten).

Aussage, kein Argument.

'f schrieb:

Nein, er ist keineswegs hinfällig: "Manche mögen Bibliotheken dritter als sinnvoll erachten, ich halte es eher für 'useless', da man effektiv wie bei der Ungarischen Notation eine neue Sprache lernen muss."

Noch eine Aussage ohne Argumente.

'f schrieb:

Ein Haufen Fehlschlüsse gepaart mit Beleidigungen ersetzen noch lange kein Argument.

Eine ulkige Aussage im Hinblick darauf, dass Du in Deinen gesamten Ergüssen hier NUR Aussagen triffst ohne jemals Argumente dazu zu liefern.

[Badestrand]

'f schrieb:

Allerdings nicht einmal annähernd so sicher wie viele andere Sprachen, inklusive und insbesondere Ada.

Ist nicht eine Ariane-Rakete durch einen Softwarefehler in Ada abgestürzt?

[Tachyon]

Badestrand schrieb:

'f schrieb:

Allerdings nicht einmal annähernd so sicher wie viele andere Sprachen, inklusive und insbesondere Ada.

Ist nicht eine Ariane-Rakete durch einen Softwarefehler in Ada abgestürzt?

Da haben die Entwickler die Contraint- und Type-Checks des Compilers abgeschaltet. Dazu kam noch ein Haufen weiterer Fehler:
http://www.wikiservice.at/dse/wiki.cgi?Ariane5Absturz

[queer_boy]

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.

['f]

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.

[Konrad Rudolph]

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.

[Bashar]

Tachyon schrieb:

Da haben die Entwickler die Contraint- und Type-Checks des Compilers abgeschaltet.

Wo hast du denn das her?

[Tachyon]

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.

[Konrad Rudolph]

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.

[Konrad Rudolph]

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.)

[queer_boy]

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.