Re: [boost] [endian] swap_in_place use case

Subject: Re: [boost] [endian] swap_in_place use case
From: Terry Golubiewski (tjgolubi_at_[hidden])
Date: 2010-06-04 15:24:25

> Tom wrote:
>> Terry wrote
>> If you're only going to access each element of the file, then converting
>> endian on access should be faster than swapping in place and then
>> processing, without needing double the memory.
>> Could you please give a specific example (preferably with code) that I 
>> could
>> play with?
>
> I was under the impression I already provided you with a use case in an 
> earlier
> thread.

I'm looking for a specific application, (perhaps a specific video 
compression algorithm), that I can try.
My previous test program read a large disk file, as you proposed.  Now, I 
need something

> Converting to endian on access certainly won't be faster than 
> swap_in_place, as
> you cannot have a "zero cost" version.  Additionally, in our scenarios the 
> data
> gets accessed multiple times.

What is an example of one of these scenarios?

> But just to re-iterate:
> 1) swap_in_place<>() can be zero cost in the case of no swapping, which 
> cannot
> be said for the copying approach.  I.e. it has a much better best case 
> behaviour
> and the same cost for the worst case behaviour.
> 2) It is one of the safer ways of handling floating point numbers.

I disagree.  I have demonstrated that...

1) endian-on-access can be zero cost in the native-case.
2) swapping in place is not any safer because the C++ type system cannot 
help to determine which portions of an object have been swapped, nor 
document the endian properties of a data structure.  endian<big, double> 
can, and should, be defined to provided portable floating-point transfer and 
persistent storage.

terry