Stilfrage

[THX 1138]

Hi Leute

Erstmal die Bitte an euch, den Titel nicht als Flameaufruf zu verstehn.

Ich les hier immer mal wieder, "C versaut Deinen C++ Stil!".
Was meint ihr damit? Bezieht sich das auf Lesbarkeit, verwendete Befehle oder um Design/Struktur?

Kann jemand der profesionell Software entwickelt mich mal in die richtige Richtung schubsen, bzw. ein Syntax-Styleguide empfehlen?
Klasendesign hab ich schon einiges gefunden was mir sinn zu machen scheint ( zB: C++ Notizen (?) )

thx..

[GPC]

Hallo,

1310-Logik schrieb:

Ich les hier immer mal wieder, "C versaut Deinen C++ Stil!".
Was meint ihr damit? Bezieht sich das auf Lesbarkeit, verwendete Befehle oder um Design/Struktur?

Hauptsächlich dreht es sich darum, dass man dazu verleitet wird, auch in C++ weiterhin stark strukturiert (eben wie in C) zu programmieren, obwohl man in C++ OOP programmieren sollte.

Kann jemand der profesionell Software entwickelt mich mal in die richtige Richtung schubsen, bzw. ein Syntax-Styleguide empfehlen?

Lies Scott Meyers Effective C++ und More Effective C++ bzw. Herb Sutters Exceptional C++, More Exceptional C++. Es gibt auch noch C++ Coding Standards von Sutter und Alexandrescu. Reicht das ?

MfG

GPC

[volkard]

1310-Logik schrieb:

Ich les hier immer mal wieder, "C versaut Deinen C++ Stil!".
Was meint ihr damit? Bezieht sich das auf Lesbarkeit, verwendete Befehle oder um Design/Struktur?

versaut alles.
aber weniger die sprache C, sondern die rohen sitten in der C-gemeinde. du wirst ja bei problemlösungen auch immer mal gucken, was die anderen so machen.

[THX 1138]

GPC schrieb:

Lies Scott Meyers Effective C++ und More Effective C++ bzw. Herb Sutters Exceptional C++, More Exceptional C++. Es gibt auch noch C++ Coding Standards von Sutter und Alexandrescu. Reicht das ?

Ja, das ist mal ne Menge zu lesen..
Danke.

[nirsaja]

The Elements of C++ Style | ISBN: 0521893089
Sowas ist aber Geschmackssache....

PS: Und es ist nicht sehr schnell zu bekommen. Ich bin nicht einmal sicher ob es das in Deutsch gibt.

[THX 1138]

ja über geschmack lässt sich ja herrlich streiten.
hab da schon stil angewöhnt den ich lesbar finde. aber ev. habt ihr firmeninterne standards für bezeichner?
ansich ist mir die strukturierung wichtiger, da als alter pascal hase neu mit oop.

thx

[Javaner]

GPC schrieb:

Hauptsächlich dreht es sich darum, dass man dazu verleitet wird, auch in C++ weiterhin stark strukturiert (eben wie in C) zu programmieren

In C++ programmiert man also gefälligst nicht-strukturiert == unstrukturiert
Das wäre ja fürchterlich (obwohl manche Programme tatsächlich so aussehen, als
wären sie auf diese Weise programmiert).

Du meintest statt strukturiert sicherlich imperativ, dann hast du allerdings Recht.

GPC schrieb:

...obwohl man in C++ OOP programmieren sollte.

Da wir gerade auch bei Stilfragen sind:
Objekt Orientierte Programmierung programmieren muß ich nicht unbedingt.
Objektorientiert programmiere ich schon lieber.
Das ist ja fast so schlimm, wie andauernd von PDF-Dokumenten lesen/hören zu müssen

Zusätzlich zu dem was du zu Recht geschrieben hast, würde ich noch anmerken, daß
der originale C-Programmierstil zu übermäßigem Gebrauch von Pointern
führen kann, was in C++, aus Rücksicht auf Aufwärtskombatibilität, leider nicht
durch die Sprachdefinition verhindert wird.

[Javaner]

Javaner schrieb:

Das ist ja fast so schlimm, wie andauernd von PDF-Dokumenten lesen/hören zu müssen

