[Lumen]

Als Buch würde ich C++ für Spieleprogrammierer empfehlen.

Können hochperfomante Spiele oder sogar Anwendungen mit einer reinen objektorientierten Sprache erzeugt werden?
Nein, deshalb besitzt C++ als Zwittersprache sowohl die guten alten C-Datentypen wie int, float, usw. und moderne objektorientierte Klassen wie CInt, CDouble, usw.
Nur OO-Puristen und OO-Fanatiker benutzen in Schleifen CInt als Zähler.
Der Hinweis von Firefox64 auf C ist kein Unsinn oder Schwachsinn, weil es unglaublich viel C-Code im Netz gibt, die man in ein C++-Projekt einbinden kann.

http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html

Dass alle, die hier auf Firefox rumhacken, C++-Nerds sind, ist schon klar, weil sie sich nur in Templates äußern, eine Instanzierung ihrer Vorstellungen in konkrete Objekte z.B. Links auf Online-Tutorials oder Schüler-C++ bzw. Informatiker-C++-Projekte erhält man nicht.

Posts als Vererbung von class GOOGLE

[gosha16]

Zitat von Lumen

C++-Nerds sind, ist schon klar, weil sie sich nur in Templates äußern, eine Instanzierung ihrer Vorstellungen in konkrete Objekte z.B. Links auf Online-Tutorials oder Schüler-C++ bzw. Informatiker-C++-Projekte erhält man nicht.

Ich bin "C"ler, ich benutze so gut wie nie C++ und wenn es doch nötig ist dann lagere ich den C++ Code in ein eigenes Projekt aus und erzeuge eine (dynamische) Bibliothek.

Ganz davon abgesehen das man nicht 100% des C Codes aus dem Netz einfach in sein C++ Projekt übernehmen kann. Es sind halt doch 2 verschiedene Programmierpsrachen mit unterschiedlichen Standards.

[gosha16]

Ok, ich kenns nur von Bekannten und Podcasts ausländischer Unis und von meiner Berufsschule, da wird alles anhand von Delphi erklärt, ok da wurden auch nicht alle vorzüge von Prozedural und OO durchexerziert. (Bei uns werden auch keine Anwendungsentwickler ausgebildet.)
Ich find es aber nach wie vor bedenklich erst C zu lehren und dann C++. Das ist meines erachtens nach unschöner als C++ für beides herzunehmen, denn grade in C++ fällt es kaum auf.

[harbok]

Der wohl grösste Vorzug der OOP ist die unglaubliche Stärke und Flexibilität im Design.

Programmieren hat in erster Instanz aber mal nichts mit eben jener Softwareentwicklung oder -design zu tun. Ein Anfänger sollte lernen, wie er der Maschine klarmacht, was sie zu tun hat, wie er den Kontrollfluss manipuliert, verzweigt, selektiert, iteriert - das Übliche halt. Dafür sind prozedurale Sprachen weit geeigneter als eine OOP-Sprache prozedural umzukrempeln.

Ich finde C oder PASCAL eine gute Wahl für eine erste Sprache. Nach C sollte aber meiner Meinung nach nicht C++ folgen, weil das zu fiesem Mischcode führt, da Anfängern oft nicht klar ist, welches Element nun in welche Sprache gehört. In einer Anfängergruppe in C++ prozedural oder schlimmer noch C zu schreiben kommt einer Dämonenbeschwörung gleich

[Lumen]

Ein Anfänger sollte lernen, wie er der Maschine klarmacht, was sie zu tun hat, wie er den Kontrollfluss manipuliert, verzweigt, selektiert, iteriert - das Übliche halt. Dafür sind prozedurale Sprachen weit geeigneter als eine OOP-Sprache prozedural umzukrempeln.

Sehe ich genau so.
Dass 65535+2 != 65537 sondern = 1 in der Computerwelt sein kann, führte zur Sprengung einer Ariane-Rakete, weil ein Programmierer über die Änderung der Flugbahn nicht informiert wurde und den Code nicht modifizierte, so dass es zu einem Überlauf des Wertebereichs einer Variablen kam.

Rundungsfehler sind ein weiteres Problem in der Prozessoren-Welt.

Nach C sollte aber meiner Meinung nach nicht C++ folgen

C++ hat viele fiese Fallstricke, die Mehrfachvererbung war so unglücklich, dass man sie in Java nachher weggelassen hat.

Auch der Kopierkonstruktor hat es in sich:

#include <cstdio>
class Datei
{
public:
Datei( char *name )
{
f = std::fopen( name, "wt" );
}
~Datei() { if( f ) fclose( f ); }
void schreibe( char *txt )
{
if( f )
fprintf( f, txt );
}
private:
std::FILE *f;
};
// ...
void f( Datei d )
{
d.schreibe( "Eine Zeile Text.\n" );
}

int main()
{
Datei d( "test.txt" );
f( d );
d.schreibe( "Und noch eine Zeile\n" );
return 0;
}

Was geht hier schief?

[harbok]

Dein Aufruf

f( d );

erzeugt eine shallow copy, da Du nur mit einer Referenz aufrufst, schreibt dann seinen String, ruft am Ende der Funktion den Destruktor für die shallow copy auf, der wiederrum schließt das File und in der nächsten Zeile in Deiner main()

d.schreibe( "Und noch eine Zeile\n" );

fliegst Du gegen die Wand, weil das File längst geschlossen wurde.


Wenn ich daneben liege, dann brauche ich einen Compiler, weil ich sonst nichts Falsches sehe.

[Lumen]

fliegst Du gegen die Wand, weil das File längst geschlossen wurde

Richtig.

weil ich sonst nichts Falsches sehe.

Auch richtig.

Der Urheber dieses Skripts empfiehlt, dass man den Kopierkonstruktor private machen soll, damit keine Wertekopie erzeugt werden kann.

private:
std::FILE *f;
// in privater Sektion verstecken!
Datei( const Datei & );

[harbok]

Hmm, ich würde einfach mit einem ptr arbeiten. Das braucht kein neues Objekt auf dem Stack, keinen Kopiervorgang und muss auch keinen Destruktor aufrufen.

Simpler und schneller m.E..