Nun, ich habe mir gedacht, dass ich am besten den Codingstyle der STL und von boost nehme. Dieser scheint einfach zu sein und so habe ich auf dauer ein einheitliches Bild im Code wenn ich eigenen Code und STL/boost mische.
Leider finde ich über diese nur sehr wenige Informationen? Kann mir wer helfen?

Danke

PS: Mit Codestyle meine ich weniger Formatierung sondern eher Namenskonventionen etc.

We do not use C++ exceptions.
We do not use Run Time Type Information (RTTI).
Do only trivial initialization in a constructor. If at all possible, use an Init() method for non-trivial initialization.

*aua* google schreibt wohl ehr ein C-With-Classes als C++, definitiv ein sehr schlechter style guide wenn man ordentliches c++ schreiben will.

(ich hab nicht alles gelesen,das reicht!)

We do not use C++ exceptions.
We do not use Run Time Type Information (RTTI).
Do only trivial initialization in a constructor. If at all possible, use an Init() method for non-trivial initialization.

*aua* google schreibt wohl ehr ein C-With-Classes als C++, definitiv ein sehr schlechter style guide wenn man ordentliches c++ schreiben will.

(ich hab nicht alles gelesen,das reicht!)

Das habe ich auch gedacht, als ich den Guide gelesen habe
Mir geht es eigentlich wirklich nur um Namenskonventionen...

thomas001 schrieb:

We do not use C++ exceptions.
We do not use Run Time Type Information (RTTI).
Do only trivial initialization in a constructor. If at all possible, use an Init() method for non-trivial initialization.

*aua* google schreibt wohl ehr ein C-With-Classes als C++, definitiv ein sehr schlechter style guide wenn man ordentliches c++ schreiben will.

(ich hab nicht alles gelesen,das reicht!)

Das habe ich auch gedacht, als ich den Guide gelesen habe
Mir geht es eigentlich wirklich nur um Namenskonventionen...

Tut mir Leid, wenn ich euch jetzt auf die Füße trete

Im modernen, professionellen Coding-Umfeld ( ob Firma, OpenSource, ... ) gelten die obigen Regeln. Ich danke für den Link, denn der ist eine sehr gute Zusammenfassung.

Das sind ja echt die Sahnestücke oben im Zitat :
RTTI, Exceptions, Konstruktoren ...

Denkt mal nach ob es entsprechende Coding-Probleme gibt, die nicht anders zu lösen sind. [ Tip: while vs. for ]

http://www.wxwidgets.org/develop/standard.htm

Greetz
nurF

blubbba schrieb:

thomas001 schrieb:

We do not use C++ exceptions.
We do not use Run Time Type Information (RTTI).
Do only trivial initialization in a constructor. If at all possible, use an Init() method for non-trivial initialization.

*aua* google schreibt wohl ehr ein C-With-Classes als C++, definitiv ein sehr schlechter style guide wenn man ordentliches c++ schreiben will.

(ich hab nicht alles gelesen,das reicht!)

Das habe ich auch gedacht, als ich den Guide gelesen habe
Mir geht es eigentlich wirklich nur um Namenskonventionen...

Tut mir Leid, wenn ich euch jetzt auf die Füße trete

Im modernen, professionellen Coding-Umfeld ( ob Firma, OpenSource, ... ) gelten die obigen Regeln. Ich danke für den Link, denn der ist eine sehr gute Zusammenfassung.

Das sind ja echt die Sahnestücke oben im Zitat :
RTTI, Exceptions, Konstruktoren ...

Denkt mal nach ob es entsprechende Coding-Probleme gibt, die nicht anders zu lösen sind. [ Tip: while vs. for ]

http://www.wxwidgets.org/develop/standard.htm

Greetz
nurF

Bei großen, Plattformübergreifenden Projekten ist es natürlich klar. Aber bei meinem privaten, kleinen Projekten, die wirklich nur ich entwickle für ein OS mit einem Compiler, da sehe ich keinen Grund, auf Exceptions und RTII zu verzichten.

Denkt mal nach ob es entsprechende Coding-Probleme gibt, die nicht anders zu lösen sind. [ Tip: while vs. for ]

Lol, das ist DAS sinnlose Argument überhaupt. Denk mal nach ob es Coding-Probleme gibt die nicht ohne X zu lösen sind. OMG.

Tut mir Leid, wenn ich euch jetzt auf die Füße trete

Im modernen, professionellen Coding-Umfeld ( ob Firma, OpenSource, ... ) gelten die obigen Regeln.

Professionell vielleicht, modern: Nein.

Aber bei meinem privaten, kleinen Projekten, die wirklich nur ich entwickle für ein OS mit einem Compiler, da sehe ich keinen Grund, auf Exceptions und RTII zu verzichten.

Bei einer One-Man-Show benötigt man nur Absprachen mit sich selbst. Das ist klar.

