On Thursday, 6 February 2014 at 08:38:57 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 6 February 2014 at 08:06:54 UTC, Paulo Pinto wrote:
That won't play ball with third party libraries distributed in
binary form.
That is not obvious, you specify the runtime. Anyway, whole
program analysis also does not play well with binary libraries
without detailed semantic metadata.
So what do you do when different libraries require different
runtimes?
To be more specific to my previous comment. Objective-C GC
required special compilation flags and care needed to be taken in
GC enabled code, like in C GCs.
This did not played well when mixing code that used the GC
enabled runtime, with code that did not.
Thus the endless causes of core dumps in Objective-C code that
made use of the GC.
The Apple decision to create ARC and dump the GC wasn't because
it is better as they later sold it, but because the compiler
inserts for the developer the usual [... retain]/[... release]
calls that they were already writing since the NeXT days.
So no distinct runtimes were required as the generated code is no
different than an Objective-C developer would have written by
hand.
This was the best way to achieve some form of automatic memory
management, while preserving compatibility across libraries
delivered in binary form.
Does shared_ptr in C++11 work with binary libraries that use
it, if the it is compiled with a compiler from another vendor?
As far as I am aware, no.
In any case there isn't a standard C++ ABI defined. Well, there
are a few, but vendors don't use them.
