Re: [boost] [endian] swap_in_place use case

Subject: Re: [boost] [endian] swap_in_place use case
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-07 06:59:20

Terry Golubiewski wrote:
> 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.

Let's be clear about a few things to avoid talking past one another:

 - No one is suggesting swapping an entire large file in place just to access a few bytes.

 - Accessing each swapped byte only once reduces the possible difference in the various approaches to one copy.

 - Accessing values multiple times, when swapping is actually required, means that swapping up front and then accessing the data will be faster than swapping on access.

Because of those differences, swap-in-place is valuable.  Whether one chooses to use it in any given use case or context is a separate matter.

It is also clear that it is easier to make mistakes using the function-based approach, so the object-based approach is safer, if less efficient in specific use cases.

> > 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.

I think both can have zero cost if the interface is designed to handle that correctly, but then one must also consider the worst case costs.

> 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

That presumes that the entire object hasn't been swapped, of course.  In use cases in which only select datum are accessed, there can be an advantage to the endian type, but it comes at the cost of having to declare a parallel structure definition in the typical case (an OS/RTL structure must be redefined using the endian types).  That is particularly onerous when only select fields are accessed, but it does mean that any alteration to the code reading the fields will automatically use the correct values should yet another field be read.  In the non-object-based approach, changing the algorithm to read a new field means the maintainer must remember to swap the new field before using it.

These differences should be discussed in the documentation in order to help the library user understand whether to use the function-based approach or the object-based approach.  Because there are clear desires to use each, the documentation should not be biased between them but clearly document their strengths and weaknesses.

> data structure.  endian<big, double> can, and should, be
> defined to provided portable floating-point transfer and
> persistent storage.

Since endian is designed to return T by value, it suffers from the normalization problem described elsewhere in these discussions.  That means the floating point specializations would, of necessity, require a different interface than those for integral types.  That will be discomfiting.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.