Re: [boost] [soc] Boost.extension/reflection project advances

From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2007-06-07 11:18:25

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