Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk