From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-06-07 02:27:11
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.
>> 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):
>> 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.
>> 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
> 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
boost::shared_ptr<derived> pd = boost::dynamic_pointer_cast<derived>(pb);
Regards / Johan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk