Boost logo

Boost :

From: Matthias Troyer (troyer_at_[hidden])
Date: 2006-09-18 13:36:26


On Sep 18, 2006, at 7:30 PM, Robert Ramey wrote:

> Matthias Troyer wrote:
>> I am a bit perplexed by your mail, since it is an identical copy of a
>> private e-mail you sent me two weeks ago, even before the review
>> started.
>
> I realize this - its just that I thought that someone else might
> have some other observations to add on the subject.

OK, thanks for explaining.

>
>> The comments of several reviewers, which were initially skeptical
>> about our use of the serialization library in a high performance
>> context, but whose concerns vanished when they saw the array
>> optimizations, should show you that it was not only me who needs
>> these optimizations.
>
> I don't object to the array optimizations per se, I'm interested
> in seeing if there's a way to do that doesn't hard code coupling
> between particular pairs of archives and datatypes into the
> the original archive classes. Actually this question applies to the
> the modifications in binary_?archive so its a little off topic - but
> still related.
>
>> Watch out that there are more such types: multi_array, ublas and MTL
>> vectors and matrices, ... With the array wrapper we have an elegant
>> solution to handle also these other types. Since we have discussed
>> this topic many times on the list over the past year I will not
>> comment further for now.
>
> I think this is the part I'm still not seeing. the changes to
> binary_?archive
> include specializations for std::valarray, std::vector and native C++
> arrays.

Can you please show me these specializations? I do not see any except
for a std::vector overload in the base class which is needed for
special reasons and only for this class.

valarray, C-array, as well as other classes like ublas arrays and
matrices and multi_array can be serialized just using the array
wrapper and will not need any modification to the archives.

Matthias


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