Re: [boost] [soc] Boost.Reflection project advances

From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2007-06-12 12:15:53

> > I'd actually want to separate the "reflection" of the methods from the
> > declaration of the class - the same as Boost.Extension does not
> > require any plugin declarations in the class header file.
>
> where those declarations are supposed to be placed, then?

The user declares an extern "C" function and puts the declarations
there. The reasoning behind it was:

1 - The class shouldn't have to know it will be a plugin.
2 - Only one extern "C" function is now required.
3 - It is probably no more verbose.
4 - All plugin declarations for a library are in one place (though, of
course, you could declare multiple extern "C" functions with different
names, and then instruct the Extension library to load each of them).
5 - It is thread safe - you could have multiple threads loading the
same library at the same time, and it wouldn't cause any problems. No
mutexes necessary.

So, basically, you just put into some .cpp file (it could actually be
your class's .cpp file) this extern "C" function. I believe it uses
far less code than the other solutions that I've looked at - which
should help make it easier to avoid or fix errors.

My preferred method is as follows (though the following is certainly
not required by the Extensions library - it is pretty flexible):

1 - Put a single extern "C" function into every shared library that
declares the plugins exported by that library.

2 - Give the extern function the same name in every library.

This basically just gives each library one extra function that
describes all of the plugins available in it, while not requiring
modification of the classes that are being exported. This should make
it rather simple to fit into existing projects.

Jeremy

>
> >From my point of view it's better to have a single place to update
> information about a class. When method signature changes I prefer to
> update just two files (.cpp & .hpp), instead of three files
> (.cpp & .hpp & .hpp) (not mentioning their callers). I'll
> certainly always forgot about the third file, which will lead to
> compilation errors, or crashes.
>
> But if those .hpp files are supposed to reside in the same directory
> and belong to the same plugin, then the solution can make sense.
> eg. car.hpp and car_reflection.hpp
>
> However the ability of connecting both files to be a single file will
> certainly be useful in some cases. Please don't disallow that. I'm
> not sure which I'll really prefer, but one file less to decrease
> human memory burden is very temping.
>
>
> > boost::extension::reflection car_reflection<Car, std::string>("A Car!");
>
> side note: wouldn't it be boost::reflection car_reflection<...> since
> as I understand, the reflection will come out as a separate library?
>
>
>
> A very annoying problem I encountered when implementing my own plugin
> and serialization library was that templates sometimes are not
> handled correctly across plugins by the compiler. I hope that you
> know what I mean:
>
> I used templates in serialization code, to determine the type of
> serialized object. The template function in question was called
> findType<>();
>
> Some plugin code uses that template. The .hpp template code resides
> in a serialization plugin compiled earlier.
>
> It can happen that sometimes the compiler is not generating a code
> for findType() function. It is assuming that the code for this
> function is in serialization library compiled earlier. Which cannot
> be true, because when serialization was being compiled the object
> type wasn't known yet. The effect is that plugin is calling a
> fallback findType() function, that gives an error "cannot determine
> the type!".
>
> Have you had this problem?
>
> How do you plan to cope with a problem of templates across plugins?
> It certainly exists, and honestly I don't know where it comes from,
> and how to cope with it.
>
> I'm asking about that, becuase your design decision is to put all
> Reflection information inside templates, like the car_reflection<> above.
>
> --
> Janek Kozicki                                                         |
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>