Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

DarthB

Treue Seele

Beiträge: 265

Beruf: Schüler

  • Private Nachricht senden

11

11.08.2003, 13:22

Also ich bin da zwar eher nicht so der Experte aber C++ wird intern bestimmt nicht in C übersetzt sondern direkt in ASM.
Auch mich kann man bei dieser Aussage vieleicht korrigieren.
Das structs in C++ eigentlich nur Klassen sind die alles Members public haben ist nartürlich richtig.

12

11.08.2003, 13:55

Zitat von »"DarthB"«

Also ich bin da zwar eher nicht so der Experte aber C++ wird intern bestimmt nicht in C übersetzt sondern direkt in ASM.

Das sagte zumindest mein Informatik Professor. Der gilt zwar als sehr kompetent aber auch Profs sind der Sage nach nur Menschen ;-) (Zumindest bei Vollmond *grins*)

Könnte auch so gemeint gewesen sein, daß die erzeugten Strukturen denen eines übersetzten C-Programms entsprechen (also ohne den expliziten Umweg über einen C-Source). Aber schlußendlich gibts es eh kein objektorientiertes ASM.

13

11.08.2003, 16:00

Zitat

intern wird nach meinem Wissen c++ sowieso in c übersetzt
Also ich glaub ja das du da den Prof gänzlich falsch verstanden hast. C++ wird nicht in C übersetzt. Beide Sprachen werden direkt in einen CPU freundlichen Code übersetzt, also in ASM.

Zitat

Das einzige was man den "structs" ankreiden kann ist, daß per Default alle Elemente public sind
Das kann man denen nicht ankreiden. Das liegt einfach daran, das sie zu den C Strukturen Kompatibel sein sollten.

Einige Optimierungen sind bestimmt Compilerabhängig. Aber was nicht Compilerabhängig ist, ist das man die Initialisierungsliste immer vorziehen sollte. Weil das Sprachspezifisch ist.
Wichtig! Ich übernehme keinerlei Verantwortung für eventl. Datenverlust oder Schäden am Rechner ;D

14

11.08.2003, 16:19

Zitat von »"DragonMaster"«

Zitat

intern wird nach meinem Wissen c++ sowieso in c übersetzt
Also ich glaub ja das du da den Prof gänzlich falsch verstanden hast. C++ wird nicht in C übersetzt. Beide Sprachen werden direkt in einen CPU freundlichen Code übersetzt, also in ASM.

sach ich doch (weiter unten im Thread :angel: Der meinte nicht explizit "C" sondern halt "nicht OOP"-Struktur). Ich wollte damit auch nur ausdrücken, daß OOP (und mit ihnen die Klassen) eine Sache der höheren Programmiersprachen sind und schlußendlich das ASM mit OOP nix mehr am Hut hat. Oder ist der Befehlssatz der CPUs mitlerweile auch objektorientiert - wäre mir völlig neu *grins*. Das meinte ich.

Zitat

Das kann man denen nicht ankreiden. Das liegt einfach daran, das sie zu den C Strukturen Kompatibel sein sollten.

ja schon klar. Daß sie in der OOP aber eventuell nicht so doll angesehen sind, liegt daran, daß sie gegen das Kapselungsprinzip verstoßen, ist ja alles öffentlich (auch die Eigenschaften) und das ist pfui!

Zitat

Einige Optimierungen sind bestimmt Compilerabhängig. Aber was nicht Compilerabhängig ist, ist das man die Initialisierungsliste immer vorziehen sollte. Weil das Sprachspezifisch ist.

Liegt das nicht daran, wie der Compiler Initialisierungsliste bzw. Constructor-Body in ASM übersetzt und optimiert oder eben nicht?

Fragen über Fragen???
Das Leben ist kein Spiel... Aber die Grafik ist geil!

15

11.08.2003, 17:04

Zitat

Liegt das nicht daran, wie der Compiler Initialisierungsliste bzw. Constructor-Body in ASM übersetzt und optimiert oder eben nicht?
Wenn man eine Struktur oder weitere Klasse als Eigenschaft hat, wird immer deren Standardkonstruktor aufgerufen, wenn man es nett anders angibt. So ist es in der Sprache festgelegt.

Eigentlich ist es ja auch so das immer ein Standard-, Kopier- und Destruktor vom Compiler automatisch erzeugt wird, wenn man keine selber Definiert. Diese sind natürlich leer. In einem solchen fall kann es natürlich sein, das hier von einem Konstruktoraufruf, in der Initialisierungsliste, abgesehen wird.
Wichtig! Ich übernehme keinerlei Verantwortung für eventl. Datenverlust oder Schäden am Rechner ;D

16

11.08.2003, 17:17

Reden wir aneinander vorbei??? Nochmal das Beispiel von Oben:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// ##################################
// Methode 1
class Klasse 
{ 
public: 
    Klasse() 
    {
        Var1 = 0; 
        Var2 = 0;
    } //Standardkonstruktor 

private: 
        int Var1; 
        int Var2; 
}; 

// ##################################
// Methode 2
class Klasse 
{ 
public: 
    Klasse(void) : Var1 (0), Var2 (0)
    {
    } //Standardkonstruktor 

private: 
        int Var1; 
        int Var2; 
}; 

Der Unterschied liegt doch nur darin an welcher Stelle ich die Zuweisungen an var1 und Var2 mache. Ob nun aus der Initialisierungsliste eine einfache Zuweisungsoperation gemacht wird (vor dem eigentlichen Constructor-Header) oder ob da ein superduper schneller ASM-Code draus wird liegt doch an der Implementierung des Compilers??? Is ja auch beide Male der Standardkonstruktor, aber halt ein selber geschreibener nicht ein vom compiler erzeugter.

Lerne immer gern dazu

P.S. lieber Haare als Atome spalten }>
Das Leben ist kein Spiel... Aber die Grafik ist geil!

Werbeanzeige