ich habe in einer Klasse einen privaten Member:

void* m_pvBuffer;

initialisieren geht so...

m_pvBuffer = (void*) new uint8[(int) qwMemBytes];

löschen so...

delete ((uint8) m_pvBuffer);

Lösche ich denn so alle Elemente des Array's oder nur eins?

Gruss

2. Warum ist dein Typ void* und nicht uint8*?

3. Warum willst du dich überhaupt manuell um die Speicherverwaltung kümmern? Schau dir mal std::vector bzw. std::array an.

Michael E. schrieb:

1. Wenn du zum Allozieren new[] benutzt, musst du biem Löschen auch delete[] schreiben (mit den Klammern).

2. Warum ist dein Typ void* und nicht uint8*?

3. Warum willst du dich überhaupt manuell um die Speicherverwaltung kümmern? Schau dir mal std::vector bzw. std::array an.

Da ich nicht so ganz allein am Code arbeite, wegen des uint8* werde ich das mal anmerken.
Aber das delete[] ist exakt das was ich gesagt habe. Weil ohne Klammern nicht alle Elemente des Arrays gelöscht werden.

In einer neuen Version werde ich Vector nutzen!

Danke

Franky

Da ich nicht so ganz allein am Code arbeite...

Das scheinen ja alle Helden der Programmierung zu sein wenn ihr dieses Problem nicht intern lösen konntet.

Sorry, aber das musste ich loswerden.

Da ich nicht so ganz allein am Code arbeite, wegen des uint8* werde ich das mal anmerken.

Wozu sollen die ganzen Casts da überhaupt gut sein? Sieht jedenfalls ziemlich wirr aus.

test.cpp:10:20: error: cast from ‘void*’ to ‘uint8_t {aka unsigned char}’ loses precision [-fpermissive]
test.cpp:10:24: error: type ‘uint8_t {aka unsigned char}’ argument given to ‘delete’, expected pointer

Was ist das denn für ein Compiler, der sowas akzeptiert?

Sämtliche Casts in deinem Beispiel kannst du ersatzlos wegstreichen. Zumindest unter der Voraussetzung, dass "qwMemBytes" ein für diese Verwendung geeigneter Typ ist, aber davon gehe ich einfach mal aus, sonst wäre das ja noch deutich perverser und wird auch durch noch so viele Casts nicht besser.

FrankTheFox schrieb:

Da ich nicht so ganz allein am Code arbeite...

Das scheinen ja alle Helden der Programmierung zu sein wenn ihr dieses Problem nicht intern lösen konntet.

Sorry, aber das musste ich loswerden.

Tja, alte Programmierer ( 15 Jahre C-Programmiererfahrung und einige sogar einen "Dr.") und die Ansicht C++ ist nur ein bisschen mehr C, also wenn der Code läuft, warum dann ändern denn so läuft es ja...

Und die "qwMemBytes" sind eigentlich uint64.

Greetz

ich glaube das die sich auf den g++ als Compiler geeinigt haben, tja und dann kann mann auch hier und da C++ machen. Ist auch viel moderner...
Sei's drum kann ich nicht ändern.

Greetz

Tja, alte Programmierer ( 15 Jahre C-Programmiererfahrung und einige sogar einen "Dr.") und die Ansicht C++ ist nur ein bisschen mehr C, also wenn der Code läuft, warum dann ändern denn so läuft es ja...

Und die "qwMemBytes" sind eigentlich uint64.

Greetz

Sorry, aber da ist alt und C auch kein Argument. Der Code war auch vor 15 Jahren in C schlecht.

Dann schreibt doch lieber gleich in C. Ganz ehrlich, warum sollte man C++ nutzen, wenn RAII nicht sitzt? Macht einfach keinen Sinn.

OOP. Schonmal gehört? Meinjanur.

cooky451 schrieb:

Dann schreibt doch lieber gleich in C. Ganz ehrlich, warum sollte man C++ nutzen, wenn RAII nicht sitzt? Macht einfach keinen Sinn.

OOP. Schonmal gehört? Meinjanur.

Man kann in C OOP machen. Insbesondere wenn man keine Polymorphie braucht ist das kein Problem. Mit geht es auch. Siehe zB gtk+.

Und wenn man lernresistente C Programmierer hat kommt mir das durchaus sinnvoll vor.

Das für mich entscheidende bei c++ ist RAII und wenn man das eh nicht macht, kann man es sich gleich sparen.

Man kann in C OOP machen. Insbesondere wenn man keine Polymorphie braucht

Der war gut.

Das für mich entscheidende bei c++ ist RAII und wenn man das eh nicht macht, kann man es sich gleich sparen.

Na zum Glück hat Bjarne Stroustrup damals anders gedacht.

...
Und wenn man lernresistente C Programmierer hat kommt mir das durchaus sinnvoll vor.

...

Davon haben wir in unserer Firma reichlich, sogar lernresistente Assemblerprogrammierer, einer z.B. programmiert seit 20 Jahren in 8086 Assembler und weiss nicht, das bereits der 8086 rep mov besitzt, hat dies immer mit loop gelöst. Oder das der 8086 bereits 1MB Speicher addressieren kann, die haben immer gedacht, er kann nur 128KB. .

Das für mich entscheidende bei c++ ist RAII und wenn man das eh nicht macht, kann man es sich gleich sparen.

Na zum Glück hat Bjarne Stroustrup damals anders gedacht.

...?
Und dass Bjarne Stroustrup damals RAII nicht so wichtig war, ist der Grund, dass C++ RAII perfekt unterstützt? Oder wie?

Und dass Bjarne Stroustrup damals RAII nicht so wichtig war, ist der Grund, dass C++ RAII perfekt unterstützt? Oder wie?

Was soll ich denn darauf jetzt antworten? Am besten nichts.