Boost logo

Boost :

Subject: Re: [boost] [Endian] Review
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-09-10 09:15:37

Le 10/09/11 14:39, Beman Dawes a écrit :
> 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?
I gues you have at least 1 follower :)
> 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?
Happy to see that you have finaly adapted my private proposal included
in Boost.Endian.Ext.


Boost list run by bdawes at, gregod at, cpdaniel at, john at