Malloc oder C++-Standard
-
Alóha,
ich muss für ein Zeiger vom Datentyp 'unsigned char*' neuen Speicher
reservieren. Frage ist jetzt ob über Malloc oder einfach über new, die
Frage ist jetzt, ob es genau die selbe Auswirkung hat. Sprich:
(Malloc)bitmapImage = (unsigned char*)malloc(bitmapInfoHeader->biSizeImage);..., und:
bitmap_Image=new unsigned char[o_Bitmap.InfoHeader.biSizeImage];(Ist im Übrigen aus meinem Bitmap-Decoder)
Wie schon gefragt, haben die beiden Zeilen die gleiche Auswirkung?
Danke im Voraus.
-
So:
#include <vector> //... std::vector<unsigned char> bitmapImage(o_Bitmap.InfoHeader.biSizeImage);Zur Frage:
Ja, in diesem Fall sind die Auswirkungen gleich. Für Klassen gilt das allerdings nicht, da bei malloc/calloc der Konstruktor der Klassen nicht ausgeführt wird, und somit Klassen nicht korrekt erzeugt werden.
Daher in C++ immer mit new arbeiten, wenn man denn mal unbedingt damit arbeiten muss.
-
der einzige unterschied, ist die art und weise auf die der speicher wieder frei gegeben werden muss.
-
vlad_tepesch schrieb:
der einzige unterschied, ist die art und weise auf die der speicher wieder frei gegeben werden muss.
Falsch.
-
vlad_tepesch schrieb:
der einzige unterschied, ist die art und weise auf die der speicher wieder frei gegeben werden muss.
Aber nur in einen so einfachen Fall wie hier (Tachyon hat ja schon geschrieben warum man in C++ eigentlich new/delete verwenden sollte).
cu André
-
Auch, wenn ich bestimmt gleich geschlagen werden, aber ich verwende in bestimmten Fällen gerne [x]alloc, da realloc so praktisch ist und es bei der new/delete-Methode eben kein Äquivalent dafür gibt.
-
_matze schrieb:
Auch, wenn ich bestimmt gleich geschlagen werden, aber ich verwende in bestimmten Fällen gerne [x]alloc, da realloc so praktisch ist und es bei der new/delete-Methode eben kein Äquivalent dafür gibt.
Nenn mal ein Beispiel, wo Du es sinnvoll einsetzt...
-
Na ja, jedesmal, wenn du ein dynamisches Array resizen willst (und es sich nicht gerade um Klasseninstanzen handelt), ist realloc sehr praktisch, da man halt nicht umkopieren muss wie bei new. Natürlich sind Container-Klassen aus der STL oder MFC die bessere Alternative, aber wenn man sich in einem solchen Fall zwischen new/delete und malloc/calloc/realloc entscheiden soll, dann würde ich definitiv letzteres wählen.
-
_matze schrieb:
Na ja, jedesmal, wenn du ein dynamisches Array resizen willst (und es sich nicht gerade um Klasseninstanzen handelt), ist realloc sehr praktisch, da man halt nicht umkopieren muss wie bei new. Natürlich sind Container-Klassen aus der STL oder MFC die bessere Alternative, aber wenn man sich in einem solchen Fall zwischen new/delete und malloc/calloc/realloc entscheiden soll, dann würde ich definitiv letzteres wählen.
Naja, die Frage ist nun: Wieso sollte man ein solches dynamisches Arrays benutzen, wenn man STL Container hat?
-
Tachyon schrieb:
_matze schrieb:
Na ja, jedesmal, wenn du ein dynamisches Array resizen willst (und es sich nicht gerade um Klasseninstanzen handelt), ist realloc sehr praktisch, da man halt nicht umkopieren muss wie bei new. Natürlich sind Container-Klassen aus der STL oder MFC die bessere Alternative, aber wenn man sich in einem solchen Fall zwischen new/delete und malloc/calloc/realloc entscheiden soll, dann würde ich definitiv letzteres wählen.
Naja, die Frage ist nun: Wieso sollte man ein solches dynamisches Arrays benutzen, wenn man STL Container hat?
Mir ist schon klar, worauf du hinaus willst, und du hast im Grunde ja auch Recht. Ich muss aber auch viel C programmieren und bin an realloc gewöhnt. Da mach ich's halt auch manchmal in C++. Und eines sollte man nicht vergessen: realloc mindert ja nicht automatisch die Qualität/Stabilität eines Programms! Wer damit umzugehen weiß, schreibt ähnlich stabilen Code wie mit STL-Containern. Worin wir aber übereinstimmen, ist vermutlich, dass man C**++**-Anfängern am besten gar nicht von realloc erzählen sollte...
P.S.: Ich habe doch gesagt, dass ich geschlagen werde...

