Malloc oder C++-Standard

[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é

[pumuckl]

realloc in C++ halte ich grundsätzlich für keine gute Idee.

1. wie hustbaer schon geschrieben hat ists fraglich ob es überhaupt einen Vorteil gegenüber malloc + memcopy + free hat (also ob und wie häufig es vorkommt dass der bestehende Speicherblock tatsächlich verlängert werden kann)
2. wird wenn das nicht gerade häufig vorkommt UND der Profiler mir sagt dass das ein wichtiger Performance-Punkt ist der vielleicht-unter-umständen-mal-möglich-Vorteil durch einige Nachteile wieder wettgemacht:
   - nicht einheitlich -> schwerer zu lesender Sourcecode
   - ich stelle im Laufe der Entwicklung fest dass ich grundsätzlich meine eigene Speicherverwaltung haben möchte, also überlade ich operator new und delete. Fertig. Ach nee, ich muss ja noch über alle Sourcen greppen und meine Aufrufe von malloc und free durch new und delete ersetzen, weil die natürlich nicht auf meinen selbst implementierten Speicherverwalter zugreifen. So ein Mist, hätt ich das doch gleich gemacht...
   - ich stelle im Laufe der Entwicklung fest, dass ich die ints die ich an vielen Stellen benutzt hab durch eine kleine Klasse ersetzen sollte. Ich ersetz also die entsprechenden Variablendeklarationen (oder den entsprechenden typedef wenn ich so schlau war einen zu machen) und fertig. Ach nee, ich muss ja noch über alle Sourcen greppen und meine Aufrufe von malloc und free durch new und delete ersetzen, weil malloc/free natürlich nicht die Konstruktoren meiner Klasse aufrufen. So ein Mist, hätt ich das doch gleich gemacht...

[hustbaer]

Jo.
Wenn man realloc möchte weil Mr. Profiler sagt das viel Zeit beim Resizen von Vektoren draufgeht, dann sollte man IMO eher nachdenken ob es nicht eine Möglichkeit gibt das Resizen ganz zu verhindern.
Oft kann man schon früh ganz gut abschätzen wieviel Speicher man braucht oder es sogar genau ausrechnen.
Wenn nicht kann vielleicht eine andere Datenstruktur helfen.