| > But that requires acknowledgement of a fact that there is no "single, global C runtime". On Windows, yes, giving rise to situations where you have a dynamic library and the program using it, linked against two different C runtimes. On a Unix like OS you usually have a single, global libc. You would have to deliberately link it statically into a shared library, or a program that uses a shared library, to create a similar situation. For the standard C use case, if the library malloc()s something and passes the result pointer to the program, the program itself has no way to free it. The two have their own, independent copies of the allocation code that don't share the allocation arena. If the program calls free(), the best case scenario is that the libc of the program realizies it doesn't recognize the pointer, yells "double free" and abort()s. That's a bit of a portability pit-fall and definitely something one has to consider when designing a library ABI. Pointers returned from the library have to be passed back into the library to free the underlying memory. A solution like the one used by Delphi is required. (For polymorphic objects being passed around, you would typically have something like a destroy() hook anyway). I'm a bit hesitant to make a guess on what happens in the case of a C++ smart pointer. Technically they can have an allocator, but does that cross the ABI bounds? Is there a template specialization for optimizing it away if you are using the default delete operator? I guess the compiler of the program could also end up instantaiting the programs allocator when inserting the template parameters? |