Re: [integer] Promotion of endian library code from vault

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost