Malloc oder C++-Standard

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

[hustbaer]

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.

WENN man eine Implementierung hat bei der realloc überhaupt *jemals* einen bestehenden Block vergrössern kann. Bei vielen optimierten Allocator-Implementierungen geht das schonmal in 99% der Fälle garnicht, und wird daher auch gleich garnicht versucht.

malloc/realloc/free zu verwenden nur weil realloc eventuell manchmal wenn das Wetter stimmt und der Weihnachtsmann grad gute Laune hat etwas schneller sein könnte halte ich für Unfug.

[asc]

it0101@loggedoff schrieb:

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

Was hindert einen daran nach den Containern noch Grundlagenwissen zu lernen?

it0101@loggedoff schrieb:

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

Also würdest du einen der Japanisch lernen will erstmal Chinesisch vorschreiben, da Japanisch einige der Zeichen übernommen hat?

C++ ist so schon schwer genug, um nicht auch noch Funktionen lernen zu müssen die man später nicht mehr einsetzt.
Ich habe nichts dagegen wenn sich Interessierte anschließend noch nach dem Einsatz der Containerklassen auch mal mit deren Aufbau beschäftigen. Nicht jeder der einen Computer käuft möchte ihn selbst zusammenstecken - später erkundigt man sich vielleicht darüber wie man ihn erweitert, und lernt dann etwas zum Aufbau, aber erstmal geht es um das Verwenden.

cu André