Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-07-01 12:49:04


Martin Wille wrote:
> Michael Behrns-Miller wrote:
>
>> 3) I realize I can split serialize() into separate load/save
>> functions. However, I appreciate the recommendation to use one
>> serialize() function, where the load/save order is easier to
>> maintain. However again, I absolutely need (I think :>) to know,
>> within that function, if I am loading or saving. It's the only way
>> I can efficiently handle versioning or handle dynamic allocations,
>> and still use one serialize() function, as far as I can tell.
>> Bottom line: I now have isSaving(archive)/isLoading(archive)
>> functions, can these be added to the library? Or am I approaching
>> this wrong?

A big advantage of using the "split" functionalty is that its implemented at
compile time. So that if you include your class header in a program which
does only saving only the code to do the saving will be instantiated. Your
programs will be smaller and more efficient (due to the lack of an if(...

Note that the library documentation (1.33) does in fact describe is_loading
and is_saving boolean contants which can be used to implement trickier
serialization. Looking at the split?.hpp files will show one way how these
can be used to generate only the required code. Of course they can also be
used in the more traditional straight forward way of

if(ar.is_loading...)

but then your program that do only a save or load will include code they
never use. (i.e. code bloat). I believe this will constitute a short
excercise in becoming comfortable with template meta-programming as it
applies to controling code-bloat.

> During the writing, I missed some additional documentation about how
> to write these wrappers and had to resort to reading the source. Since my
> understanding of that topic isn't complete, I currently can't
> contribute the documentation I missed.
>
> Robert (and others), do you think some framework to enable users to
> write their own wrappers would be useful? (A simple and slow one could
> use user-provided functors for converting to/from a string.) Could you
> comment on whether it is desirable to enable users to write their own
> wrappers?

It has been my intention that wrappers be a "first class" feature of the
library. That is available to user of the library. The documentation
that's there is written with that intention. So if its incomplete let me
know.

Having said that, I recently had to add a code in a couple of places to
workaround some other inrelated issue. That code is somethin like if type
is nvp ....

which breaks the independence between nvp and the serialization library
itself. Of course nvp IS special but I remember considering adding a trait
"is_wrapper" to permit a better indepence of the wrapper concept. I suspect
thiis concept ("wrapper") might now be in some need of improvement,
clarificatiion and/or repair. But I haven't had time to visit the issue.

Robert Ramey


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