Objektgröße einer Klasse??
-
BorisDieKlinge schrieb:
Nehmen wir an... ich habe eine Klasse mit 2 int membervariablen, und 100 Memberfunktionen mit jeweils 200 zeilen code! wenn ich nun eine Instanz dieser Klasse erzeuge, wie groß ist diese dann im speicher?
100 memberfunktionen.. uups
-
nur mal angenommen... sind natürlich keine 100 methoden...:)
-
class Foo { private: int a,b; public: void bar() {} };entspricht ziemlich genau
struct Foo { int a,b; }; void bar(Foo* const this) { }
-
ghorst schrieb:
also eine klasse ohne virtuelle funktionen (auch nicht in einer mutterklasse) sollte exakt so groß sein, wie die summe ihrer data-memeber inklusive aller ererbten.
Naja, fast - technisch spielt da noch das Padding eine Rolle, wodurch die Klasse etwas größer werden kann.
-
in den meisten fällen, sollte da wohl kein "werden kann" sondern "wird" stehen. nur ist es unüblich die größe eines datentypes inklusive padding anzugeben. also zumindest ich habe noch nirgendwo gelesen, dass ein char 4byte groß ist.
-
ghorst schrieb:
also zumindest ich habe noch nirgendwo gelesen, dass ein char 4byte groß ist.
Ja, ein Datentyp alleine hat kein Padding, sondern erst im Zusammenspiel mit seinen Nachbarn. D.h. char hat Größe 1, int (z.B.) Größe 4 - und ein struct{char c;int i} kommt je nach Padding auf 5 bis 8 Byte.
-
das ist so nicht ganz richtig. auch datentypen außerhalb von structs werde mit einem padding versehen, so sie nicht auf die bevorzugten grenzen fallen, was bei allen datentypen deren größte ungleich der align-größe bzw. einem ganzzahligen vielfachen davon der fall ist. daher ist auch ein einzelnes char auf einem pc üblicherweise 4 byte groß.
-
Nein, ein char ist ein Byte groß (wieviel Bit das sind, wird allerdings freigestellt) und muß in der Lage sein, den Speicher lückenlos zu füllen - und wenn du nur char's hast, werden die auch ohne Padding in die struct gepackt. Erst bei größeren Datentypen wie int wird der Compiler zwischen Platz und Aufwand (bei einem falsch ausgerichteten int braucht er zwei Speicheraufrufe und muß den Wert dann noch zusammensetzen) entscheiden müssen - und da setzt er dann Padding-Bytes vor das int, um es sauber ausrichten zu können.
-
ghorst schrieb:
auch datentypen außerhalb von structs werde mit einem padding versehen, so sie nicht auf die bevorzugten grenzen fallen...
ja, das ist manchmal so, aber trotzdem liefert 'sizeof' hier die grösse ohne die lückenfüller, aber wenn sizeof auf structs angewendet wird, werden diese mitgezählt.
CStoll schrieb:
und wenn du nur char's hast, werden die auch ohne Padding in die struct gepackt.
nicht unbedingt. bei char-arrays hast du recht, aber einzelne 'chars' können in einer struct auch 'gepaddet' werden.
-
CStoll schrieb:
Nein, ein char ist ein Byte groß (wieviel Bit das sind, wird allerdings freigestellt) und muß in der Lage sein, den Speicher lückenlos zu füllen - und wenn du nur char's hast, werden die auch ohne Padding in die struct gepackt.
hier irrst du. es wird häufig tatsächlich billigend in kauf genommen, das keine vollständigen speicherbereiche genutzt werden. du kannst deinen compiler zwingen, das er sich anders verhält, bzw. bei großen menge an chars würde er es hoffentlich auch von selbst machen, allerdings verlierst du dann sogar bei char laufzeit, da sie dann an der unpassende stelle im register ankommen bzw. der speichercontroller sie erst umsortieren muss.
bei char[] gilt das natürlich nicht. hier wird tatsächlich wie bei allen anderen arrays und den packed structs auch, nur der tatsächlich benötigte bereich + abschluß-padding reserviert, damit es wieder mit zu dem alignment passt.
-
Nehmen wir an... ich habe eine Klasse mit 2 int membervariablen, und 100 Memberfunktionen mit jeweils 200 zeilen code! wenn ich nun eine Instanz dieser Klasse erzeuge, wie groß ist diese dann im speicher?
jenach dem
z.B.
2*4 + 100*4 = 408 bytes
-
Häh?
Selbst bei virtuellen Funktionen wird _ein_ Zeiger auf die vtable gespeichert.
Also:
2*4 + 1*4 = 12 Byte // ohne Padding.408 Byte wär ein bisschen heftig...
