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.