Admittedly there are times I use expat (SOAP parsing) and times I use Apache (Xalan XPath parsing)... It would be really nice to have a friendlier interface to XPath support, as XPath expressions are being increasingly incorporated into web service messaging specifications. On Jul 20, 2004, at 6:18 AM, Vladimir Prus wrote:

Hi Aleksander,

...

serialization/object persistance (via iostreams)

It's about to appear in 1.32:

http://boost-consulting.com/boost/libs/serialization/doc/index.html

...

network socket iostreams UUID stuff (sometimes know as GUIDs) interface to dlls/.so loading

This is something I'd be interested to as well (including writing the code). What specifically do you need from such a library? Something like:

boost::dll plugin("foo"); plugin["bar"].as<void (void)>();

or something trickier, like:

- calling C++ functions:

plugin.call<void (void)>("bar") -- no need for "extern "C"

- some auto-registraction mechanisms

plugin_registry<CodeGenerator> plugins; plugins.load("foo"); plugins.load("bar");

plugins["i386"].run(.......)

...

and, just out of curiosity: xml/html parsing

None so far. In fact, it seems unlikely that somebody will come along and implement all the XML stack (DOM, XPath, XML Schema, XSTL, whatever) right now. One chance would be is somebody boostify some existing XML toolkit -- but which one?

Another chance is to initially create "tiny XML" library. In fact, both regression tools and serialization have their own tiny XML parsers and users aksed about XML support for program_options, so such library might really be usefull.

- Volodya

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

David Abrahams wrote:

Vladimir Prus <ghost@cs.msu.su> writes:

...

boost::dll plugin("foo"); plugin["bar"].as<void (void)>();

or something trickier, like:

- calling C++ functions:

plugin.call<void (void)>("bar") -- no need for "extern "C"

- some auto-registraction mechanisms

plugin_registry<CodeGenerator> plugins; plugins.load("foo"); plugins.load("bar");

plugins["i386"].run(.......)

Those are some really cool DSEL ideas! I love it!

Thanks! The problem is that to implement the coolest of them: plugin.call<void (void)>("bar") I'd need a C++ mangler for all platforms, and after initial look at just gcc name mangling spec I feel a bit scared. The first syntax should work in all cases, though. - Volodya

John Torjo wrote:

David Abrahams wrote:

...

Vladimir Prus <ghost@cs.msu.su> writes:

...

boost::dll plugin("foo"); plugin["bar"].as<void (void)>();

or something trickier, like:

- calling C++ functions:

plugin.call<void (void)>("bar") -- no need for "extern "C"

I love this! It would really be great!

How about something like plugin.func<void(void)>("some_func") returning a callable functor - some wrapper over boost::function,

I think last message from Sven even suggests the syntax were you get boost::function. And you don't need a wrapper, BTW, you can just bind function to a functional object which can do what you ask below

which - will work as long as the plugin is in memory - will throw otherwise

Isn't it better to always keep the plugin in memory?

- eventually have a method for knowing if you can still call this function

Ah... this would need some wrapper over boost::function indeed. - Volodya

I'd certainly have uses for this.

Best, John

Pavel Vozenilek wrote:

...

or something trickier, like:

- calling C++ functions:

plugin.call<void (void)>("bar") -- no need for "extern "C"

- some auto-registraction mechanisms

plugin_registry<CodeGenerator> plugins; plugins.load("foo"); plugins.load("bar");

plugins["i386"].run(.......)

You may take look on polymorphic_map (in Boost.Files section). It is work in progress but useable and can serve as base for advanced object factory.

Maybe, though in case of plugins classes are identified by names, not by they real types -- since the types are generally unknown in the caller. Speaking about the library itself, I'd really prefer if it were in sandbox -- I had no idea it exists. Ideally, it would be nice to have some "CVS digest", like: http://cvs-digest.org/index.php?issue=jul162004 to facilitate cooperation. For example, I was interested in polymorphic map where the keys do no have to derived from common base. I even think boost_sandbox/filesytem has some code like that. Bringing this all together would be good. - Volodya

On Tue, 20 Jul 2004, Vladimir Prus wrote:

...

interface to dlls/.so loading

This is something I'd be interested to as well (including writing the code). What specifically do you need from such a library? Something like:

boost::dll plugin("foo"); plugin["bar"].as<void (void)>();

I currently use a very slim wrapper around around dlopen() and the similar Win32 facility. Ofcourse, this requires big-hammer reinterpret casts, but my needs are very simple. Basically, my "plugs" export (extern "C") some kind of entry/registration function that my main app calls on load. The code is here: http://scopira.org/api/classscopira_1_1tool_1_1dll.html And could be a basis for a boost endevour. More C++/demangling/complex stuff could build on the basic symbol loading class... -- // scopira.org | ninjacoder.com //

