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.)
Yes.
> 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.
Yes.
> 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.
Best,
Vicente