[extension] library under construction status

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[extension] library under construction status

lcaminiti
Hello all,

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

P.S. I read the docs and I have a couple of comments:

1. shared_library as RAII
Why isn't shared_library an RAII object? If there's a good reason for
that, a RAII object should also be provided scoped_library that will
open at construction and automatically close at destruction.

2. get should use function type syntax
get<result_type, arg1_type, arg2_type, ...> should be changed to
get<result_type (arg1_type, arg2_type, ...)>

3. type_map purpose/name
The introduction of type_map seems arbitrary... some rationale needs
to be provided as soon as it's introduced in Tutorial 2. Is there a
better name than type_map? That name tells me little about what it
is.. maybe, factory_map given that it's a map strings to factories?

4. call(type_map)
lib.call(type_map) the name call is too generic, it should be changed
to set or even better get_factories:

type_map types;
if(!lib.call(types)) ...

Changed to:

factory_map factories;
if(!lib.get_factories(factories)) ...

5. type_map doesn't allow for multiple constructors
type_map doesn't allow for derived classes to have constructors with
different signatures than the base class. It also doesn't allow for
classes (derived or base) to have multiple constructors. In any case,
the syntax should use member function types, changing the current
syntax:

std::map<std::string, factory<animal, int> >...

to:

std::map<std::string, factory<void (*::animal)(int)>

6. I didn't understand parameter_map purpose, usage, etc :(

Thanks.
--Lorenzo

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [extension] library under construction status

Klaim - Joël Lamotte
On Mon, Apr 1, 2013 at 7:34 PM, Lorenzo Caminiti <[hidden email]>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
>


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-td4282212.html
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.

Also, note that some people/companies seem to have used Boost.Extension
without any problem so if you want to use it it might be good enough for
your use.
But in the same time, if you don't like the design, I guess you'll have to
wait for an improvement or another library or propose yours (maybe based on
this one).

That was a short summary of the situation.

Joel Lamotte

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [extension] library under construction status

Artyom Beilis
----- Original Message -----

> From: Klaim - Joël Lamotte <[hidden email]>
> To: Boost Developers List <[hidden email]>
> 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
> <[hidden email]>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-td4282212.html
> 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/

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [extension] library under construction status

Klaim - Joël Lamotte
On Tue, Apr 2, 2013 at 3:55 PM, Artyom Beilis <[hidden email]> wrote:

> > 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)


To be more precise, what I'd like to know is: are you currently or soon
working on
proposing the libraries cited in the link to boost through the official
review process or not?
I understand that indeed a user could just extract your work from cppcms.

Joel Lamotte

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