Boost logo

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