Codingstyle?
-
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.
-
übrigens schrieb:
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.
Und woher weisst du, was der Rückgabewert bedeutet?
-
übrigens schrieb:
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.
Das ist irrelevant. Du musst als Aufrufer ja auch auf den Fehler reagieren. Ein einfaches
if (retval != SUCCESS) return FAILURE;wird da wohl kaum ausreichen. Stattdessen muss sich der Aufrufer Gedanken darum machen, wie er den Rückgabewert behandelt, *welcher* Fehler aufgetreten ist und ob der Fehler an dieser Stelle behoben/ignoriert werden kann.
-
Meep Meep schrieb:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-149932-and-highlight-is-meep+meep.html
ganz unten hab ich es beschrieben
Vielen Dank, das ist ein guter Tip. Da habe ich bei der Gelegenheit gleich auch mal
size_tundptrdiff_teingetragen. Das ist zwar nicht korrekt, aber dafür konsistent mit dem VIM-Syntaxhighlighting und da ich eh meistens mit dem VIM arbeite, bietet sich das an.
-
Konrad Rudolph schrieb:
übrigens schrieb:
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.
Das ist irrelevant. Du musst als Aufrufer ja auch auf den Fehler reagieren. Ein einfaches
if (retval != SUCCESS) return FAILURE;wird da wohl kaum ausreichen. Stattdessen muss sich der Aufrufer Gedanken darum machen, wie er den Rückgabewert behandelt, *welcher* Fehler aufgetreten ist und ob der Fehler an dieser Stelle behoben/ignoriert werden kann.Wenn du um jeden Methodenaufruf ein try catch(...) machst, dann könnte es wirklich das selbe sein, aber dann hast du mit den Exceptions nicht viel mehr gewonnen als mit Returncodes. Wenn du mit den Exceptions richtig arbeiten würdest dann müsstest du auch folgendes beachten.
Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in in a new project. The conversion process would be slow and error-prone.
Und da kannst du doch nicht behaupten, dass das dasselbe ist.
-
übrigens schrieb:
Konrad Rudolph schrieb:
Du musst als Aufrufer ja auch auf den Fehler reagieren. Ein einfaches
if (retval != SUCCESS) return FAILURE;wird da wohl kaum ausreichen. Stattdessen muss sich der Aufrufer Gedanken darum machen, wie er den Rückgabewert behandelt, *welcher* Fehler aufgetreten ist und ob der Fehler an dieser Stelle behoben/ignoriert werden kann.Wenn du um jeden Methodenaufruf ein try catch(...) machst, dann könnte es wirklich das selbe sein, aber dann hast du mit den Exceptions nicht viel mehr gewonnen als mit Returncodes.
Ich schrieb doch gar nicht, dass man das „um jeden Methodenaufruf“ machen muss, aber *irgendwo* muss man es machen. Sonst bräuchte man ja auch bei Ausnahmen keine Ausnahmebehandlung zu schreiben, und genau das wird hier ja behauptet.
Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in in a new project. The conversion process would be slow and error-prone.
Und da kannst du doch nicht behaupten, dass das dasselbe ist.
Für solche Fälle eignet sich ein Proxy, sagte ich doch bereits.
