Jeremy, sorry for jumping into this discussion. Just a few points/questions. Jeremy Pack wrote:
Hi Janek!
I can answer a few of these:
1. do you plan to use (not yet accepted) Boost.UUID to uniquely identify classes for the class factory?
The library allows you to define an arbitrary type identification facility. Check out the typeinfo header. It uses RTTI names by default - but you can identify your constructors by version number or any other mechanism. I'd say that Boost.UUID would be a good fit. We'll try to add an automatic way of using it (but not require it).
Yes, please don't make it a requirement to use UUIDs. I'll definitely have a need to use human-readable type names, which could also easily map to shared library names. This would allow for some automatic loading of shared libraries based upon the requested types. [snip]
2. how else do you identify them if not with UUID ?
RTTI. Some platforms (OS X) actually work fine just using the type_info reference returned by typeid - other platforms (Windows, for instance) only work with the full typeid(x).name(). But see above for other options.
Plain strings, e.g. equal to class names (including namespaces): "my::namespace::MyClass" [snip]
5. does your library work without bjam? (I remember that Jeremy Pack configured Jamfile to use *.extension). I'm particularly concerned with that, because I don't want to change the build system in my project ;)
Yep - it works fine without bjam. The basic functionality currently works without Boost at all (though advanced functionality requires it - as do the tests). You don't have to rename the files. You can just use *.so, *.dll or whatever. I just used a different extension for ease of cross-platform use.
Why not provide a class loader with the library, which could be configured with e.g. : - Locations (i.e. directories) to use for loading, in prioritized order. - Type id => library name mappers, allowing the user to only provide the type id when loading classes. - Shared library extensions to use for the library loading (defaults to platform standard extension). - Explicit load functionality, where the user can specify the library name and the type id. As for cross-platform usage, the users should normally not include the file extensions or the paths to the libraries, only the canonical library names. It should still be _possible_ to provide the exact path and library extension. [snip]
7. can you explain shortly what Reflection is? Or some URL with explanation, please.
I think of reflection as runtime type information about the methods of a class for which you do not have access to any of its base classes. As such, there are a lot of directions one could go with it - I'm not sure which direction Mariano will choose. Some of these directions are really hard in C++. I think we'll be discussing that a lot in about three weeks - and will want lots of input from the community.
I don't know what you intend to do, but please don't mix the two libraries into one. I'd even go as far as to suggest that the "dynamic (un-)loading of libraries/finding the entry points for specific methods" part of the Extension library should probably be a standalone library.
8. You need to record information about classes stored in plugins. Does this information include also the inheritance hierary? I mean - do you know on runtime which class derives from which one?
[snip]
If we wanted to allow just exporting a flying_car and let it be loaded through any of it's interfaces, a whole bunch of dynamic casts could do it. I don't believe this functionality is necessary.
I assume that it will always be possible to dynamic_cast the created instance to whatever types it actually implements, right? Example: boost::shared_ptr<base> pb = "load extension and create shared base instance"; boost::shared_ptr<derived> pd = boost::dynamic_pointer_cast<derived>(pb); Regards / Johan