RE: preconditions for aligned_union
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
RE: preconditions for aligned_union
> -Original Message-
> From: Travis Vitek [mailto:[EMAIL PROTECTED]
> 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.
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?
>
>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;
}
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.
Travis
RE: preconditions for aligned_union
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > 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 > 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 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.
