Malloc oder C++-Standard

[_matze]

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

[copynator]

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

[_matze]

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!

[Nexus]

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.

[_matze]

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.

[copynator]

ohne groß drüber nachzudenken:

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

geht bestimmt noch schlauer.

[Tachyon]

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.

[_matze]

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

[Tachyon]

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

[it0101@loggedoff]

_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

[_matze]

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!

[Genau]

it0101@loggedoff schrieb:

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

[Nexus]

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.

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.

[Tachyon]

it0101@loggedoff schrieb:

[...]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.

[Tachyon]

Nexus schrieb:

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]

Nexus schrieb:

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.

[Nexus]

copynator schrieb:

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.

[_matze]

Nexus schrieb:

copynator schrieb:

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.

Genau, ist nicht eindeutig, und so habe ich es auch nicht gemeint! Trotzdem ist die Performance-Frage grundsätzlich ein interessanter Aspekt.

[Nexus]

_matze schrieb:

Trotzdem ist die Performance-Frage grundsätzlich ein interessanter Aspekt.

Und vielleicht ausnahmsweise mal ein berechtigter.

Naja, einigen wir uns darauf, unter C++ möglichst viele STL- und Boost-Container zu verwenden.

[copynator]

Nexus schrieb:

Ich dachte, mit "umkopieren" werde schon auf die Performance angespielt...

bei realloc weißt du vorher nicht, ob kopiert wird oder nicht. im schlechtesten fall ist realloc auch nur ein malloc+memcpy.
mein doofes renew ist zwar vermutlich langsamer als ein handelsübliches realloc, funktioniert dafür aber auch in c++.