Codingstyle?
-
Shade Of Mine schrieb:
Konrad Rudolph schrieb:
Ich verwende die ausschließlich.
OK, das ist dann dein eigenes Problem.
Sie waren nie gedacht dass man sie verwendet wenn es denn nicht sein muss.Wenn du gegen die intention dieser keywords arbeitest, musst du dich nicht wundern wenn es schief geht...
Diese Argumentation ist an Dünnpfiff aber kaum noch zu überbieten, das ist Dir hoffentlich bewusst. „gegen die intention dieser keywords“ – hallo?! Außerdem steht im Standard nix von Intention, im Standard steht „muss unterstützt werden.“
Auf Basis Deiner Argumentation verbiete ich Dir jetzt die Benutzung von Boost und jeglicher Template Metaprogramming. Das war nie Intention von Templates.
-
Shade Of Mine schrieb:
Konrad Rudolph schrieb:
Ich verwende die ausschließlich.
OK, das ist dann dein eigenes Problem.
In dem Satz liegt Shade Of Mine allerdings schon richtig. Ich meine, wie es die Microsoft Leute dir gesagt haben, du bist der Erste und diese Keywords sind ja nicht gerade neu. Es kennt sie niemand, es will sie anscheinend niemand, bzw. nur ein einziger und der bist du
Allerdings finde ich es schon witzig, sooo viel Arbeit kann das wirklich nicht darstellen, diese zu implementieren. Wäre sicher noch interessant, ob es dann ein paar mehr verwenden würden. Aber ich denke, dass die bei Microsoft ganz klare Vorgaben haben, dass wenn ein Feature von niemanden verlangt wird oder von viel zu wenigen, egal wie gross das Feature ist, man es gar nicht implementiert. Strikt nach den Regeln, sonst hätte man plötzlich Probleme mit der Argumentation, was man denn nun implemtieren, bzw. umsetzen, soll.
Grüssli
-
Dravere schrieb:
Darf ich fragen, wie du das argumentativ untermauert hast? Ich finde irgendwie kein sinnvolles Argument dafür. Mir ist es bis Heute überhaupt ein Rätsel, wieso diese Keywords eingeführt worden sind. Wofür? Verwendet die überhaupt jemand, bzw. würde die überhaupt jemand verwenden?
Ich find die eigentlich garnicht so schlecht. Allein dass es dann syntaxhighlighting gibt ist ein riesen vorteil wenn man sich code später wieder anschauen muss.
dies->ist_ein(langer,ausdruck(mit,vielen,argumenten) && dies(ist(ein,anderer),ausdruck) //vergleich dies->ist_ein(langer,ausdruck(mit,vielen,argumenten) and dies(ist(ein,anderer),ausdruck)
-
Dravere schrieb:
Shade Of Mine schrieb:
Konrad Rudolph schrieb:
Ich verwende die ausschließlich.
OK, das ist dann dein eigenes Problem.
In dem Satz liegt Shade Of Mine allerdings schon richtig. Ich meine, wie es die Microsoft Leute dir gesagt haben, du bist der Erste und diese Keywords sind ja nicht gerade neu. Es kennt sie niemand, es will sie anscheinend niemand, bzw. nur ein einziger und der bist du
Ja, und mit diesem Hintergedanken lies Dir meine Antwort bei Connect nochmal durch: Der Grund, warum nur ich es verwende ist eben, dass es nicht vernünftig unterstützt wird!
In anderen Sprachen, die einem die Alternative geben, ist die Akzeptanz der Schlüsselwort-Varianten sehr hoch. Offensichtlich bin ich nicht der einzige, der es lesbarer findet.
-
Konrad Rudolph schrieb:
Ja, und mit diesem Hintergedanken lies Dir meine Antwort bei Connect nochmal durch: Der Grund, warum nur ich es verwende ist eben, dass es nicht vernünftig unterstützt wird!
Das ist Spekulation. Aber ich habe ja auch einen zweiten Absatz geschrieben, dort hatte ich diesen Hintergedanken im Kopf
Konrad Rudolph schrieb:
In anderen Sprachen, die einem die Alternative geben, ist die Akzeptanz der Schlüsselwort-Varianten sehr hoch. Offensichtlich bin ich nicht der einzige, der es lesbarer findet.
Andere Sprachen, andere Anwender. Und oft haben diese Leute ganz unterschiedliche Vorstellungen und insofern kann eine ganz andere Aktzeptanz entstehen. Aber wie gesagt, ich fände es noch interessant, was passieren würde. Aber dazu wird es wohl nicht kommen, aus den Gründen, welche ich schon hingeschrieben habe.
Unterstützt der GCC, bzw. G++, dieses Feature? Der Intel Compiler? Sonstige Compiler?
Grüssli
-
Konrad Rudolph schrieb:
Diese Argumentation ist an Dünnpfiff aber kaum noch zu überbieten, das ist Dir hoffentlich bewusst. „gegen die intention dieser keywords“ – hallo?! Außerdem steht im Standard nix von Intention, im Standard steht „muss unterstützt werden.“
Auf Basis Deiner Argumentation verbiete ich Dir jetzt die Benutzung von Boost und jeglicher Template Metaprogramming. Das war nie Intention von Templates.
Und wieder Kindergarten
Wie immer.
and bit_and etc. wurden aus kompatibilitaetsgruenden eingefuehrt. Wenn du sie nutzen willst, inkludiere iso646.h und gut ist. Aber damit werden deine programme nur schwerer lesbar.iso646.h wird von C++ Compilern uebrigens auch unterstuetzt, also verwende es doch einfach anstatt rumzumeckern dass dieses sinnlose feature nicht in den compilern selbst implementiert ist.
Es war damals schon ein Fehler diese option anzubieten, aber man musste es tun genauso wie man die trigraphs eingebaut hatte: damit jeder in dieser sprache programmieren konnte.
Aber da das heute kein thema mehr ist, sind diese features auch nicht in verwendung. ein && ist mittlerweile einfach klarer als ein and. denn && versteht jeder, bei and schaut jeder erstmal doof weil das einfach unerwartet ist in einem c oder c++ code.
du kannst jetzt sagen dass das total uninteressant fuer dich ist und and einfach soviel cooler ist als && und ich kann dir jetzt sicher 100 mal erklaeren warum ein and in c++ einfach nicht schoen hereinpasst, zB aus konsequenz zu + und * oder eben wegen dem whitespace problem - aber das wird dir egal sein.
was du aber erkennen solltest ist: in c++ programmiert man c++, in java java und in foo foo. and, bit_and, etc. wurden als unpraktisch befunden und &&, &, etc. sind die gaengige variante die um nichts schlechter ist, worum es dir geht ist aesthetik - mehr nicht. es gibt keine technischen gruende fuer and, bit_and,...
in anderen sprachen macht man es anders, ja. aber das ist keine andere sprache: c++ bietet einem heute, hier und jetzt die moeglichkeit and, bit_and, etc. zu verwenden. aber man tut es nicht, weil es keinen sinn macht.
in php verwendet man auch kein and, or,... sondern && und || obwohl man da die moeglichkeit ebenfalls hat zu wechseln. in anderen sprachen wird das von der sprache abhaengig jeweils anders gehandhabt.
generell besser kann and, bit_and,... ja auch nicht sein, sonst haette C# oder Java oder eine sonstige neue sprache das ja vermutlich zwingend erforderlich gemacht, oder? also bitte, get your facts straight.
PS:
alleine dass hier niemand die iso646.h kennt sollte begreiflich machen wie uninteressant dieses feature von c++ ist
-
To be honest you are the first person to ever request something like this.
-
hehe, es ist wie
To be honest, it sucks to be you.
-
Shade Of Mine schrieb:
Und wieder Kindergarten
Wie immer.Moment mal. Den hast ja nun aber wirklich Du angefangen.
was du aber erkennen solltest ist: in c++ programmiert man c++, in java java und in foo foo. and, bit_and, etc. wurden als unpraktisch befunden und &&, &, etc. sind die gaengige variante die um nichts schlechter ist, worum es dir geht ist aesthetik - mehr nicht. es gibt keine technischen gruende fuer and, bit_and,...
Ästhetik /ist/ ein technischer Grund, wenn er die Lesbarkeit beeinflusst. Das ist weder ein Argument für noch gegen 'and', aber es ist ein Argument. Du hingegen argumentierst nicht sondern stellst nur lustig Behauptungen auf („wurde als schlecht befunden“).
in php verwendet man auch kein and, or,... sondern && und || obwohl man da die moeglichkeit ebenfalls hat zu wechseln.
Wer ist „man“? Du? Vielleicht? Andere? Wohl eher nicht.
generell besser kann and, bit_and,... ja auch nicht sein, sonst haette C# oder Java oder eine sonstige neue sprache das ja vermutlich zwingend erforderlich gemacht, oder?
Nein, wieso sollten sie? Die Sprachen sind ja auch ansonsten in Punkto Lesbarkeit ein einziges Fehldesign. Und sowohl Gosling als auch Hejlsberg scheinen sowieso einige sehr kranke Ansichten zur Programmierung zu vertreten. Die beiden als Autorität auf diesem Gebiet anzusehen habe ich schon lange aufgegeben.
– In jedem Fall wäre diese Argumentation aber idiotisch, da es genug andere Sprachen gibt, die nach C und C++ herausgekommen sind und die 'and' und 'or' unterstützen (und teilweise erheblich von der C-Syntax beeinflusst wurden).
alleine dass hier niemand die iso646.h kennt sollte begreiflich machen wie uninteressant dieses feature von c++ ist
Oder eben genau andersherum, wie von mir argumentiert.
Ich kapiere allgemein nicht, wieso Du so krampfhaft versuchst, iso646 zu einem Sprachfeature zweiter Klasse zu degradieren. Ich muss überlesen haben, dass im Standard Wertigkeiten vergeben wurden. Oder Du interpretierst da einfach Deine persönlichen Wertigkeiten hinein. Von „ich mag 'and' nicht“ zu „'and' wurde für schlecht befunden“ ist es ein weiter Schritt.
-
dies[h1]->[/h1]ist_ein(langer,ausdruck(mit,vielen,argumenten) [h3]&&[/h3] dies(ist(ein,anderer),ausdruck)
-
However, this is unsatisfactory as it does not enable proper syntax highlighting for these keywords
man hat auch die moeglichkeit in vc eigene keywords einfaerben zu lassen. sollte dann also auch mit and .. funktionieren
Meep Meep
-
Shade Of Mine schrieb:
ein && ist mittlerweile einfach klarer als ein and
Dieser Argumentation kann ich mich nicht anschließen. In anderen Sprachen gibt es gut zu unterscheidende Operatoren für logisches AND und Bitoperationen. Wenn man && schreibt kann man leicht & tippen. Wenn man Pech hat wird noch nicht einmal ein Fehler oder Warnung vom Compiler ausgegeben - schlecht. Die neuen Schlüsselworte dienen dazu, so etwas zu verhindern.
-
~john schrieb:
Die neuen Schlüsselworte dienen dazu, so etwas zu verhindern.
Die neune?
-
~john schrieb:
Shade Of Mine schrieb:
ein && ist mittlerweile einfach klarer als ein and
Dieser Argumentation kann ich mich nicht anschließen. In anderen Sprachen gibt es gut zu unterscheidende Operatoren für logisches AND und Bitoperationen. Wenn man && schreibt kann man leicht & tippen. Wenn man Pech hat wird noch nicht einmal ein Fehler oder Warnung vom Compiler ausgegeben - schlecht. Die neuen Schlüsselworte dienen dazu, so etwas zu verhindern.
Dann sollte man auch noch eq einführen, weil man sich bei if(i = 0) noch viel lieber vertippt.
-
Meep Meep schrieb:
However, this is unsatisfactory as it does not enable proper syntax highlighting for these keywords
man hat auch die moeglichkeit in vc eigene keywords einfaerben zu lassen. sollte dann also auch mit and .. funktionieren
Mir war/ist nicht bewusst, dass das ohne weiteres geht. Hast Du da irgendwelche genaueren Infos? (Auch, wenn das das Problem nur bedingt umgeht …)
-
Konrad Rudolph schrieb:
Meep Meep schrieb:
However, this is unsatisfactory as it does not enable proper syntax highlighting for these keywords
man hat auch die moeglichkeit in vc eigene keywords einfaerben zu lassen. sollte dann also auch mit and .. funktionieren
Mir war/ist nicht bewusst, dass das ohne weiteres geht. Hast Du da irgendwelche genaueren Infos? (Auch, wenn das das Problem nur bedingt umgeht …)
http://www.c-plusplus.net/forum/viewtopic-var-t-is-149932-and-highlight-is-meep+meep.html
ganz unten hab ich es beschrieben
Meep Meep
-
hypermegaprocoder schrieb:
PS: Wer solche Konstruktoren schreibt die an 10 Stellen Exceptions werfen können, der hat doch sowieso schon was falsch gemacht. Alle großen C++ Libs die mir so einfallen kommen ohne unmengen an Exceptions in Konstruktoren und sonst wo aus.
Die meisten Klassen die man schreibt werfen selbst Exceptions oder rufen (explizit oder implizit) Code auf der Exceptions werfen kann.
Ein std::string oder Ähnliches als Member reicht.Und: alle *guten* C++ Libs die mir so einfallen verwenden durchgehend Exceptions.
-
wenn man sich das mal durchliest, warum google keine Exceptions nimmt, dann ist ziemlich klar warum sie das machen, aber ich denke das hat keiner gemacht, der sich darüber aufregt.
-
übrigens schrieb:
wenn man sich das mal durchliest, warum google keine Exceptions nimmt, dann ist ziemlich klar warum sie das machen, aber ich denke das hat keiner gemacht, der sich darüber aufregt.
Nicht wirklich. Der Grund klingt erst mal gut, ist aber eigentlich Quatsch. Es stimmt zwar, dass es enorm viel Aufwand bedeutet, wenn man ein 'throw' in existierenden Code einfügt, weil tatsächlich alle aufrufenden Funktionen aktualisiert werden müssen.
Dasselbe ist aber der Fall, wenn man einen anderen Fehler-Mechanismus statt Ausnahmen verwendet. Das Problem wir dadurch dann sogar eher noch schwerer. Das Argument ist also gut, nur bezieht es sich auf eine ganz andere Behauptung, nämlich nicht „don't use exceptions“ sondern „don't modify existing code, if at all possible.“
Wenn Google ihren OpenSource-Code auch in internen, Ausnahme-freien Projekten verwenden wollen, müssen sie eben einen Wrapper bauen. Das ist übliche Praxis und ich weiß nicht, wieso hier dagegen argumentiert wird.
-
Konrad Rudolph schrieb:
Dasselbe ist aber der Fall, wenn man einen anderen Fehler-Mechanismus statt Ausnahmen verwendet. Das Problem wir dadurch dann sogar eher noch schwerer. Das Argument ist also gut, nur bezieht es sich auf eine ganz andere Behauptung, nämlich nicht „don't use exceptions“ sondern „don't modify existing code, if at all possible.“
Warum dasselbe und warum schwerer? Den returnwert einer Funnktion sieht man immer gleich, wogegen man bei exceptions nur hoffen kann, dass es im Kommentar steht oder man mus den ganzen Code der irgendwie aufgerufen werden kann durchschauen.
