From: David Abrahams (dave_at_[hidden])
Date: 2002-12-09 22:43:34
My posting was not meant to start a discussion thread here, and I was
not trying to solicit individual opinions like those you posted below.
Those interested in the development of this library should regroup and
tackle these questions and others of concern to the group together.
I will, however, clarify two points below.
"Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]> writes:
>> 2. Careful description of scope. Answer questions like:
>> * Is this a persistence or serialization library?
>> * Is it important to be able to plug in arbitrary archive
>> 3. Careful consideration of the appropriate interface for describing
>> the serialization of UDTs on a conforming compiler. In particular,
>> consider the lexical cost of requiring users to specialize library
>> templates. Also consider that the use of operator<< is going to
>> invoke ADL anyway, so maybe the interface should just use
Argument-dependent (aka Koenig) lookup.
>> that. Serialization of class template specializations and other
>> classes should use the same mechanisms.
> On conformant compiler.
>> * Dave Harris suggested several times that integers should be
>> written in the binary archive in a variable-length format. This
>> echoes a philosophy on serialization which I've had for years,
>> provides many benefits and would seem to allow drastic
>> simplification of the library if it is decided that the current
>> scope will be retained, since it entirely obviates the need a
>> text archive format (the same could be done for floating point
>> numbers). The only application I can imagine this approach being
>> unsuitable for would be extremely fast, relatively small
>> in-memory archives... and I'd have to see benchmarks and a real
>> use-case to be convinced of that.
> I do not think we should enforce specific portable binary presentation.
> 1. There is no such task to present portable binary presentation
> 2. "you don't pay for what you don't use". I may not bother. Even if it
> costs almost nothing.
Even though I didn't intend this posting to start a debate, I feel I
should clarify that for all the actual use cases we know about, Dave's
suggestion would be very likely to be a major performance win because
it generally reduces the size of archived data. As review manager,
I'd like to know there's an important use case for which it is
actually slower before it is dismissed.
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk