Array richtig löschen?



  • Hi,

    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



  • 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.



  • Hi,

    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



  • Warum castest du in uint8 und nicht uint8* ?



  • Könnte man nicht auch mit Konstruktoren die gewünschten Werte initialisieren bzw
    wäre das nicht sogar vorteilhafter?



  • 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.



  • FrankTheFox schrieb:

    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.



  • Entschuldigt das Doppelposting, aber ich muss da doch nochmal was nachfragen: Macht dir der Compiler da nicht die Hölle heiß, wenn du solchen Code schreibst? Der GCC will sowas nichtmal kompilieren, Clang ebenso wenig.

    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.



  • EOP schrieb:

    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



  • Mein Beileid.



  • Danke!!



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



  • Hi,

    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



  • Wäre ich euer Chef, würde ich euch alle rausschmeißen 🤡



  • Ich auch!!!!!!! Und dann wäre ich Chef!! 😃



  • FrankTheFox schrieb:

    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.



  • 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.



  • Bashar schrieb:

    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.



  • AppleFan schrieb:

    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.



  • AppleFan schrieb:

    ...
    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. 😃 😃 .



  • Bashar schrieb:

    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? 😕


Anmelden zum Antworten