From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-05-24 07:45:20
Neil Mayhew wrote:
> On 5/23/08 7:11 AM, Beman Dawes wrote:
>> In working on endian, I became convince that the C++ standard's POD
>> specification was a serious impediment and needed major revision. The
>> standards committee agreed, and so C++0x will include a major
>> relaxation on the requirements for POD's... So the next step is to
>> revisit the current endian design, and apply C++0x features where useful.
>
> Thanks for this clarification. The standard changes sound great, and it
> makes sense to take advantage of these in endian, where possible.
>
>> Some of these features are starting to become available in compilers,
>> so they can be tested.
>
> However, I think it will be a while before I myself am able to use a
> compiler with these features, whereas I'd like to use endian asap. How
> about we get the current implementation into boost more or less as-is,
> and then work on improving it with new compiler features as these become
> available?
>
>> I'm buried with other commitments, so if someone else wants to help
>> with endian it might speed things up quite a bit.
>
> What kind of help did you have in mind?
I just took a look at the current state of the library, and it seems to
be in pretty good shape. So the main help would be careful review and
commenting on a revised version. I'll try to get that out in a week or so.
> Is there anything that needs to
> be done that doesn't involve using new compiler features?
Yes. The two enums need to be moved into subnamespaces to simulate C++0x
scoped enums.
Questions:
* For efficiency, should an operator= taking a value_type argument be
added? (I can't remember why there isn't one.)
* Should there be a conversion to bool?
* Should there be a way (#ifdef? separate class?) to provide an
interoperable version that meets C++03 POD requirements, so endian
objects can be put in unions? Is that what you mean by (1) below?
> The areas that I am interested in seeing more work done on are (1)
> making constructors "conditional" and (2) adding a bit-range access method.
Do you have a proposed design for bit-range access?
What is the use case or motivation for bit-range access?
Thanks,
--Beman