Re: [boost] [Endian] Review

Subject: Re: [boost] [Endian] Review
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-09-10 08:39:07

All,

On Thu, Sep 8, 2011 at 1:18 PM, Tomas Puverle
<Tomas.Puverle_at_[hidden]> wrote:
> Hi Beman,
>
>>      - What is your evaluation of the design?
>
> The design of the integer types seems reasonable to me, even though I would
> prefer not to have the overloaded operators on them.  I feel that having the
> operators has the potential to break the boundary between program input and
> the program's processing.  What do you I mean by that?  Typically, I try to
> structure my programs as follows:
>
>        1) Read input data
>        2) Verify input invariants, construct internal representation
>        3) Process internal representation
>        4) Output result
>
> The problem with having operators in the endian types is that they encourage
> the user to continue using them past the point 2).
>
> However, as I said, that's my personal preference and last year plenty of
> people wanted to see the operators included.  Perhaps they could be a policy?
>
> endian<..., bool EnableOperators_ > ?

Consider this alternative:

A class template, perhaps named "endian_buffer", that is the same as
the current class endian except it does not provide the operators. The
typedefs provided would have "buf" added to the name (E.G. big32buf_t,
etc.)

A class template, perhaps named "endian_integer", that publicly
inherits from "endian_buffer" and also provides the operators. In
functionality it would thus be identical to the current class
"endian", including the current typedefs.

Functionally of this approach is exactly the same as Tomas'
endian<..., bool EnableOperators_ > suggestion plus the additional
typedefs. But my sense is that it would clarify the separation of
concerns, and would be a bit easier to explain to new users than a
policy.

It seems to me this addresses the concerns of those who want explicit
separate of the boundary between I/O and processing, and that it will
make users more aware of choices in program organization. Do others
agree?

It seems to me that the cost in terms of both surface area and
implementation complexity is relatively small, so I'm not overly
worried about feature bloat. What to others think?

--Beman