stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
Subject RE: preconditions for aligned_union
Date Wed, 18 Jun 2008 15:37:06 GMT
 

> -----Original Message-----
> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com] 
> Sent: Tuesday, June 17, 2008 5:43 PM
> To: dev@stdcxx.apache.org
> Subject: preconditions for aligned_union
> 
> 
> I'm looking at the standard, and it appears that the following is
> legal...
> 
>   struct incomplete_t;
> 
>   std::aligned_union<0, void, incomplete_t>::type
>       aligned_t;
> 
> Does anyone have any idea what the expected behavior of such 
> code would
> be? The comments in table 51 of the current draft say
> 
>   template <std::size_t Len, class... Types>
>   struct aligned_union;
> 
>   The member typedef type shall be a pod type suitable for
>   use as uninitialized storage for any object whose type is
>   listed in Types; its size shall be at least Len. The static
>   member alignment_value shall be an integral constant of
>   type std::size_t whose value is the strictest alignment
>   of all types listed in Types.
> 
> The problem is that void and incomplete types don't have a size or
> alignment requirements. It appears that this is an oversight in the
> standard. The related trait alignment_of<T> requires that T be a
> complete type, a reference type, or an array of unknown 
> bound, but not a
> function type or cv-void type.
> 
> Now I could implement aligned_union<> to ignore incomplete types (they
> have no alignment requirement), but this might cause problems 
> if someone
> tried to use the result.

How so?  If someone uses only such types in the list (probably a very
rare use case), a zero result should be expected.  If alignable types
are mixed with such non-alignable types, the result would be as if no
such non-alignable types were given.

So I'd say just ignore non-alignable types.

Brad.

Mime
View raw message