Re: [boost] [extension] library under construction status

----- Original Message -----

From: Klaim - Joël Lamotte To: Boost Developers List Cc: Sent: Monday, April 1, 2013 8:50 PM Subject: Re: [boost] [extension] library under construction status

On Mon, Apr 1, 2013 at 7:34 PM, Lorenzo Caminiti wrote:

...

What's the status of Jeremy Pack's library under construction Boost.Extension?

AFAIK it's on hold since several years. Last time I asked Jeremy Pack about it, he allowed me to post his answer in this mailing list, which I did at the time, in 2011. I'm reporting the answer here again:

Unfortunately, some of the C++11 stuff did not go the way I needed it to.

...

The linking guarantees it provides are not strong enough to provide for consistent shared library behavior across platforms. Many tasks that work just fine with certain compiler/platform combinations break horrifically on others. One example is being able to call the constructor in one shared library and the destructor in another shared library for an object, which only works on certain platforms.   This and other serious issues can cause bizarre bugs for users whose code looks perfectly natural. Resolving these issues would result in a very complicated and inelegant API, and a complete rewrite of the library. I won't have time to do any of this work for quite some time, as I am currently a full-time software engineer and part-time student. I'm sorry for the bad news!   Jeremy  

Actually it is not "that bad" situation. There have never been a problem in calling destructor in form example main part and constructor in SO/DLL. There is one limitation that is strict by clear once you understand what do you do: The shared object/dll should use **the same runtime** as the main executable. I mean if the main executable is linked statically with a run time library that for example performs allocations or it used different version  (MSVCRT10.DLL and MSVCRT10D.DLL) than you would have problems and this has nothing to do with loading libraries dynamically on runtime or  loaded when executable starts (i.e. linked with them directly) Actually in CppCMS we do very complex things like reloading shared objects and dlls in runtime upon update, the global constructors and descructors registering the factories to the main application such that you can easily query a list of modules etc. It is not as complicated as it looks like.

On related info, Artyom Beilis (CPPCMS, boost.Locale and other libs author) did this post: http://boost.2283326.n4.nabble.com/Request-for-Interest-in-several-Modules-t... Where he propose a "shared object" library that would provide basic dll/so cross-platform support. However from the discussion on this thread I understand that: 1. you need to use extern C to define factory functions; 2. you need to new and delete your objects inside the same dll; I'm not sure about the usage as I didn't work with it so it might be too minimalist in some cases but I'd have to test in my own context to be sure.

Maybe Artyom can comment on what's the status of his library? It was only a poll of interest not a library submission.  

It was mostly a small poll of interest. In general the implementation is  quite simple if not trivial. Just a wrapper of dlopen/dlclose and LoadLibrary (Close something don't remember what)

[snip]  Joel Lamotte

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

  Artyom Beilis -------------- CppCMS - C++ Web Framework:   http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/