On Tue, 20 Jul 2004, Jeff Garland wrote:

00004 * 00005 * All rights reserved. 00006 * 00007 * This material is confidential and proprietary information of 00008 * National Research Council Canada ("Confidential Information"). 00009 * This Confidential Information may only be used and reproduced 00010 * in accordance with the terms of the license agreement. 00011 * 00012 */

Seems to me this code shouldn't be posted on an open website.

That's our standard boiler plate header -- the app is released under the GPL. Besides, that's like a 20 line wrapper around dlopen and friends. There's only so many ways one can implement that. However, for any boost versions, recoding would be trivial and probably best. -- // scopira.org | ninjacoder.com //

On Tue, 20 Jul 2004, Angus Leeming wrote:

http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket

Hugo Duncan opened a sourceforge project http://giallo.sourceforge.net to push this forward but the last commits were three months ago.

Excellent. So that means it's done I take it :) -- // scopira.org | ninjacoder.com //

On Tuesday 20 July 2004 15:40, Jeff Garland wrote:

On Tue, 20 Jul 2004 01:19:33 -0500 (CDT), Aleksander Demko wrote

...

and, just out of curiosity: xml/html parsing

There have been various discussions of this, but I'm not aware of a coherent effort.

All the libraries you mention would be valuable in boost in my view -- contributions appreciated. See http://www.boost.org/more/submission_process.htm if you haven't already.

Recently I implement some XML related code with the following features: - currently lightweight general XML classes like xml_node and xml_document. they are both uses STL (to hold parent/child releations, content and attributres) and (when needs to produce/parse real XML strings) libxml2. Sample code: xml_document doc(xml_node("root)); xml_node& root = doc.get_root(); xml_node::child_iterator c = root.insert_child(xml_node("node", "content")); c->insert_attribute("name", "value"); c->append_content("... more content."); // XML document is convertable to std::string std::string raw_xml = doc; cout << doc; // parse XML to new document uses another constructor xml_document rebuilded(raw_xml); - XML serialization subsystem -- a set of helpers to convert ANY (almost ;) type to XML and back to C/C++ type... sample code may look like this: int a = 10; xml_node n = xml_cast<xml_node>(a, "size"); // "size" is a node name (which is become XML 'tag' if XML output requierd int b = xml_cast<int>(n, "size"); // convert from xml_node back to int... // you may produce serializable types from 'usual' types at easy xml_serializable_data<map<int, float> > src("my_map"); src.value()[1] = 3.14; src.value()[2] = 2.73; xml_node my_map = src.to_xml(); // or using already known xml_cast :) // no need to pass a name... it is already known xml_node mm = xml_cast<xml_node>(src); - and finally I have implement a XML RPC like protocol to do remote calls: int foo(std::list<int>, std::string, const float*) { /* ... */} // to create XML RPC server you just need: // 1) connection maker object -- usual listener for servers xml_rpc_listener listener(port_number); // 2) RPC server object itself which will use sockets maden by listener xml_rpc_server server(&listener); // 3) add/register XML method(s) on server server.add_method( xml_rpc_server_method< int(std::list<int>, std::string, const float*) >("xml_foo", &foo) ); // ... // to call remote method you need: // 1) connection maker object -- usual active connector for clients xml_rpc_connector connector("localhost", port_number); // 2) client object which will use socket produce by connector xml_rpc_client_p2p client(&connector); // 3) XML method/functor -- this is a real functor, so you may pass it // everywhere a functor maybe passed... even for std algorithms ;) xml_rpc_client_method<int(std::list<int>, std::string, const float*)> remote_foo("xml_foo", &client); // now call it! ;) std::list<int> my_list; my_list.push_back(123); const float* pi_ptr = new float(3.14); remote_foo(my_list, "super string", pi_ptr); You even may catch __remote__ exception if server's foo throw it :) All of above used in project I worked on currently, but if it can be interested for someone else I can start to boostify this... :) have fun!

On Wednesday 21 July 2004 14:05, Daniel Wesslén wrote:

I am definitely interested. Actually, if you decide not to boostify it (though I certainly hope you do), would you consider making it available some other way? Yes I do. I have plans (if boosters reject this lib) to start a project on SF.net...

Sven Van Echelpoel wrote:

* 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.

Actually, I now think it will be very hard to do, and will give very little benefit....

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.

... because if you mostly load some classes, it does not really matter if the single function is extern "C" or not.

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.

You mean you'd write a tool which will automatically write name mangler, or I misunderstood you? In any way, http://www.codesourcery.com/cxx-abi/abi.html#mangling is complex.

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.

Probably, you could start by explaining your vision of the library first. Of three points you've given: * 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 The two last seems very vague for me. For example, how the second is different from: boost::function<void (void)> f = static_cast<void (*void)>dlsym(h, "whatever") - Volodya