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-03 14:57:39

Vicente Botet wrote:

I'm looking for a use case where the use of swap_in_place (or whatever is 
renamed) is not followed/preceded by a copy.

When I need to send a message I need to copy the information to send in a 
buffer. I gues that in this case the use of swap (copy) is the function to 
use.

Can somene help me to identify a real use case on which the swap_in_place 
can be used to send a message that do not need to be initialized before 
sending?

When I receive a message, I will need to store some of the messages 
information on application context, store them on local variables or pass 
them to other functions. All this suppose a copy from the buffer to the 
different kinds of native storage. I gues that swap (copy)  should be used 
in this case also.

The example of Terry reveives a array of ints and makes a swap_in_place, but 
do nothing with. Someone has proposed to sum all these ints, but in this 
case, we don't need to swap_in_place and the count. With swap approach, we 
can count at the same time as we do the conversion, so no need to swap in 
place.

Can somene help me to identify a real use case on which the swap_in_place 
can be used to reveive a message, without needing to do any additional copy 
from the swapped buffer to native data?

Terry replied:

Yes.  Image/video decompression. In these cases, each video frame is stored 
on a physical medium or is sent streaming across a network.  The image is 
usually represented as a matrix of "coefficients" that are in either big- or 
little-endian format.  During the decompression, the coefficients may be 
read several times, so it is beneficial to store these coefficients in 
native format in memory.  Doing computation in place and transforming data 
is also quite common in signal-processing, e.g. the Fourier transform. 
Doing computation in place also provide a performance advantage because of 
memory caching.  That said though, such high-performance applications 
usually involve (for me) exploitation of the underlying hardware and 
processor instruction set for the performance critical parts, and therefore, 
don't fall in the realm of generic C++ implementation.

But... these applications usually also eventually involve some form or 
error-correction and/or compression close the the communication/storage 
layer.  Once that happens, then the data is necessarily copied to another 
format.  Frequently, these operations access blocks of the input stream and 
cannot be done in place (an in-place decompression algorithm doesn't make 
much sense).  Once you need to do the copy, the advantage of 
in-place-conversion is lost.

terry