$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Robert Ramey (ramey_at_[hidden])
Date: 2002-11-25 21:01:00
Date: Mon, 25 Nov 2002 10:41:17 +0100
From: Matthias Troyer <troyer_at_[hidden]>
>> I guess this should be changed to:
>> #ifdef BOOST_HAS_MS_INT64
>> virtual basic_iarchive & operator>>(int64_t & _Val) = 0;
>> virtual basic_iarchive & operator>>(uint64_t & _Val) = 0;
>> #endif
>> #ifdef BOOST_HAS_LONG_LONG
>> virtual basic_iarchive & operator>>(long long & _Val) = 0;
>> #endif
>This sounds better. Thanks.
whoops, that doesn't work either - this will take some work to address.
>> why can't this be handled using
>>
>> basic_oarchive::write_binary(void *p, size_t count)
>This does not allow type-specific transformation (e.g. change of byte
>order) to be performed. Thus we neeed one such function for each
>primitive type.
I fail to see the problem. If you want superfast i/o with only once
virtual function call use
basic_oarchive::write_binary(void *p, size_t count)
If you want each array item handled individually use
ar << t
Note that if t is a fundamental type, all serialization machinery
is effectively bypassed. So the only overhead is one vtable
indirection which should be small compared to doing something
like changing bigendian to little endien
>
>> The current library is however not consistent since
>
[snip]
>According to the documentation this seems to be the way we have to
>implement it. Do you want to tell me that if I just want to support conforming
>compilers, then I can just specialize the serialization class for my
>template classes? If so, then only a change to the documentation seems
>needed.
Currently there is only one way to specify serialization of template classes.
I believe a better way (as hinted at in the manual) will be available to those
concerned only with conforming compiler in addition to the current method.
Robert Ramey