Sorry, meinte natürlich PDF-Format (statt Dokument was ok ist)

[Walli]

1310-Logik schrieb:

Ich les hier immer mal wieder, "C versaut Deinen C++ Stil!".

Gilt umgekehrt auch. Ich musste in einem Praktikum in der Uni heute mal wieder was in C machen und habe mich einige Male dabei ertappt, dass ich versuche C++ in C zu programmieren.

[GPC]

Hallo,

Javaner schrieb:

GPC schrieb:

Hauptsächlich dreht es sich darum, dass man dazu verleitet wird, auch in C++ weiterhin stark strukturiert (eben wie in C) zu programmieren

In C++ programmiert man also gefälligst nicht-strukturiert == unstrukturiert
Das wäre ja fürchterlich (obwohl manche Programme tatsächlich so aussehen, als
wären sie auf diese Weise programmiert).

Du verstehst mich falsch, ich meinte z.B. dass man anstatt switch zur Typauswahl lieber virtuelle Methoden verwenden sollte (Gruß an volkard ), oder dass man nicht n Haufen globaler Funktionen schreiben sollte, sondern vernünftige Klassen.

Du meintest statt strukturiert sicherlich imperativ, dann hast du allerdings Recht.

Eigentlich nicht, aber sprich weiter...

GPC schrieb:

...obwohl man in C++ OOP programmieren sollte.

Da wir gerade auch bei Stilfragen sind:
Objekt Orientierte Programmierung programmieren muß ich nicht unbedingt.
Objektorientiert programmiere ich schon lieber.
Das ist ja fast so schlimm, wie andauernd von PDF-Dokumenten lesen/hören zu müssen

okay, der Begriff hat sich so eingebürgert. Es hört sich halt blöd an, wenn ich sage: "Ich programmier OO". Programmiere ich WCs? Nein, eher nicht. Es ist wie mit "C/C++". Nervt, aber was will man machen?

Javaner schrieb:

Javaner schrieb:

Das ist ja fast so schlimm, wie andauernd von PDF-Dokumenten lesen/hören zu müssen

Sorry, meinte natürlich PDF-Format (statt Dokument was ok ist)

Da PDF Portable Document Format heißt, ist sowohl PDF - Dokument als auch PDF - Format blödsinn

Zusätzlich zu dem was du zu Recht geschrieben hast, würde ich noch anmerken, daß
der originale C-Programmierstil zu übermäßigem Gebrauch von Pointern
führen kann,

Da man in C nichts anderes hat, fällt die Wahl nicht schwer

Es ist kompakt und straightforward. So sollte es sein und so ist es auch.

was in C++, aus Rücksicht auf Aufwärtskombatibilität, leider nicht
durch die Sprachdefinition verhindert wird.

Pointer sind schon i.O. , wenn man sie verstanden hat, sind sie auch nicht komplizierter als Java - Referenzen. Wichtig ist nur, dass man, wenn möglich, ne Referenz nimmt.

MfG

GPC

[THX 1138]

ein portables dokument im PDF-format bitte??

[Artchi]

Also wenn ich sehe, das einige Leute z.B. anstatt std::vector lieber mit realloc oder so arbeiten, dann ist das für mich versauter Stil. Oder anstatt std::string dann doch lieber mit char-Arrays und strcmp und dem anderen Kram arbeiten, dann ist das für mich versaut. Weil dann brauch ich kein C++, dann sollte ich lieber bei C bleiben. Dann ist es berechtigt sowas zu benutzen. Und wenn einem std::vector oder std::string nicht gefällt, dann sollte man sich wenigstens eine C++-Alternative suchen (z.B. aus der Boost-Lib) oder wenigstens eine eigene String-Klasse programmieren. Aber nicht mit dem C-Zeug in C++ rummachen.

switch-Cases anstatt Polymorphie ist auch noch so ein Thema.

Oder Pointer, wo meistens Referenzen ihren Dienst tun sollten... was nicht heißt, das man keine Pointer benutzen soll, aber dann bitte nur da, wo es auch Sinn macht.

