Eric Lemings wrote:
>
>> Travis Vitek wrote:
>>
>> 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.
>
With the wording that is currently provided, I believe that the above
code is completely legal. That is why I brought up the issue in the
first place.
>>
>> 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".
Actually, detection is quite easy. The implementation of
__rw_aligned_union that I wrote a while back should detect it [I use a
union internally you can't put an incomplete type in a union]. Honestly
it would actually be much more trouble to allow it, but I'm pretty sure
it could be done.
I'm hoping that Martin will eventually be able to provide some
clarification or file a defect report for us.
Travis