r = ...; 
if(SUCCEEDED(r))
{
  ...; 
  r = ...; 
  if(SUCCEEDED(r))
  { 
    ...

int array[3]={1,2,3};

auch lustig, dass sie den uralt vc6 noch unterstützen wollen:

FALSCH:

for(int i=0;i<100;++i)

RICHTIG:

int i;
for(i=0;i<100;++i)

Kopf->Wand

oder die Sache mit den templates: sicher brauchen templates länger zum compilieren, aber die zeit hätte man locker raus, wenn deren config scripts/makefiles nicht so grottenschlecht wären, dass sie commandozeilenparameter zugunsten von irgendwelchen __irgendwo__ gefundenen config daten ignorieren würden. Hat mich 4x compilieren gekostet, bis der mir die typedefs richtig konfiguriert hat.

Zum Glück gibt es aber bekannte Firmen, die auch moderne C++-Features einsetzen. (was heißt eigentlich modern? Exceptions und RTTI sind seit 1998 ISO-Norm! Das sind selbstverständlichste Features!)
Schaut euch mal die von Adobe freigegebene Opensource-Libraries an:
http://stlab.adobe.com/ bzw. http://stlab.adobe.com/asl_toc.html

Top moderner Meta-Programming-Code mit allem Pipapo! Ich sage nur GIL (Generic Image Library) von Adobe, welches sie der C++-Welt freudlicherweise frei gegeben haben:
http://opensource.adobe.com/wiki/display/gil/Generic+Image+Library
Moderne Library von einer Firma die anscheinend ihr C++-Handwerk versteht.

Das genaue Gegenteil von dem was Google, wxWidgets und Mozilla (ja, die sind auch so drauf) propagieren.

Nur weil die Philosophie von ein paar OpenSource-Projekten heißt, das sie jeden Asbach-Uralt-Compiler unterstützen müssen, ist das noch lange nicht gut oder richtig. Übrigens gibts auch http://pocoproject.org/ - welches auch gewerblich ist, und die setzen auch alle Features ein.

Zum Glück gibt es aber bekannte Firmen, die auch moderne C++-Features einsetzen. (was heißt eigentlich modern? Exceptions und RTTI sind seit 1998 ISO-Norm! Das sind selbstverständlichste Features!)

Ich frag mich eh, von wann solche Codingstandards wie von Google erstellt wurden, und von wem. Man muss doch auch mit der Zeit gehen können. Wenn man 5 Jahre noch alte Compiler supportet, okay, aber 10 Jahre?

nurf schrieb:

Tut mir Leid, wenn ich euch jetzt auf die Füße trete

Im modernen, professionellen Coding-Umfeld ( ob Firma, OpenSource, ... ) gelten die obigen Regeln. Ich danke für den Link, denn der ist eine sehr gute Zusammenfassung.

Eben nicht. Moderne Firmen werden von Zeit zu Zeit auch die Codingstandards anpassen. Der von google schreit förmlich danach angepasst zu werden. Ja, einiges in den Codingstyle mag okay sein, aber gerade das, was du als "Sahnestücke" bezeichnest ist einfach nur veraltet. Es mag sein das es mal Compiler gab die damit nicht klarkommen. Aber Firmen sollten lieber auch mal etwas Zeit investieren und in gewissen Abständen kleine Migrationen zu machen (Man muss nicht jede Compilergeneration mitmachen, aber sollte dennoch von Zeit zu Zeit Anpassungen vornehmen).

Ich kenne aus eigener Erfahrung Firmen die den Sprung nicht oder zu spät gemacht haben, nun vor dem Problem stehen das Compiler seit 10 Jahren nicht mehr supportet werden, erste Probleme mit aktuellen Betriebssystemen auftreten und eine Migration kaum mehr möglich ist (Zumal die verwendeten Bibliotheken auch nicht weiterentwicklet wurden, und etliche Fehler aufweisen). Altlasten summieren sich über die Zeit immer weiter auf. Man muss damit leben können sich auch mal anpassen zu müssen (Gerade wenn man das Projekt auf Zeiträume von 15+ Jahren ansetzt).

Daher: Wer Scheuklappen vor Neuerungen beibehält, muss sich nicht wundern wenn er irgendwann von den Änderungen überfahren wird.

cu André

1. Don't use C++ templates
2. Don't use C++ exceptions
3. Don't use RTTI
4. Don't use namespaces
5. Don't use STL
6. Don't declare variables inside for()
7. Don't use nested classes

OMG, wieso benutzen die ueberhaupt C++? Vor allem 1, 2, 3 und 4 sind doch die Vorteile von C++.

8. Don't use new logical operators keywords

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

Strolch schrieb:

Das hat absolut nichts mit professionell zu tun. Das ist einfach nur "wir wollen jeden Compiler supporten, auch wenn der Code am Ende scheisse sein wird.".

Da ist doch C fuer solche Firmen doch optimal, wenn man sowieso auf fast alle Features von C++ verzichtet (wie bei wxWidgeds).

1. Don't use C++ templates
2. Don't use C++ exceptions
3. Don't use RTTI
4. Don't use namespaces
5. Don't use STL
6. Don't declare variables inside for()
7. Don't use nested classes

Ist ja wie kochen ohne Topf,Pfanne,Herd und Gewürzen. Am besten alles roh essen.

OMG, wieso benutzen die ueberhaupt C++? Vor allem 1, 2, 3 und 4 sind doch die Vorteile von C++.

Ich vermute ganz stark das dieser Codingstyle von einen ewig gestrigen Entwickler geschrieben wurde, der Entscheidungsbefugt war. Ich kenne auch so einen Entwickler der nach meiner Schätzung durch den gesehenen Projektcode auch mit 25 rum das letzte Mal bereit war zu lernen, dieser ist im Projektleiterposten und verteifigt diesen Stil bis heute (Müsste Heute um die 40 sein) - Neuerungen sind nur möglich wenn man sie hintenrum in den Code einschleust, sich diese als gut herausstellen und man dann dieses langsam und in kleinen Häppchen serviert (letzteres hatte ich in dem Betrieb zum Glück mit Erfolg geschafft).

cu André

Microsoft und gcc

DMC++, Intel, etc. sind alle kompatibel zum MS compiler. Borland habe ich ewig nirgendwo mehr gesehen...

Jedenfalls sind das allesamt moderne Compiler die C++ gut beherrschen. Diese Coding Guidelines waren relevant als die Compiler das alles noch nicht konnten. aber heute? wenn man nicht eine extrem exotische plattform ansteuert wo kein gcc3 läuft, dann ok. aber dann kann befindet man sich sowieso in einem speziellen umfeld.

was aber software betrifft die auf windows, mac, linux, bsd, solaris,... laufen soll - da sind diese guidelines 10-15 jahre zu alt. aber die industrie entwickelt sich bei sowas sehr langsam. deshalb sind diese richtlinien noch immer aktiv - aber wenn man selber mitreden kann, dann bitte ordentliches c++ verwenden...

was aber software betrifft die auf windows, mac, linux, bsd, solaris,... laufen soll - da sind diese guidelines 10-15 jahre zu alt.

Oder um dein Kommentar mal zu mißbrauchen:

Googles Coding Style - ewig nicht mehr aktualisiert

cu André

Gerade das ist ja wohl das Paradebeispiel für einen miserablen C++-Codestil:

1. Don't use C++ templates
2. Don't use C++ exceptions
3. Don't use RTTI
4. Don't use namespaces
5. Don't use STL
...

Da frag ich mich echt auch, wieso die nicht mit C programmieren. Aber das sind wahrscheinlich solche Leute, die Makros wo nur möglich einsetzen, und ihre Container jedesmal selber basteln (viel Spass, vor allem bei der Performance), und und und...
Überhaupt finde ich es unangebracht, wenn irgendwelche Leute denken, sie hätten den einzig wahren Codestil gefunden. Mit der ungarischen Notation kann ich beispielsweise überhaupt nichts anfangen, das scheint für mich eher ein verzweifelter Versuch, dreckigen Code durch die UN noch einigermassen ordentlich aussehen zu lassen...

Aber natürlich, jedem das Seine; wenn man damit zurecht kommt, ist ja alles in Ordnung. Ich kann es nur nicht verstehen, wenn man sich verkrampft an irgendwelche Pseudo-Normen zu halten versucht, obwohl man selber auch ganz anderer Überzeugung ist...

Shade Of Mine schrieb:

was aber software betrifft die auf windows, mac, linux, bsd, solaris,... laufen soll - da sind diese guidelines 10-15 jahre zu alt.

Oder um dein Kommentar mal zu mißbrauchen:

Googles Coding Style - ewig nicht mehr aktualisiert

cu André

Scheint so, aber ich finde das echt ein wenig traurig. Ein so grosses Unternehmen und ein Unternehmen, dass so jugendlich und dynamisch Auftritt, sollte da doch ein Beispiel sein und allen voran gehen.
Ich gehe sogar so weit zu glauben, dass dieser Standard intern nicht eingehalten wird und die Mittel dennoch genutzt werden. Ich kann mir das einfach nicht vorstellen.

Das sind ja echt die Sahnestücke oben im Zitat :
RTTI, Exceptions, Konstruktoren ...

Das ist der letzte Müll. Das führt nur wieder zum alt bekannten ignorieren von Fehlermeldungen und des beliebten Fehlerhandlings "exit(EXIT_FAILURE);". So sinnvolle Dinge wie Destruktoren grundsätzlich als "throw ()" zu deklarieren wird kein Wort verloren.

Do only trivial initialization in a constructor. If at all possible, use an Init() method for non-trivial initialization.

find ich gar nicht sooo verkehrt...
Mach ich selbst zwar auch nicht, aber es wäre eigtl mal eine Überlegung wert - weil (vermutlich bis zum nächsten Standard kein Ctor einen anderen aufrufen kann) - und so kann man Klassen wenigstens "wiederverwenden"...

Oder seh ich das komplett falsch?

bb