Stilfrage

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

[.filmor]

const char* != char const*, aber ja. Allerdings sollte in unserer aufgeschlossenen, internationalisierten Welt nur noch wenig Text fest einkodiert sein.
Was volkard mit diesem Beispiel meinte, sehe ich aber auch nicht ...

[joomoo]

.filmor schrieb:

const char* != char const*

Huh? Wo besteht der Unterschied? Gibt es nicht nur einen Unterschied zwischen const char* und char* const?

mfg.

[.filmor]

Dann hab ich das wohl verwechselt, danke. Jetzt ergibt das alles einen Sinn

[joomoo]

.filmor schrieb:

Dann hab ich das wohl verwechselt, danke. Jetzt ergibt das alles einen Sinn

Ich hab's leider noch nicht verstanden. Soll ich jetzt const char* anstatt const std::string nehmen?

mfg.

[.filmor]

Nur, wenn der gespeicherte Text zur Compilezeit bekannt ist. std::string ist immer dynamisch, legt also eine (dann sinnlose) Kopie des Strings an.

[joomoo]

.filmor schrieb:

Nur, wenn der gespeicherte Text zur Compilezeit bekannt ist. std::string ist immer dynamisch, legt also eine (dann sinnlose) Kopie des Strings an.

Und was bewirkt das const dann vor dem std::string?

mfg.

[.filmor]

Das bewirkt, dass das std::string Objekt konstant ist, der gespeicherte Text also nicht nachträglich veränderbar ist. Das ändert aber nichts an der Tatsache, dass eine Kopie erstellt wird. Das gleiche gilt für std::vector <-> Arrays fester Größe.