Ich benutze nicht eine total andere Sprache, um nachher doch die Features nicht zu nutzen. Ich kauf mir ja auch nicht nen Ferrari, um damit so durch die Gegend zu fahren, wie ich es vorher mit meinem Roller gemacht habe.

[volkard]

Artchi schrieb:

Also wenn ich sehe, das einige Leute z.B. anstatt std::vector lieber mit realloc oder so arbeiten, dann ist das für mich versauter Stil.

wenn ich sehe, daß leute leiber mit std::vector arbeiten als mit realloc, ist das für mich versauter stil. ich sehe sogar leute, die std::vector nehmen, wo fixed-sized arrays reichen.

Oder anstatt std::string dann doch lieber mit char-Arrays und strcmp und dem anderen Kram arbeiten, dann ist das für mich versaut.

oder anstatt char const* gleich strings in ihre schöüsselworttabele als std::map legen.

dann ist das offensichtlich verschenkte performance. wer's nicht kann, soll doch java nehmen.

Weil dann brauch ich kein C++, dann sollte ich lieber bei C bleiben. Dann ist es berechtigt sowas zu benutzen. Und wenn einem std::vector oder std::string nicht gefällt, dann sollte man sich wenigstens eine C++-Alternative suchen (z.B. aus der Boost-Lib) oder wenigstens eine eigene String-Klasse programmieren. Aber nicht mit dem C-Zeug in C++ rummachen.

switch-Cases anstatt Polymorphie ist auch noch so ein Thema.

ok.

Oder Pointer, wo meistens Referenzen ihren Dienst tun sollten... was nicht heißt, das man keine Pointer benutzen soll, aber dann bitte nur da, wo es auch Sinn macht.

und das ist nur dann, wenn die das übergebene objekt non-const ist oder bei opertatoren.

Ich benutze nicht eine total andere Sprache, um nachher doch die Features nicht zu nutzen.

aber benutze doch nicht jedes feature so oft es geht, nur weil es da ist.

Ich kauf mir ja auch nicht nen Ferrari, um damit so durch die Gegend zu fahren, wie ich es vorher mit meinem Roller gemacht habe.

das nicht. den ferrari kaufste natürlich, um zur disco zu fahren und eindruck zu schinden. dein fehler ist, daß du, weil du den ferrari jetzt hast, damit auch die brötchen holst, mit dem ferrari bierflaschen aufmachst und ihn als briefbeschwerer benutzt. und in deinem jugendlichen leichtinn, das sogar noch empfiehlst! das klingt so:

Ich benutze nicht eine total andere Auto, um nachher doch die Features nicht zu nutzen.

das ist dem ferrari gegenüber doch entwürdigend.

[THX 1138]

ööh..
ernst gemeinte frage:

also warunm soll man statt pointern referenzen benutzen? (ich mein nicht bei parameterübergabe)

habe mit c++ angefangen, und c grundlagen nur überflogen (typen, if/for strukturierungen, funktionen etc..). daher weiss ich auch gar nicht wo die gravierenden unterschiede sind, ausser die stl und die oop?
wenn man dann aber mit sdl/ogl arbeitet wird man fast verrückt, weil da die meisten alles in die main.cpp schreiben (tutorials und beispielcodes in forenbeiträgen).

ist das nun ein soll, ein kann oder ein muss, soviel wie möglich in eigene klassen zu packen?
und ist das performancetechnisch überhaupt sinnvoll?
eigentlich ist mir runtime wichtiger als entwicklungsdauer und aufwand

[GPC]

1310-Logik schrieb:

also warunm soll man statt pointern referenzen benutzen? (ich mein nicht bei parameterübergabe)

Sie sind syntaktisch einfacher und wir haben nicht das Problem/die Möglichkeit auf 0 testen zu müssen/können.

habe mit c++ angefangen, und c grundlagen nur überflogen (typen, if/for strukturierungen, funktionen etc..). daher weiss ich auch gar nicht wo die gravierenden unterschiede sind, ausser die stl und die oop?

spontan fallen mir z.B. noch templates ein^^ Es gibt noch mehr, geh einfach mal bei google oder wikipedia nachlesen.

