Re: [boost] [boost::endian] Summary of discussion #1

Subject: Re: [boost] [boost::endian] Summary of discussion #1
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-03 08:07:12

vicente.botet wrote:
> Stewart, Robert wrote:
>
> > I dislike referring to the function-based interface as
> > "untyped" and the higher level interface as "typed."
> > Perhaps we could use "function-based" and "object-based"
> > as the adjectives?
>
> My typed/untyped was respect to endianess. With the Beman's
> approach the type know its endianess, with the Tom approach
> it doesn't.

Of Beman's library provides types.  int and double are types, too.  I understand that Beman's types know their endianness, insofar as it is supplied by a template argument.  Endianness, however, is not a type.

> I don't find the function/object naming appropiated, I
> consider the Beman's endian classes as types not as objects,
> and the conversion from atype to another is clearly a
> functional concept not an object concept. I don't consider
> the swap_in_place belongs to the functional programming
> paradigm, at least not to the pure one.

I didn't use the word "functional" but "function-based."  Tomas' approach uses functions.  Beman's approach uses objects of type boost::endian, hence "object-based."  Tomas' functions are not typeless.  They operate upon a specific type T.  To call them "untyped" is misleading, hence my desire to use "function-based" and "object-based" as the means to reference the different approaches.

> > Several of us have agreed that including support for
> > arithmetic operators is misleading.
>
> I agree for the kind of applications I'have done. This
> doens't mean that nobody will take advantage of this
> transparent interface. Not all the applications have the same
> performances constraints.

The standard library usually refrains from providing what is inherently inefficient.  That is a good idea for Boost libraries, too.  At the very least, I think there should be separate types with and without the operators so the distinction can be made very clear.

> > From my point of view we need just to split the interface
> > of the endian class in two:
> * packets: endian packets without arithmetic operators.
> * integer: endian integers with all the arithmetic operators.

I guess your "packets" are simply what Beman provides now minus the arithmetic operators.  The name isn't helpful, but we can work on that.

> Tom can always reimplement the Beman's library using its
> library, but I don't consider this necessary.

I wasn't suggesting it was necessary, but Tomas may well have ideas of his own and we don't know yet how Beman will receive the new ideas.

> > Whether Tomas or others have still different ideas on the
> > interface remains to be seen, but there is already sufficient
> > reason to create a new set of endian types, if only to
> > compare and contrast with Beman's.
>
> I agree, but I dont see why the Tom library should include
> the packet interface.

You're assuming that Beman's library will be accepted and that Tomas' library should be proposed as a complement to it.  I'm assuming the possibility that Tomas' will produce a library that subsumes Beman's.

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