Codingstyle?

finix

Noch ne Variante:

foo::foo( int& error ) {
    if (error == 0) {
        // initialize foo
        if (!whatever()) {
            error = 123;
            return; }}}

bar::bar( int& error )
    : foo1_(error)
    , foo2_(error) {
    if (error == 0) {
        // error == 0 means m_foo1 and m_foo2 have been fully constructed
        // initialize bar
        if (!whatever()) {
            error = 123;
            return; }}}

otze

was spricht jetzt eigentlich gegen exceptions?

diese konstrukte mit error sind ziemlich fürn arsch. und man muss sich, wie hustbaer sagte, mit untoten objekten rumschlagen.

Immerhin schreibt Google mit diesen Regeln gute Programme. Sind bei denen die Serverseitigen Programme auch in C++ geschrieben, oder nur sowas wie Google Earth?

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.

otze

hypermegaprocoder schrieb:

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.

richtig. manchmal muss es aber sein. spätestens wenn du irgendwas hast, dass direkt auf lockbare hardware zugreifen muss, wie soundkarte, grafikkarte, usw, wirds kritisch. Man kann es umgehen, aber es ist sinnvoll zu wissen, wie man mit sowas umzugehen hat.

DEvent

Nexus schrieb:

unskilled schrieb:

weil (vermutlich bis zum nächsten Standard kein Ctor einen anderen aufrufen kann)

Wieso sollte man das nicht können? Das passiert ja bei allen Elementen, deren Typ kein Grundtyp von C++ ist.
In der Initialisierungsliste kann man die Konstruktoraufrufe auch explizit aufschreiben, ansonsten wird der Standardkonstruktor aufgerufen.

Ich find Init() -Methoden nicht gerade schön, das hebelt das ganze Konzept von Konstruktoren aus. Für mich ist das eher ein Anzeichen von schlechtem Design. Wie ist das begründet, dass man nur triviale Dinge im Konstruktor regeln und den Rest in Funktionen auslagern sollte?

Ich frag mich grade wie lange man wohl debuggen muss, damit man den Bug enddeckt das irgend einer vergessen hat init() aufzurufen.

class GoogleRegeln
{
    public:
      GoogleRegeln() : error(0) { }
      int init()
      {
          // initialliserire das Objekt
          return 0;
      }
}

// ...

GoogleRegeln* obj = new GoogleRegeln();
// obj->init() vergessen
// ...
obj.foo();
obj.bar();

pumuckl

DEvent schrieb:

8. Don't use new logical operators keywords

Das wusste ich gar nicht das C++ solche keywords hatt.

Hat es. Es sind die üblichen: and, or, not. Dass die nicht so bekannt sind liegt AFAIK daran dass ein oder zwei größere Compiler (MSVC?) die Dinger nicht unterstützen. Was widerum in meinen Augen ein Armutszeugnis des Compilerherstellers ist. Wenn irgendwelche komplizierten template-Konstrukte nicht ganz so funktionieren wie der Standard es vorsieht, naja. Aber diese Keywords sollten nunmal echt billig zu implementieren sein.

unskilled

Ich meinte den "eigenen" CTor...

Wundertolles Beispiel folgt:

struct ali_nix_schuld
{
bool ist_ali_schuld;
bool ali_wirklich_nicht_schuld;

ali_nix_schuld (bool ist_wahr_fragezeichen)
: ist_ali_schuld (ist_wahr_fragezeichen), ali_wirklich_nicht_schuld (ist_wahr_fragezeichen)
{}

ali_nix_schuld (const Tperson &schuldiger)
: ali_nix_schuld (false)
{
//noch was mit Tperson machen
}

ali_nix_schuld (const Tobject &missverstaendnis)
: ali_nix_schuld (false)
{
//noch was mit Tobject machen
}
};

bb : )

It0101

Wie wäre es denn, wenn mal jemand, der sich einen guten Programmierstil zutraut, ein paar Grundregeln veröffentlicht. Auch meinetwegen Codebeispiele. Damit meine ich nicht nur den eigenen Standpunkt zu Exceptions, oder Templates, sondern auch den Faktor "Lesbarkeit / optische Erscheinung" des Codes.

Falls es sowas hier schon gibt, bitte ich um einen Link, da ich gern mal wissen würde, wie andere so coden und was ich vielleicht selbst besser machen könnte.

Konrad Rudolph

pumuckl schrieb:

DEvent schrieb:

8. Don't use new logical operators keywords

Das wusste ich gar nicht das C++ solche keywords hatt.

Hat es. Es sind die üblichen: and, or, not. Dass die nicht so bekannt sind liegt AFAIK daran dass ein oder zwei größere Compiler (MSVC?) die Dinger nicht unterstützen. Was widerum in meinen Augen ein Armutszeugnis des Compilerherstellers ist. Wenn irgendwelche komplizierten template-Konstrukte nicht ganz so funktionieren wie der Standard es vorsieht, naja. Aber diese Keywords sollten nunmal echt billig zu implementieren sein.

Microsofts Antwort darauf ist „won't fix“. Ich habe das als Bugreport gemeldet und m.E. auch argumentativ untermauert. MS' Gegenargument war, dass sich bisher noch niemand beschwert hat.

Dravere

Konrad Rudolph schrieb:

Microsofts Antwort darauf ist „won't fix“. Ich habe das als Bugreport gemeldet und m.E. auch argumentativ untermauert. MS' Gegenargument war, dass sich bisher noch niemand beschwert hat.

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?

Grüssli

Shade Of Mine

Dravere schrieb:

Verwendet die überhaupt jemand, bzw. würde die überhaupt jemand verwenden?

Damit man auf exotischen Tastaturen C Programmieren kann. Siehe http://en.wikipedia.org/wiki/Iso646.h

Das ganze ist natuerlich heute laengst ueberholt.

Dravere schrieb:

Mir ist es bis Heute überhaupt ein Rätsel, wieso diese Keywords eingeführt worden sind. Wofür?

Ja, finde es auch sinnlos zwei schreibweisen dafür haben zu wollen.

Konrad Rudolph

Dravere schrieb:

Konrad Rudolph schrieb:

Microsofts Antwort darauf ist „won't fix“. Ich habe das als Bugreport gemeldet und m.E. auch argumentativ untermauert. MS' Gegenargument war, dass sich bisher noch niemand beschwert hat.

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 verwende die ausschließlich. Es ist einfach lesbarer als dieses unsägliche ASCII-Art-Unsitte, das sich mit C eingeschlichen hat. Man muss nicht auf Tot komm raus versuchen, jedes Schlüsselwort in ein Symbol zu pressen. Dafür gibt's Brainfuck.

Die Fehlermeldung kannst Du auf Connect nachlesen: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=312168

Shade Of Mine

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

Konrad Rudolph

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.

Dravere

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

otze

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)

Konrad Rudolph

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.

Dravere

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

Shade Of Mine

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