Re: Several useful utility classes uploaded

From: brianjparker_at_[hidden]
Date: 2001-11-03 03:27:20

--- In boost_at_y..., Douglas Gregor <gregod_at_c...> wrote:
> On Sunday 28 October 2001 07:05, you wrote:
> > Though I tend to agree that if the only use for the proposed 
language
> > extentions was to align stack memory, then the need is probably 
not
> > great enough to justify a language extension and a standardised
> > std::alignment_traits<>::align_t and 
std::alignment_traits<>::value
> > would be enough support.
> 
> I think that the path of least resistance would be to supply 
> std::alignment_traits with the value and align_t members, and 
require compile 
> support. This is similar to some of the other type traits 
> (has_trivial_constructor, is_empty, etc.) that require compiler 
support.

Actually, I think that there is a third option which would be the 
best long term solution. 
The fundamental problem is that the standard disallows non-PODs in 
unions, hence the need for creating a POD with the same alignment via 
alignment_traits. The language definition could, though, be easily 
extended to allow class types directly in union definitions (perhaps 
requiring a POD as the first (initialised) member). This would remove 
the need for std::aligment_traits<>::align_t.

(In fact, I vaguely remember reading somewhere on the web that an 
even more extensive upgrade of unions to allow class types was being 
considered for the next language standard anyway. Does anyone have 
any details on that?)

Failing that however, I agree that a standard 
alignment_traits<>::align_t and ::value is the best library solution.

(BTW, what is the best way to submit such small additions to existing 
library classes such as boost::alignment_of or 
boost::alignment_traits- do they require a full review or should they 
be submitted as a patch directly to the developer of the existing 
library?)

,Brian Parker