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 18:34:48 GMT
 

> -----Original Message-----
> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com] 
> Sent: Wednesday, June 18, 2008 11:04 AM
> To: dev@stdcxx.apache.org
> Subject: RE: preconditions for aligned_union
> 
>  
> 
> >Eric Lemings wrote:
> > 
> >> Travis Vitek wrote:
> >> 
> >> 
> >> 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;
> >> 
> >> [...]
> >> 
> >> 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.
> 
> What if none of the provided types have an alignment requirement or
> size? What should the alignment be? What should the size be?

Undefined?

> 
> >
> >So I'd say just ignore non-alignable types.
> 
> So you see no problem with the following code failing at 
> runtime due to
> misalignment or insufficient space?
> 
>   struct incomplete_t;
> 
>   // supposed to be 'suitable for use as uninitialized
>   // storage for any object whose type listed and will
>   // be at least Len bytes
>   std::aligned_union<1, incomplete_t>::type aligned_buf;
> 
>   struct incomplete_t
>   {
>     long double val;
>     // [...]
>   };
> 
>   void save_value (const long double& v)
>   {
>       ((incomplete_t*)&aligned_buf)->val = v;
>   }

Yeah, that could be problematic...if the standard actually
allows it.

> 
> I'm pretty sure that the standard assumes we will use
> std::alignment_of<> and std::aligned_storage<> to implement
> std::aligned_union<>. If that is the case, then the 
> requirement for the
> type to be complete would be implied.

The only other possible course of action that I see is to check
for incomplete and other non-alignable types at compile-time
and generate a diagnostic.  Not sure how you would do that
with type traits but, if its possible, that might be more
"well-behaved".

Brad.

Mime
View raw message