Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-03-13 20:19:34


I've looked at this proposal a little bit. I was expecially curious how
it managed to do this totally within a header with not static objects.
I had been unable to do this.

Looking at a tiny bit more carefully, it seems to be that it presumes
that the possible "plug-ins" are listed ahead of time. I'm not sure
what the all the implications of that are. But it would preclude
shipping an add-on DLL to be used by an existing program.

This isn't necessarily a criticism, but its clear to me that this is
a "different thing" than what is part of the serialization libary.

The extended_type_info component could use a "construct
from id" function. The serialization library doesn't need it
but I thought it make make the component more useful.
The details turned out to be problematic. But recently
a possible way to do this has occurred to me. So maybe
something will happen someday in this regard.

Implementing this for non-RTTI wasn't all that hard
as I remember. It did require a fair amount of
code shuffling which resulted in breaking out extended_type_info
as a separate component.

The current version depends upon static objects to
register themselves in a global table so they don't have
to be "pre-registered" by the programmer. This is
convenient - and its what people insisted on - but I think
this is the root cause of some of difficulties which
occured (hopefully resolved in the HEAD) with
the dynamic loading/unloading of DLLS.

The serialization library lets one select the typeinfo
system he want's a particular class to use. The common
one is RTTI. However, one based on the specified
EXPORT name is also implemented. There is a test
which demonstrates that the different systems
inter-operate. So it might be interesting to see
if this method would/could be used as another
variation of extended type info.

I didn't spend a huge amount of time looking at it
so feel free to take these comments with a grain of salt.

Robert Ramey

Jeremy Pack wrote:
>> I want to suggest Robert Ramey as a mentor (if he agrees of course),
>> because boost::serialization already has some mechanisms for plugin
>> library in place.
>
>
> I agree - we discussed this in a thread a few months ago. Robert's
> help
> would be appreciated, especially for removing the RTTI requirement
> from the library. He already pointed me in the right direction - I
> just haven't
> gotten the chance to work on implementing it yet.
>
> However, there are places in the code where I currently use a python
> script to generate some redundant template code - Hartmut Kaiser's
> preprocessor library would probably come in quite handy there and in
> a few other places.
> A number of items in my "to do someday" list involve using the
> preprocessor and template tricks.
>
> Either of them has knowledge that would give Mariano (and me of
> course)
> great material for the library.
>
> Jeremy
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk