30 May 03:51
Re: [integer] Promotion of endian library code from vault
Beman Dawes <bdawes <at> acm.org>
2008-05-30 01:51:07 GMT
2008-05-30 01:51:07 GMT
Neil Mayhew wrote: > On 28/05/08 04:25 PM Beman Dawes wrote: >> Neil Mayhew wrote: >>> ... have a base class that contains everything except the >>> constructors, and a derived class that adds the constructors >> There are some issues with the base class approach. For it to be a >> POD, it can't have constructors, base classes, or private members. > > Strictly speaking, yes, although we are only concerned about memory > layout here, so the class doesn't have to be a true POD. The other > concern is for the class to be able to live inside a union, and I think > the constructors are the the only thing stopping that. (I #if'd the > constructors and I was then able to use endian in a union.) I was wrong above - you are correct that just the constructs have to be removed. Private members and base classes are OK. >> It might be better to just have two separate types, endian and >> old_endian. (old_endian isn't very clear as a name, but calling it >> pod_endian becomes invalid the moment C++0x ships.) >> >>> The typedefs to big32_t etc. would then be #if'd to correspond to the >>> POD or non-POD classes as desired. I think this is better than >>> putting the #if's around the constructors themselves. >> Hummm... Seems too obscure. Better to have two sets of typedefs, with >> the C++03 set prefixed by old_ (or whatever better name anyone can >> come up with.) > > I don't like "old_", at least not if it has to appear in my code!> > I would like my client code to remain essentially the same when I > upgrade to a C++0x compiler. This means having the same type names, > which is why I suggested conditional typedefs. I thought this was > cleaner than putting the conditionals inside the endian class itself. > However, it doesn't make a lot of difference. > > Perhaps the simplest and best solution is therefore: > > class endian< ... > > : cover_operators< ... > > { > public: > #if defined(CXX_0X) || !defined(ENDIANS_IN_UNIONS) > endian() {} > endian(T val) { ... } > #endif That would work. The macro names need tweaks. Maybe !defined(BOOST_NO_RELAXED_PODS) || !defined(BOOST_ENDIANS_IN_UNIONS) or !(defined(BOOST_NO_RELAXED_PODS) && defined(BOOST_ENDIANS_IN_UNIONS)) It's been a long day so that'll need checking in the morning
Thanks for the ideas, --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
> I would like my client code to remain essentially the same when I
> upgrade to a C++0x compiler. This means having the same type names,
> which is why I suggested conditional typedefs. I thought this was
> cleaner than putting the conditionals inside the endian class itself.
> However, it doesn't make a lot of difference.
>
> Perhaps the simplest and best solution is therefore:
>
> class endian< ... >
> : cover_operators< ... >
> {
> public:
> #if defined(CXX_0X) || !defined(ENDIANS_IN_UNIONS)
> endian() {}
> endian(T val) { ... }
> #endif
That would work. The macro names need tweaks. Maybe
!defined(BOOST_NO_RELAXED_PODS) || !defined(BOOST_ENDIANS_IN_UNIONS)
or
!(defined(BOOST_NO_RELAXED_PODS) && defined(BOOST_ENDIANS_IN_UNIONS))
It's been a long day so that'll need checking in the morning
RSS Feed