Boost logo

Boost :

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

Aleksander Demko <ademko <at>> 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
* 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at