Re: [boost] [serialization] fast array serialization (10x speedup)

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-11-25 00:04:28

Manfred Doudar wrote:

>> The main point is - do enhancement for special cases have to be
>> incorporated into the the core code so that everybody else
>> is obligated to use it?  What are the advantages and
>> disadvantages of doing so?
>
> Umm, I don't follow - how are others going to be obligated to use
> those special cases that don't necessarily apply to them?

The design of the original submission changed binary_archive
so that everyone would benefit from the enhancement whether
they asked for it or not.  The library has been designed to
avoid exactly that situation.

>> No one is disputing that it desireable to be able to extend
>> the library for these special circumstances.

>
> Actually it's *very* desirable.

The library has been designed to permit this.  I don't see how
anyone who looks at the documentation could conclude
otherwise.

>>> If there is to be any possibility of targetting an archive to this
>>> format, then array support is crucial.
>>
>>
>> Then just make an archive which does it- what's stopping you?

> True - but the suggestion is that it's common enough to want as part
> of the core library.

Ahhh - perhaps this is the source of the confusion.  When I use the word
"core library" I'm refering to the common set of facilities that ALL
archives use.  For example, xml is not part o the core library - though
its widely used.  xml_archives have been build on top of the "core"
and are in fact a use case for the library.  Of course, users who
don't build archives themselves may not be aware of of and see
xml_archives are part of the "core library" because its included
in the package and they just use it.  The library is really an
archive construction kit.  As part of the package it includes
5 pre-made archives which

a) can be used as is
b) can serve as examples for making one's own archives
c) can be used as base classes for making variations and extentions
d) can be composed with archive adaptors to create variations
of existing archives - e.g. polymophic archives.

The current situation is where one user feels he needs to to something
that none of the other archive creators have had to do - alter the
construction kit itself.  This violates the factoring which has permited
the library to be used to make all these different archives from the same
core layer.  This same factoring has permitted the implementation
of polymorphic versions of all the above 5 archives and will
permit any new archive to be made polymorphic by composition
with existing code.

******************************************************
*So for the Nth time.  This is not about whether or not archive
*XDR, CDR, MPI, or XYZ should be made.  Anyone is free to make it.
*Its about how to do it so that it doesn't impact anyone else's efforts.
******************************************************

<snip> about how important other formats are </snip>

> I've been loosly following this thread and I understand your
> reluctance to this - but it's a matter of perception as to how
> needful, and widespread such a need is.

If there is a need, I trust someone will make the corresponding
archive.

If its too hard to make an archive - well that's another problem
and I'll see how that can be made more transparent.

Robert Ramey