From: Jeremy Pack (jeremy.pack_at_[hidden])
Date: 2006-10-09 18:04:01
Janek and Robert (and others),
First of all, the library that I'm working on does use the Serialization
library, but not to the level that Robert is suggesting.
1 - The exporting of classes from a dll or whatever is not a terribly
difficult part to implement - if this were all that I needed, I would not
have started my own library. However, I agree that this part SHOULD use
boost::serialization (not reusing already proven code would be a mistake in
this case). As long as the way that has been suggested will meet a few
criteria, I think work should immediately begin on doing it using Robert's
suggestion. I will check through the extended_type_info documentation to see
if it will be able to provide each of the requirements that I feel
necessary. It sounds like it does.
2 - The primary requirement that is important to me is tracking dependencies
between loadable objects. I'm working on a relatively flexible way of
handling that. I think it is a vital part of making this library more useful
than just a classloader. It's also, I think, the hardest and most subjective
I will still attempt to get my code posted, keeping in mind that most of the
object loading will probably be completely rewritten to use
Robert, if you have the time, I believe your experience creating the
boost::serialization library would make you the most qualified to head up
the effort to create a plugin library for Boost. Even if you don't have that
kind of time, your continuing input would be very appreciated.
Either way, hopefully my code could be a good launching point for this. I
hope to have it posted in a few days.
One important question: should we avoid requiring RTTI? Should
boost::serialization make it unnecessary? I'm currently using a dynamic cast
or two, mostly just for type safety. I know that certain older compilers
have a problem with that (Borland at one time, perhaps still, cannot handle
RTTI in DLLs correctly for instance), and it might annoy people to have to
remember to enable it on those that do not.
Thanks again for all of the input.
"Janek Kozicki" <janek_listy_at_[hidden]> wrote in message
> Robert Ramey said: (by the date of Mon, 9 Oct 2006 09:31:38 -0700)
>> Janek Kozicki wrote:
>> > Think of it. With two separate libraries (one for serialization
>> > and one for plugins) the user will have to register each class twice.
>> > Serialization already registers classes with GUID (Global Unique
>> > IDentifier) so plugins/extensions library should take advantage of
>> > that.
>> Oh no. registering a data type for export would be sufficient
>> for plug-ins AND serialization.
> Yes you are right. Slight misunderstanding here. I was talking about
> "two separate, totally different" libraries. Like we already have
> boost::serialization and a new library from Jeremy that doesn't know or
> use the mechanisms from serialization but instead reinvents the whell.
> And I meant that this would be bad.
>> So I would like to see:
>> a) a plug-in library based on ehancement of extended_type_info
>> b) serialization tweaked to use this library.
>> Then we get a "smaller" serialization library - and a separate
>> self contained library which is useful for other things. Just
>> a little code re-factoring.
> yes, I agree 100%
> So if we start working on this, we simply continue the work started by
> introducing extended_type_info
> But since it's Jeremy who started this thread I await his (your ;)
> acknowledgement of this conclusion. I'll try to help in doing that
> (as usual - given enough time...)
> Janek Kozicki |
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk