RE: :decay related question
>Eric Lemings wrote: > >Page 490, section 20.3.1.2, paragraph 1 in the latest draft says this: > >"Let Ui be decay::type for each Ti in Types. Then each Vi in VTypes >is X& if Ui equals reference_wrapper, >otherwise Vi is Ui." > >What do you suppose the relationship is between type `X' and types `Ti' >and `Ui'? I see how the latter two types are deduced from the >type list >`Types' but not so sure about how type `X' is deduced from `Types'. I'm looking at this and I have no idea where VTypes and X are coming from. Is that an issue, or am I missing something? That said, I think X is supposed to be Ti. If that were the case then the definition would make some sense [at least to me]. Let Ui be decay::type for each Ti in Types. Then each Vi in VTypes is Ti& if Ui equals reference_wrapper, otherwise Vi is Ui. If that is right, then it essentially says that the 'make_tuple' function transforms reference_wrapper back to T& and for other types does the normal decay transformation [function to funciton pointer, array to array pointer, and cv-stripping of all other types]. Travis > >Brad. >
std::decay related question
Page 490, section 20.3.1.2, paragraph 1 in the latest draft says this: "Let Ui be decay::type for each Ti in Types. Then each Vi in VTypes is X& if Ui equals reference_wrapper, otherwise Vi is Ui." What do you suppose the relationship is between type `X' and types `Ti' and `Ui'? I see how the latter two types are deduced from the type list `Types' but not so sure about how type `X' is deduced from `Types'. Brad.
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
dev@stdcxx.apache.org
Consider the following: file $TOPDIR/include/memory: ... 30 #ifndef _RWSTD_MEMORY_INCLUDED 31 #define _RWSTD_MEMORY_INCLUDED 32 33 #include 34 #include 35 #include 36 #include 37 #include 38 #include 39 #include 40 41 #endif // _RWSTD_MEMORY_INCLUDED Any idea why is included last? I've noticed this in a couple other standard headers also. Brad.
RE: question on Warning on AIX
> -Original Message- > From: Farid Zaripov [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 18, 2008 10:35 AM > To: dev@stdcxx.apache.org > Subject: RE: question on Warning on AIX > > > -Original Message- > > From: Jeremy Dean [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 18, 2008 7:19 PM > > To: dev@stdcxx.apache.org > > Subject: question on Warning on AIX > > > > I have a customer that is getting hundrends of warnings like > > this. The customer is checking to make sure that these are > > nothing to be concerned about or how to resolve the warnings: > > > > "/usr/local/rogue/RogueWave/SourcePro/Ed10/include/loc/_num_get.cc", > > line 126.22: 1540-0840 (W) The integer literal > > "0x7fffL" is out of range. > > "/usr/local/rogue/RogueWave/SourcePro/Ed10/include/streambuf", line > > 179.25: 1540-0840 (W) The integer literal > > "0x7fffL" is out of range. > > Perhaps he compiling 32-bit (ILP32) program with using config.h > generated for 64-bit (LP64) library? I've seen other projects/packages put details about the target environment (hostname, OS, build type, etc.) right inside the configuration header. It's possible we could do something similar and then use these details to generate errors/warnings when the details don't match. Brad.
RE: question on Warning on AIX
Could be an error in a configuration test. Is this a 32-bit or 64-bit machine? How about the build? What are his/her configured values for _RWSTD_INT_MAX and _RWSTD_PTRDIFF_MAX from $BUILDDIR/include/config.h? Brad. > -Original Message- > From: Jeremy Dean [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 18, 2008 10:19 AM > To: dev@stdcxx.apache.org > Subject: question on Warning on AIX > > I have a customer that is getting hundrends of warnings like > this. The > customer is checking to make sure that these are nothing to > be concerned > about or how to resolve the warnings: > > "/usr/local/rogue/RogueWave/SourcePro/Ed10/include/loc/_num_get.cc", > line 126.22: 1540-0840 (W) The integer literal > "0x7fffL" is > out of range. > "/usr/local/rogue/RogueWave/SourcePro/Ed10/include/streambuf", line > 179.25: 1540-0840 (W) The integer literal "0x7fffL" is out > of range. > > > Thanks, > > Jeremy > >
RE: question on Warning on AIX
> -Original Message- > From: Jeremy Dean [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 18, 2008 7:19 PM > To: dev@stdcxx.apache.org > Subject: question on Warning on AIX > > I have a customer that is getting hundrends of warnings like > this. The customer is checking to make sure that these are > nothing to be concerned about or how to resolve the warnings: > > "/usr/local/rogue/RogueWave/SourcePro/Ed10/include/loc/_num_get.cc", > line 126.22: 1540-0840 (W) The integer literal > "0x7fffL" is out of range. > "/usr/local/rogue/RogueWave/SourcePro/Ed10/include/streambuf", line > 179.25: 1540-0840 (W) The integer literal > "0x7fffL" is out of range. Perhaps he compiling 32-bit (ILP32) program with using config.h generated for 64-bit (LP64) library? Farid.
question on Warning on AIX
I have a customer that is getting hundrends of warnings like this. The customer is checking to make sure that these are nothing to be concerned about or how to resolve the warnings: "/usr/local/rogue/RogueWave/SourcePro/Ed10/include/loc/_num_get.cc", line 126.22: 1540-0840 (W) The integer literal "0x7fffL" is out of range. "/usr/local/rogue/RogueWave/SourcePro/Ed10/include/streambuf", line 179.25: 1540-0840 (W) The integer literal "0x7fffL" is out of range. Thanks, Jeremy
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.