wenn man dann aber mit sdl/ogl arbeitet wird man fast verrückt, weil da die meisten alles in die main.cpp schreiben (tutorials und beispielcodes in forenbeiträgen).

Schlecht.

ist das nun ein soll, ein kann oder ein muss, soviel wie möglich in eigene klassen zu packen?

Das nennt sich dann Datenabstraktion, davon sollte man reichlich gebrauch machen. Wenn du Klassen verwendest , wirst du bald merken, dass das Programmieren angenehmer wird.

und ist das performancetechnisch überhaupt sinnvoll?

ist es.

eigentlich ist mir runtime wichtiger als entwicklungsdauer und aufwand

ich habe gehört, Assembler soll schnell sein

MfG

GPC

[.filmor]

@artchi&volkard: Verdammt, muss dieser metaphorische Kram immer sein?

1310-Logik schrieb:

also warunm soll man statt pointern referenzen benutzen? (ich mein nicht bei parameterübergabe)

Weil sie nicht umlenkbar sind (was in vielen Fällen auch gar nicht benötigt wird) und für Polymorphie nutzbar sind. Sie sind also der äquivalente Ersatz für * const mit einer einleuchtenderen Syntax (nämlich der für normale Variablen). In anderen Fällen benutzt man natürlich Zeiger.

1310-Logik schrieb:

habe mit c++ angefangen, und c grundlagen nur überflogen (typen, if/for strukturierungen, funktionen etc..). daher weiss ich auch gar nicht wo die gravierenden unterschiede sind, ausser die stl und die oop?

Ersetze bitte STL durch "Standardbibliothek und Templates". Reicht das nicht? Aus diesen Zusätzen ergibt sich ein fast vollkommen anderes Design. Die einzigen Programmteile, die nach C aussehen, sind Implementierungen, aber die sind in der OOP nicht so wichtig wie der Entwurf.

1310-Logik schrieb:

ist das nun ein soll, ein kann oder ein muss, soviel wie möglich in eigene klassen zu packen?
und ist das performancetechnisch überhaupt sinnvoll?
eigentlich ist mir runtime wichtiger als entwicklungsdauer und aufwand

Die Klassen sind nur "übergestülpt", zur Laufzeit gibt es keine Typen mehr, sondern nur noch Daten bzw. Anweisungen. Daher ist der Performanceunterschied ohne Polymorphie praktisch 0, aber auch ansonsten dürfte er nicht viel größer ausfallen. Und ich bezweifle, dass in deinen Programmen alle Teile performancekritisch sind.
Spätestens wenn du dich an das Debugging machst oder neue Eigenschaften zum Programm oder der Bibliothek hinzufügen willst, wirst du dich an der OOP erfreuen. Aber niemand zwingt dich, alles in Klassen zu packen. Algorithmen z.B. werden in C++ (sinnvollerweise) immernoch als Funktionen implementiert. Es kommt auf den Einzelfall an.

[Mario Sandler]

Ganz meine Meinung!
Der Einzelfall entscheidet, lässt sich etwas gut in einer klasse darstellen (das ist gerade bei Grafikprogrammierung oft der Fall) mach ichs eben in ne klasse, wenn es aber nur en einfache funktion sein soll bracuh ich dafür keine klasse dann mach ich ne funktion. Wenns geht macht mans wenn nicht dann halt nicht.

Ich finde beide Programmierparadigmen "Strukuturiert" und "Objektorientiert" haben ihre Vor und Nachteile, jedoch verbietet es niemand diese auch mal zu mischen.

[DEvent]

aber benutze doch nicht jedes feature so oft es geht, nur weil es da ist.

und wieso nicht? Features sind da um benutzt zu werden. Sofern man natürlich nichts unnötig kompliziert macht.

Das Beispiel mit dem Ferrarie hinkt gewaltig.
Da müsste sich der Ferrarie plötzlich auf die Größe eines Briefbeschwerers schrumpfen wenn ich ihn als Briefbeschwerer benutze und plötzlich wieder zum Ferrarie mutieren wenn ich mit ihm in die Disco fahre.

[Blue-Tiger]

DEvent schrieb:

aber benutze doch nicht jedes feature so oft es geht, nur weil es da ist.