-
_matze schrieb:
realloc sehr praktisch, da man halt nicht umkopieren muss wie bei new.
ob umkopiert werden muss oder nicht, liegt (genauso wie bei std::vector) nicht in deiner hand. du musst es nur nicht explizit machen.
aber wenn man sich in einem solchen Fall zwischen new/delete und malloc/calloc/realloc entscheiden soll, dann würde ich definitiv letzteres wählen.
ich hingegen würde weiterhin new benutzen, und mir ein funktionierendes renew inkl. kopieren selber schreiben. aber nur wenn mich jemand mit waffengewalt von std::vector fernhält.
-
copynator schrieb:
ob umkopiert werden muss oder nicht, liegt (genauso wie bei std::vector) nicht in deiner hand. du musst es nur nicht explizit machen.
Richtig, so meinte ich das auch!
-
copynator schrieb:
ich hingegen würde weiterhin new benutzen, und mir ein funktionierendes renew inkl. kopieren selber schreiben.
Würde mich mal interessieren, wie du das machst, ohne intern auf die C-Funktionen zuzugreifen.

-
Nexus schrieb:
copynator schrieb:
ich hingegen würde weiterhin new benutzen, und mir ein funktionierendes renew inkl. kopieren selber schreiben.
Würde mich mal interessieren, wie du das machst, ohne intern auf die C-Funktionen zuzugreifen.


-
ohne groß drüber nachzudenken:
T* renew(oldmem, oldcount, newcount) { newmem = new T[newcount]; std::copy(...) delete [] oldmem; return newmem; }geht bestimmt noch schlauer.
-
Nexus schrieb:
copynator schrieb:
ich hingegen würde weiterhin new benutzen, und mir ein funktionierendes renew inkl. kopieren selber schreiben.
Würde mich mal interessieren, wie du das machst, ohne intern auf die C-Funktionen zuzugreifen.

Wer sagt, das
newmit den C-Funktionen arbeiten muss? Im Standard steht, das es unspezifiziert ist.
-
Tachyon schrieb:
Nexus schrieb:
copynator schrieb:
ich hingegen würde weiterhin new benutzen, und mir ein funktionierendes renew inkl. kopieren selber schreiben.
Würde mich mal interessieren, wie du das machst, ohne intern auf die C-Funktionen zuzugreifen.

Wer sagt, das
newmit den C-Funktionen arbeiten muss? Im Standard steht, das es unspezifiziert ist.Richtig, aber soweit ich weiß, machen es die meisten Implementierungen (z.B. MS) so...
-
_matze schrieb:
[...]
Jo, aber es geht auch ohne. Oben wurde es als Fakt dargestellt, dass new intern mit malloc arbeitet. Dem ist aber nicht zwangsläufig so.
Juhu, ich liebe diese Haarspaltereien, auch wenn ich bei sowas manchmal deneben liege und ordentlich eins auf den Deckel bekomme.
-
_matze schrieb:
Wer damit umzugehen weiß, schreibt ähnlich stabilen Code wie mit STL-Containern.
Hunderprozentige Zustimmung!
_matze schrieb:
Worin wir aber übereinstimmen, ist vermutlich, dass man C**++**-Anfängern am besten gar nicht von realloc erzählen sollte...
Seh ich anders: Die Anfänger heutzutage die sehen nur die fertigen Container... Aber was wirklich dahinter steckt weiß kaum noch einer...
Zauberkiste STL-Container
Wenns nach mir ginge müssten alle mit ANSI-C anfangen

-
Tachyon schrieb:
_matze schrieb:
[...]
Jo, aber es geht auch ohne. Oben wurde es als Fakt dargestellt, dass new intern mit malloc arbeitet. Dem ist aber nicht zwangsläufig so.
Juhu, ich liebe diese Haarspaltereien, auch wenn ich bei sowas manchmal deneben liege und ordentlich eins auf den Deckel bekomme.
Ok, lustige Diskussion, aber ich verabschiede mich jetzt mal. Ich lese lieber solch vielfach gespaltene Haare, als dass ich mich daran allzu eifrig beteilige... Ich hab nämlich schon ein wenig auf den Deckel bekommen! 