[boost] Re: additional boost libraries?

From: Sven Van Echelpoel (sven.van.echelpoel_at_[hidden])
Date: 2004-07-20 11:48:20

Aleksander Demko <ademko <at> shaw.ca> writes:

> 
> I, like billions of other developers, have a medium sized project
> that for various reasons, invented its own thread, io, etc
> libraries. I'm thinkin of switching over to boost stuff for all my
> utility needs, but I'm wondering if boost has/possibly will have/is
> open to the possibility of adding/ or will never have the following
> facilities:
> 
>  serialization/object persistance (via iostreams)
>  network socket iostreams
>  UUID stuff (sometimes know as GUIDs)
>  interface to dlls/.so loading
>  url parsing (something like the filesystem lib)
> 
> and, just out of curiosity:
>  xml/html parsing
> 
> Thanks in advance.
> 
> --
Hi Aleksander,

>  interface to dlls/.so loading

As it so happens, I just started working on such a beast last week. I'm still 
in the experimentation/concept phase. These are the use cases I definitely 
want to support:

* cross platform loading (by name) and using of symbols (functions/PODs) 
* handling of optional OS functionality (e.g. binding at runtime to OS API 
functions that aren't available in all versions of the target OS)

Since I'm only experimenting I did not pay too much attention yet to the 
interface, but I'm thinking along these lines:

* a simple interface to load a library by name or path and query the address 
of symbols by name
* a boost::function-like type that can bind to a function at runtime and call 
it
* a scoped_ptr or smart_ptr-like type that can bind to exported PODs at runtime

One thing I'm currently experimenting with is automatic decoration based on a 
symbol's signature and qualified name. Currently I already have these 
decorators (for MSVC):

* plain: no decoration
* stdcall: decorating function names with the __stdcall calling convention
* fastcall: decorating function names with the __fastcall calling convention
* char_type: decorating a function by appending 'W' (in UNICODE builds) 
or 'A', for binding to Windows API calls
* combined: a decorator that tries any combination of decorators to find the 
function to bind to
* cdecl: (a work in progress) decorates a name using the compiler's name 
mangling scheme

The last decorator is the most ambitious and potentially the least portable. 
I'm still pursuing it because it can result better portability of user code.
Consider the following example of the loading plugins from a shared library:

std::vector< boost::shared_ptr<IPlugin> >
LoadPlugins( std::string piLib ) {

import::function< std::vector< boost::shared_ptr<IPlugin> >()>

GetPluginList( "SomeApp::_3rdParty::GetPluginList", piLib );

std::vector< boost::shared_ptr<IPlugin> > plugins = GetPluginList();

return plugins;

}

Using only the function signature and the qualified name of the exported 
function the user could bind to the exported function on every supported 
compiler, without having to resort to workarounds like extern "C" functions 
that suppress name mangling, but also prohibit the use of non-POD types.

To improve the portability all decorators are composed of base decorators that 
can be combined to form more complex ones. Furthermore I think I can come up 
with a tool that (for a lot of compilers) generates the base decorators by 
analysing a map file produced by compilig and linking a source file with known 
function names/signatures.

Even so, it will obviously not be possible to port all of the functionality of 
the library to all compilers/platforms. The basic interface should be highly 
portable however.

Since this is a rather ambitious project and I can only work on it a couple of 
hours a week (at most), it will take quite a while to finish. But if you're 
interested, I can keep you updated.

Svenne.
>