und wieso nicht? Features sind da um benutzt zu werden. Sofern man natürlich nichts unnötig kompliziert macht.

Ich glaub volkard wollte gerade darauf hinaus, dass man Features nur dann benutzt, wenn sie die Sachen einfacher machen und eben nicht benutzt, wenn sie die Dinge komplizierter machen.
z. B. mach ich ja auch nicht all meine Methoden virtuell, nur weil das Feature da ist Oder verwende auf Druck Referenzen, wenn Pointer den Code klarer machen.

Walli schrieb:

1310-Logik schrieb:

Ich les hier immer mal wieder, "C versaut Deinen C++ Stil!".

Gilt umgekehrt auch. Ich musste in einem Praktikum in der Uni heute mal wieder was in C machen und habe mich einige Male dabei ertappt, dass ich versuche C++ in C zu programmieren.

Ich glaub dass es gewisse Prinzipien gibt, die sich unabhängig von der verwendeten Sprache bewährt haben. z. B. "kein GOTO", Aufbrechen von Code in kleinere Funktionen oder eben Datenkapselung. Deswegen find ich's z. B. ok, wenn man C OO-mäßig programmiert, da es ein Schritt hin zu "besseren" Code ist, aber es wenn man C++ C-mäßig schreibt, ist das meistens ein Rückschritt.

1310-Logik schrieb:

habe mit c++ angefangen, und c grundlagen nur überflogen (typen, if/for strukturierungen, funktionen etc..). daher weiss ich auch gar nicht wo die gravierenden unterschiede sind, ausser die stl und die oop?

und OOP ist kein gravierender Unterschied? Ich wuerd sogar sagen er ist wesentlich! Da es allerdings oft so ist, dass größere C-Programme oft selbst sehr stark Objektbasiert geschrieben werden faellt das gar nicht so auf, nur hat C++ bessere Unterstuetzung fuer solches Design mit an Bord.

1310-Logik schrieb:

wenn man dann aber mit sdl/ogl arbeitet wird man fast verrückt, weil da die meisten alles in die main.cpp schreiben (tutorials und beispielcodes in forenbeiträgen).

Das liegt daran, dass es so einfacher ist, das wesentliche zu vermitteln. Wenn ich z. B. im Forum einfach eine lange Funktion poste, die all das zeigt was der Fragestellende wissen will, dann weil ich davon ausgehe, dass der schon selber weiss, wie er das am Besten in seinen Code und Stil anpasst. Ich will ja zeigen, wie dieses und jenes Problem geloest werden kann. Wie die z. B. das Klassendesign des Fragestellers aussieht und wie die Loesung da am besten reinpasst, MUSS er sogar selber entscheiden.

On a side note:
ich find "PDF-Dokument" absolut gültiges, gutes Deutsch. Ein Blatt, das grün ist, ist ein grünes Blatt. Wer Filme in MPEG codiert, hat eine MPEG-Codierung. Wer sein Dokument im PDF abspeichert, hat ein PDF-Dokument. Das zumindest ist meine Logik.
Außerdem ists immer toll sagen zu können "der ist doof, weil der nicht weiß wofür FooBarHyperTLA steht und es deshalb falsch verwendet". Im Endeffekt weiß aber jeder, was gemeint ist, wenn vom LCD-Monitor, von der OOP-Programmierung oder vom PDF-Format gesprochen wird. Jemand, der vom LC-Display, von der XM-Sprache oder vom PD-Format sprechen würde, den würd ich erstmal schief anschauen Deutsch ist nunmal eine lebendige Sprache, da geht Verwendbarkeit und Verstaendlichkeit nunmal vor formaler Korrektheit. Italiener verspotten die Deutschen ja auch nicht, weil die jetzt Spaghetti ohne "h" schreiben

[joomoo]

volkard schrieb:

Oder anstatt std::string dann doch lieber mit char-Arrays und strcmp und dem anderen Kram arbeiten, dann ist das für mich versaut.

oder anstatt char const* gleich strings in ihre schöüsselworttabele als std::map legen.

Also sollte man auch für konstante Zeichenketten allgemein immer const char* nehmen, oder? Das hab ich nähmlich noch nicht ganz verstanden.

mfg.