Wie viele bytes ist ein class?
-
StreamKid schrieb:
ist es so? und wenn es so ist, wie gross sind diese "anderen sachen"?
Die "anderen Sachen" sind bei ganz normalen Klassen ohne virtuelle Funktionen und virtuelle Vererbung nur die Basisklassenobjekte und vielleicht noch ein paar Padding-Bytes.
StreamKid schrieb:
noch ein beispiel:
in ein tcp/ip packet,
die informationen die wir mochten(der int) sind zb 1,5kb..
aber, das packet ist 1,7kb.. das heisst: in diesen 0.2kb sind andere informationen gespeichert(tcp/ip headers -> andere informationen fur das objekt)...IP-Pakete haben mal sowas von gar nichts mit C++-Klassen/Objekten zu tun...
-
Vic schrieb:
Sicherlich,
ich vermute mal, dass man die Größe eines Objektes (jetzt ohne pointer etc) immer gleich bleibt, und dass die Information über die Klassenstruktur separat gesichert wird.
Laut meinen Infos entspricht ein longlong int auf einem 32 Bit System (ohne longlong 232)
einem int auf einem 64 Bit System(264)Bin mir aber nicht sicher
-
Vic schrieb:
ich vermute mal, dass man die Größe eines Objektes (jetzt ohne pointer etc) immer gleich bleibt, und dass die Information über die Klassenstruktur separat gesichert wird.
Wie meinen? Informationen über die Klassenstruktur existieren nach dem Kompilieren praktisch nicht mehr! Und deshalb ist auch die Größe eines Objektes (und die Position und Größe dessen Member) einer Klasse immer gleich, sonst würden viele Dereferenzierungen ins Nirwana gehen.
Digger182 schrieb:
Laut meinen Infos entspricht ein longlong int auf einem 32 Bit System (ohne longlong 232)
einem int auf einem 64 Bit System(264)long long ist kein Standard. Die Größen der integralen Datentypen sind eh nicht wirklich festgelegt, es gilt so weit ich weiß nur immer sizeof (char) == 1 =< sizeof(short) =< sizeof(int) =< sizeof(long). Zeigergrößen sind davon unabhängig (aber immer gleich, abgesehen von Methodenzeigern).
-
sizeof(ex) gibt bei mir auf einem 64bit System genau 4 aus.
Also keine Paddings.
-
WTF, kein Padding bei genau einem Member
Sachen gibts 
-
Tja unglaublich, aber wahr

-
.filmor schrieb:
Vic schrieb:
ich vermute mal, dass man die Größe eines Objektes (jetzt ohne pointer etc) immer gleich bleibt, und dass die Information über die Klassenstruktur separat gesichert wird.
Wie meinen? Informationen über die Klassenstruktur existieren nach dem Kompilieren praktisch nicht mehr! Und deshalb ist auch die Größe eines Objektes (und die Position und Größe dessen Member) einer Klasse immer gleich, sonst würden viele Dereferenzierungen ins Nirwana gehen.
Digger182 schrieb:
Laut meinen Infos entspricht ein longlong int auf einem 32 Bit System (ohne longlong 232)
einem int auf einem 64 Bit System(264)long long ist kein Standard. Die Größen der integralen Datentypen sind eh nicht wirklich festgelegt, es gilt so weit ich weiß nur immer sizeof (char) == 1 =< sizeof(short) =< sizeof(int) =< sizeof(long). Zeigergrößen sind davon unabhängig (aber immer gleich, abgesehen von Methodenzeigern).
Der Standard macht keine Aussagen über die Größe von Zeigern. Es ist plausibel anzunehmen, das Zeiger auf verschiedene Objekte mit gleichen Alignment-Voraussetzungen die gleiche Größe haben, aber selbst das dürfte nicht zwingend gefordert sein.
-
Ich glaube mal die Frage zielte darauf ob ein class irgendeinen overhead hat.
Normalerweise ist das nicht der Fall.
Hast du jedoch eine virtuelle Funktion (z.B. auch virtueller destructor) schleppt jede Instanz halt noch den Pointer auf sein virtelle function table mit.
-
Bezüglich dieses Themas sollte man sich auch mit dem Begriff POD auseinandersetzen. Der Artikel Speicherverwaltung in C++ (und C) von CStoll ist auch recht interessant.
-
generell gilt zu beachten was für ein System etc. Warum auch ein long double nicht immer ein long double ist

Warum manchmal Zeiger größer sind als der Reine Wert der eigentlich gespeichert wird etc. Es hängt einfach vom verwendeten System ab.
Wenn ich in einen 64 Bit System zeiger auf ints speichere ist das ziemlich blöd. Weil der Zeiger ja 64 Bit breit ist und der int selber nur 32

Aber wer wird denn so auf solchen overhead achten? Vor allem bei den Vorteilen der OOP? Ob meine klasse nun 2 oder 10 byte braucht ist mir relativ egal. Solange sie das tut was sie soll. Wenns wirklich ums byte feilschen geht ist OOP dann eh nicht mehr so angebracht.
-
Naja gerade was padding bytes angeht muss man immer aufpassen. Siehe nur ein einfaches Beispiel:
struct TestGross { char a; long b; char c; long d; char e; long f; }; struct TestKlein { long a; long b; long c; char d; char e; char f; }; int _tmain(int argc, _TCHAR* argv[]) { std::cout << sizeof(TestGross) << std::endl; //24 bei mir std::cout << sizeof(TestKlein) << std::endl; //16 bei mir return 0; }und auch die paar bytes für den pointer auf den vtable sind manchmal nicht zu verachten.