For anyone who is interested in boost.DLL, as a user, implementor, reviewer
or just curious, I encourage them to look at ACE DLL. ACE has been there,
done that.
I know that ACE code looks horrible due to its age and the need to support
ancient compilers, and there are ugly macros all over the place. However,
ACE has solved this problem so I think developers that want to solve the
problem again should look at how it has been done before.
For example, I see from the boost.DLL example that the entire pathname,
including any OS-specific suffixes etc, is supplied to the ctor. ACE takes
a different view and it is instructive to look at the comments in the code
to see why. I am thinking of different versions of UNIX in particular and
how they handle shared libraries differently.
ACE has also thought about shared library lifetimes quite thoroughly and
caters for a lifetime that might be greater than the immediate object that
is doing symbol lookup for example. This is in the DLL_Manager class.
On 5 October 2014 23:45, Mathias Gaunard
On 05/10/2014 23:56, Gavin Lambert wrote:
On 6/10/2014 06:23, Mathias Gaunard wrote:
Personally, I only use C functions in my ABI, but if we ever wanted to make this standard-proof, it would need to have no such restrictions.
Given that neither C++ mangling nor any other details of the C++ ABI are standardised (AFAIK), I don't think anything involving C++ *could* be standard-proof.
I'm talking about a possible submission to the standard library. There is no need to specify a mangling ABI to specify a standard library for this.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
-- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk