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.

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

Falsch.

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.

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.

Naja, die Frage ist nun: Wieso sollte man ein solches dynamisches Arrays benutzen, wenn man STL Container hat?

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

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.

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!

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.

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.

T* renew(oldmem, oldcount, newcount)
{
    newmem = new T[newcount];
    std::copy(...)
    delete [] oldmem;
    return newmem;
}

geht bestimmt noch schlauer.

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 new mit den C-Funktionen arbeiten muss? Im Standard steht, das es unspezifiziert ist.

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 new mit 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...

[...]

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.

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

_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!

_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

Jap super Idee. Wenn man dann mal nach einer Zeit mit C++ anfängt wundert man sich warum das nicht mehr so funktioniert wie vorher und man erst nach Jahren lernt, dass es bereits für das C-Gefrickel fertige, sichere Alternativen gibt. Smartpointer z.B.

ohne groß drüber nachzudenken:
[...]
geht bestimmt noch schlauer.

Aber da hat man wieder den gleichen Performancenachteil gegenüber realloc() , da das ganze Array zerstört und neu aufgebaut wird.

Tachyon schrieb:

Oben wurde es als Fakt dargestellt, dass new intern mit malloc arbeitet.

Wenn wir gerade bei Haarspaltereien sind: So etwas habe ich niemals behauptet (meinst du jemand anderen?). Ich kann mir schon vorstellen, dass new und delete intern anders implementiert sind, zumal ja malloc() , realloc() und free() intern auch andere Routinen - womöglich vom Betriebssystem - aufrufen. Ich selber kenne jedoch keine Alternativen, deshalb würde es mich ja wundern, wie.

[...]Wenns nach mir ginge müssten alle mit ANSI-C anfangen

Und das ist völliger Blödsinn. Bei den meisten Programmierern hapert es schon am Design. Wenn sich solche Programmierer dann noch mit den Problemchen der Programmiersprache rumschlagen müssen, kommt es zum Eklat.
Es ist viel wichtiger, ordentlich abstrahieren zu können als zu wissen, wo jedes einzelne Bit in der CPU landet.

Aber da hat man wieder den gleichen Performancenachteil gegenüber realloc() , da das ganze Array zerstört und neu aufgebaut wird.

Anders geht es aber nicht, wenn es eine Anforderung ist, dass der Speicherblock zusammenhängt. Dafür arbeitet die Variante aber korrekt mit nichttrivialen Objekten.

Nexus schrieb:

So etwas habe ich niemals behauptet (meinst du jemand anderen?).

Naja, Du hast es so dargestellt, als dass es ohne C-Funktionen nicht geht.

Wahrscheinlich wird in vielen Fällen wirklich einfach nur malloc aufgerufen, aber es gibt, wie Du ja sagtest, auch die Möglichkeit, direkt über das OS zu gehen.

copynator schrieb:

ohne groß drüber nachzudenken:
[...]
geht bestimmt noch schlauer.

Aber da hat man wieder den gleichen Performancenachteil gegenüber realloc() , da das ganze Array zerstört und neu aufgebaut wird.

ich kann dir nicht ganz folgen. es hat doch niemand was von performance gesagt? es geht darum, dass es funktioniert, nicht dass es schnell oder schön wäre.

es hat doch niemand was von performance gesagt? es geht darum, dass es funktioniert, nicht dass es schnell oder schön wäre.

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

Ich dachte, mit "umkopieren" werde schon auf die Performance angespielt... Ist zwar hier nicht ganz eindeutig, aber das (hier negativ ausgedrückte) Kopieren wird oft mit der Schwere der Operation assoziiert.