Re: [boost] [boost::endian] Request for comments/interest

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-03 11:17:36

Terry Golubiewski wrote:
> Robert Stewart wrote:
> > Terry Golubiewski wrote:
>
> > (Since buf is a void * in the snipped code, static_cast
> > would work for your casts, too.)
>
> 'buf' must be a pointer to "something".  The void*  is just
> masking what is really analagous to a reinterpret_cast.
> void* is just as ugly as reinterpret_cast.  Maybe more so.

Data read from disk is untyped.  Many APIs use void *, others char *.  Either way, there's no useful type information.  If you have a void *, you can use static_cast to another pointer type.  If you have a char *, you must use reinterpret_cast to another pointer type (or two static_casts).

> >> What bugs me is that 'buf' doesn't point to a 'T' yet.  It
> >> points to a half-baked 'T'.  Only after one calls
> >> swap_in_place() is the object really a 'T'.
> >
> > That would apply to floating point, certainly.  However,
> > for integer types, your statement is false.  Before the
> > swap, they are still integers, they just don't have the
> > desired value.
>
> I disagree. Physically, they are compatible, but logically, they are
> different.

We're in violent agreement.

> I think the logical view matters more.

I can't argue that point, but I don't think it signifies.  In either case, the data read from disk is not usable until endianness has been addressed.  Once it has, all remaining logic works with the appropriate type.

> > Even in the object-based approach, the object isn't a
> > proper T until you access it and the swap occurs.  The
> > implicit swap veneer just gives you the impression
> > that it is already in the desired form.
>
> An endian<X, T> is not the same as a T.  Even
> endian<native,T> must be converted to a T before you can
> operate on it.  The veneer is important, because it
> works like a T, without actually being a T.  I think
> that subtle distinction is important and is the primary
> motivation for type-based endian.

You've made a reasonable case.  "Object-based" please.

> I object to your use of the word "swap" though.  My
> type-based approach does a reverse_copy, not a swap.
> This distinction is the fundamental topic of this
> discussion.

Perhaps you posted code that I was expected to have perused to know that your code did a reverse copy rather than a swap, but I didn't see such code or notice that it did so.  However, a reverse copy is not always correct for changing endianness, though certainly so for changes between big and little endianness.

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