Meshloader macht Probleme

[KN4CK3R]

sizeof(zeiger) = 4 != 12
Der reinterpret_cast beim Lesen/Schreiben würde mich bei einem POD Datentyp nicht sonderlich stören.

greetz KN4CK3R

[Makro?]

Bob Wolfskin schrieb:

int main()
{

	ofstream out("model.gsm",ios::out|ios::binary);

        Vertex v[3];

	// ...

	out.write(reinterpret_cast<char*>(&v),sizeof(Vertex) * ARRAYSIZE(v) );

	// ...

Jo, moin!
Wie is'n ARRAYSIZE definiert? (Und warum?)

[Bob Wolfskin]

Okey hab jetzt reinterpret_cast gegen (char*)&blah ersetzt.
ARRAYSIZE is ein Macro was angibt wieviel Elemente ein array hat ( hier 3 Stück )

Ich wundere mich einfach warum dasm it dem Array pointer nicht geht, was nicht so gut ist, da ich später zum ausfüllen Puffers ein solches dynamisches Array brauche.

Die Frage ist warum folgendes verschiedene größen angibt.

int _num = 3;
Vertex* a = new Vertex[_num]; // das sind jetzt 3 Stück je 4 Bytes
cout << sizeof(a) << endl; // Größe des Arrays
cout << sizeof(Vertex) * 3 << endl; // Die richtige Größe jedoch größer als das Array

Müsste ja eigendlich Vertex = 4 Bytes -> * 3 = 12 Bytes müssten es sein aber wenn ich Vertex* a= new Vertex[3]; erstelle bekomme ich nur 4 Bytes (liegt vieleicht daran dass die nicht ausgefüllt sind ?? )

[Makro?]

Bob Wolfskin schrieb:

Die Frage ist warum folgendes verschiedene größen angibt.

int _num = 3;
Vertex* a = new Vertex[_num]; // das sind jetzt 3 Stück je 4 Bytes
cout << sizeof(a) << endl; // Größe des Arrays
cout << sizeof(Vertex) * 3 << endl; // Die richtige Größe jedoch größer als das Array

Die Antwort ist:

sizeof(a) == sizeof(Vertex*) // a ist ein Vertex*

[Bob Wolfskin]

Aber durch die Instanzierung werden doch 3 Elemente reserviert oder icht ?

[Makro?]

Bob Wolfskin schrieb:

Aber durch die Instanzierung werden doch 3 Elemente reserviert oder icht ?

Ja, aber die Information über die Größe des Arrays ist nicht über 'a' zu erreichen.
Die musst Du irgendwie mitschleppen.

PS: Der Compiler ist Dir hier klar im Vorteil, weil der nämlich die Größe für delete [] a; wieder auslesen kann...

[SeppJ]

Es gibt da so eine Klasse in der Standardbibliothek, die die Größe mitschleppt und sich automatisch um das new und delete kümmert....

[pumuckl]

Bob Wolfskin schrieb:

Aber durch die Instanzierung werden doch 3 Elemente reserviert oder icht ?

Dadurch wird der Pointer selber aber nicht größer. Nur der reservierte Speicher, auf den er zeigt.

Makro? schrieb:

Der Compiler ist Dir hier klar im Vorteil, weil der nämlich die Größe für delete [] a; wieder auslesen kann...

Streng genommen ist das nicht der Compiler, aber ich hab heute schon genug Haare gespalten

SeppJ schrieb:

Es gibt da so eine Klasse in der Standardbibliothek, die die Größe mitschleppt und sich automatisch um das new und delete kümmert....

Kschsch. Du willst hier doch niemanden zu sauberem C++ verführen, oder?

[Makro?]

pumuckl schrieb:

Makro? schrieb:

Der Compiler ist Dir hier klar im Vorteil, weil der nämlich die Größe für delete [] a; wieder auslesen kann...

Streng genommen ist das nicht der Compiler, aber ich hab heute schon genug Haare gespalten

Fiel mir auch auf, aber:
Ohne Registrierung keine Editierung...

[Bob Wolfskin]

Ich könnte das ganze auch folgenderweise machen:
(Wird jedoch nicht auf dem Stack sondern auf dem Heap verbleiben)

Vertex *v = (Vertex*)malloc(sizeof(*v));
new (v) Vertex();  //oder so ähnlich

Dabei wird direkt der Speicherbereich reserviert
Ist aber vollkommen unnötig

[SeppJ]

Nenn mal einen einzigen Vorteil von malloc/placement new gegenüber "normalem" new und einen einzigen Vorteil von new genenüber std::vector.

[Kellerautomat]

SeppJ schrieb:

Nenn mal einen einzigen Vorteil von malloc/placement new gegenüber "normalem" new

Man kann reallozieren.

[SeppJ]

Kellerautomat schrieb:

SeppJ schrieb:

Nenn mal einen einzigen Vorteil von malloc/placement new gegenüber "normalem" new

Man kann reallozieren.

Nicht, wenn du einen Konstruktor brauchtest, denn dann geht eine eventuelle Verschiebung schief.