|
Boost : |
Subject: Re: [boost] Request for Interest in several Modules
From: Artyom Beilis (artyomtnk_at_[hidden])
Date: 2012-01-10 15:15:44
>
> 1. The boost::extension author reported (when i asked him) a lack in the
> C++11 standard (without precision) that makes it hard to implement
> correctly this library on all platforms/compilers (unfortunately he didn't
> say which ones).
> Do you have any information about that?
>
I don't exactly understand what is the problem.
You create an entry factory point like
extern "C" {
foo* bar();
}
Resolve bar withing shared object/dll and it works 100%
As long as you don't mix runtimes i.e. dll and main program uses
different heaps and so on there is no problems I'm aware of.
> 2. booster::shared_object::shared_object(std::string const & file_name )
>
> Here file_name is a path, right?
> I'm guessing it's relative to the way the OS will look for modules?
Actually it is quite same on Unix and Windows.
A name without "path" like "foo.so" it searches withing general path,
on windows .:$PATH and on Unix under predefined set
of locations + LD_LIBRARY_PATH.
If full/relative path provided it searches according to it.
>
> 3. Is there a specific reason that there isn't a provided abstraction
> (template "helper" function) that will call resolve_symbol() and try
> (dynamic or not) to cast it for you to the provided type? My understanding
> is that you wanted to let the user do as he wish but I was asking myself if
> common usage could be identified and provided by default.
There is a helper function that helps to cast void * to
function pointer.
Genrally any plugin/so/dll should have its entry point like
shown above and implement some known interface.
What would do the job.
It is more abstraction of dlopen/dlsym rather then generic
interface to map anything you want need dynamically.
>
> Thanks!
>
> Joël Lamotte
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk