Re: [boost] [endian] endian flip and endian domain

Subject: Re: [boost] [endian] endian flip and endian domain
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-09 06:41:22

Gottlob Frege wrote:
> On Tue, Jun 8, 2010 at 1:39 PM, Stewart, Robert
> <Robert.Stewart_at_[hidden]> wrote:
> > Dave Handley wrote:
>
> So the question may just be how much we should expose with a raw-int
> interface vs endian-typed, and/or to what degree.  If we could expose
> more strongly typed versions *without additional overhead*, I'd prefer
> that.

+1

> And actually, it is simple to convince yourself that we could.
> The problem would be the amount of reinterpret_casts that would be
> required by clients.  They would instead resort to
> boost::endian::detail... pretty quickly.

I would not want to impose any additional casts on client code.  I'd want the endian library to do all of that sort of thing by a nice, convenient, obvious, self-documenting syntax.

>    indeterminate_endian convert_to_big(indeterminate_endian);
>
> is clear about its intent.  The fact that it can take and return ints
> without additional casts just makes it useful.

I suspect I missed a message in which you previously suggested indeterminate_endian.  If that type converts to and from integer types, convert_to_big() would create ambiguities and allow unsafe conversions.  Perhaps your signature has just mislead me.  Did you mean something like the following?

   template <class T>
   indeterminate_endian<T>
   convert_to_big(indeterminate_endian<T>);

Given that, and assuming that indeterminate_endian<T> will only construct from and convert to T, it may be workable.

Syntax that clearly declares that the input is, or is assumed to be, of a certain endianness and that the output is to be another is certainly important.  Whether that requires an object-based approach or just reasonably named function templates with suitable template arguments is still at issue, I think.

Why don't you try to piece together all of your current ideas into a coherent collection that covers the bases of casting, swap-in-place, endian types, etc.  To many of those are vague in my mind from what you've been suggesting and its good to step back to see the effect of tangents on the whole periodically.

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