Johan,
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.
One of the primary goals of the library is to keep the separate parts as encapsulated as possible. As such, if the uuid specific header was included, they could be used. Otherwise, there would be no dependencies on uuid. You can define any arbitrary mapping for your class's type information. You could create a complicated struct to describe them, as long as you provided a way to compare them (a less than operator). So, I believe that what you propose should not be an issue. I or Mariano will be writing an example soon showing the use of different types of type info.
[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"
I'll make sure to detail that specific example in the tutorial.
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.
Yes, this is planned - enough people have mentioned it, that we'll definitely work it in. The basic design of it is done, and it will be implemented "when we have time". Once again, it will be included in a "convenience" header, and the code for it will only be included if its header is included explicitly. Since not everyone will need this functionality, it will be made optional.
[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.
We will be posting the proposed reflection solution to this list before implementing it. We'll do our best to avoid high coupling between the plugin loading and reflection. I thought about this for a while this morning, and I think that we can solve this in a way where the reflection will work without including any of the plugin loading headers, and vice versa. However, a "convenience" header will be provided to make it easy to use them together. We'll definitely want your input when we put forward the proposed design.
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);
Almost always - you of course can't cast it to a type that you don't have defined in the current module. In addition, some compilers have trouble doing dynamic casts across shared library boundaries. I do know that an older version of the Borland C++ compiler had problems with this, but am not sure about other compilers. I have done it successfully with relatively recent versions of VS and gcc. Thanks for the suggestions. We'll work on them! Cheers, Jeremy