ZFX + Developia

Generell gilt es ja als guter Stil, in C++ immer new statt malloc zu verwenden, auch wenn es nicht um Objekte, sondern um primitive Typen geht, immerhin könnte ja mal wer auf die Idee kommen und den new-operator zu überladen und plötzlich müsste man den malloc-Code per Hand anpassen.

Ich habe hier nun den Sonderfall, dass eine C++ Bibliothek Daten auf den Heap anlegt und diese an eine C-Bibliothek weiterreicht und umgekehrt auch für der C-lib allozierte Daten bekommt. Die C-Bibliothek hat nun aus diversen Gründen ein recht unsauberes Speichermanagement, sprich, teilweise muss die Bibliothek der aufrufenden Funktion Speicher allozieren und die der aufgerufenen gibt ihn wieder frei, teilweise andersherum.

Kann ich den C++ Code hier überhaupt problemlos new verwenden lassen?
Wenn irgendwer mal den new-operator global mit einem nicht zu malloc kompatiblen Speichermanagement überlädt, dann habe ich doch auch bei primitiven Typen ein ernsthaftes Problem, wenn new mit free und malloc mit delete freigegeben wird?

Auch in diesem Fall gilt wie immer: Speicher IMMER mit derselben API freigeben, mit der er reserviert wurde. Überlässt dir eine Bibliothek einen Speicherbereich, welcher mit malloc angefordert wurde, so ist die EINZIG richtige Lösung, diesen mit free freizugeben. Übernimmt eine Bibliothek die Inhaberschaft eines Speicherbereichs, den sie später mit free freigeben wird, so ist die EINZIG richtige Lösung, diesen von vorneherein mit malloc anzufordern.

Wie CodingCat völlig richtig gesagt hat, ist die einzige Option, genau den gleichen Speichermanager wie die C-Bibliothek – ansonsten bekommst du gröbere Probleme, wenn du jemals einen anderen Allocator einsetzen solltest.

Vergiss auch nicht, dass du new mit zusätzlichen Parametern überladen kannst. Also z.B. new (LibraryXYZBound) LibClass(); – dann ist es wumpe, wer operator new (ohne zusätzliche Parameter) überschreibt.

Es muss nicht nur der gleiche Speichermanager sein, sondern sogar derselbe.

Wenn du oder die externe C-Lib statisch gegen ihre Runtime linken, hat jeder von euch einen eigenen Heap und eine eigene Heap-Verwaltung. Wenn du also dein free() aufrufst um einen von einem fremen malloc allozierten Speicherblock freizugeben … nunja, es koennt wehtun. Bei dynamischer Linkage (oder wenn die C-Lib statisch einkompiliert wird), besteht dieses Problem nicht.

… aber trotzdem: aus genau diesem Grund sind strikte Ownership-Semantiken Pflicht fuer C/C++ Bibliotheken die den Anspruch erheben, tatsaechlich praktisch einsetzbar zu sein :-)

Krishty hat geschrieben:Vergiss auch nicht, dass du new mit zusätzlichen Parametern überladen kannst. Also z.B. new (LibraryXYZBound) LibClass(); – dann ist es wumpe, wer operator new (ohne zusätzliche Parameter) überschreibt.

Interessant, wusste ich gar nicht ,dass man da Parameter übergeben kann.

Aramis hat geschrieben:Es muss nicht nur der gleiche Speichermanager sein, sondern sogar derselbe.

Wenn du oder die externe C-Lib statisch gegen ihre Runtime linken, hat jeder von euch einen eigenen Heap und eine eigene Heap-Verwaltung. Wenn du also dein free() aufrufst um einen von einem fremen malloc allozierten Speicherblock freizugeben … nunja, es koennt wehtun. Bei dynamischer Linkage (oder wenn die C-Lib statisch einkompiliert wird), besteht dieses Problem nicht.

… aber trotzdem: aus genau diesem Grund sind strikte Ownership-Semantiken Pflicht fuer C/C++ Bibliotheken die den Anspruch erheben, tatsaechlich praktisch einsetzbar zu sein :-)

Gut, dass die C Lib statisch in die C++ Lib einkompiliert wird, das kann ein Spaß werden, wenn sich das mal ändern sollte. Habe da schon viel Arbeit reingesteckt, das quasi nicht vorhandene Speichermanagement aller "wer zuerst drauf zugreift, alloziert den Kram, wer zuletzt drauf zugreift, gibt ihn frei, aber nirgends steht, wer wann zuständig ist und wer den Kram wie lange braucht, wer wann davon ausgeht, dass er ihn freigeben kann, usw." auf Vordermann zu bringen, aber das ist irgendwie eine unendliche Geschichte., man findet doch immer wieder was...