type traits if void type
Mateusz Loskot
May I kindly ask for interpretation of correct/standard behavior of type
traits applied to void type?
What is expected output of the test below according to n2857?
#include <iostream>
#include <type_traits>
int main()
{
std::cout << std::is_pod<void>::value << std::endl;
std::cout << std::has_trivial_destructor<void>::value << std::endl;
}
Here is what I get:
1) GCC 4.3.3
0
0
2) Visual C++ 9.0 (cl 15.00.30729.01)
1
1
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
pl.comp.lang.c FAQ: http://pl.cpp.wikia.com/wiki/FAQ
C++ FAQ: http://parashift.com/c++-faq-lite
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
wasti...@gmx.net
> Hi,
>
> May I kindly ask for interpretation of correct/standard behavior of type
> traits applied to void type?
>
> What is expected output of the test below according to n2857?
>
> #include <iostream>
> #include <type_traits>
> int main()
> {
> std::cout << std::is_pod<void>::value << std::endl;
> std::cout << std::has_trivial_destructor<void>::value << std::endl;
>
> }
>
> Here is what I get:
>
> 1) GCC 4.3.3
>
> 0
> 0
>
> 2) Visual C++ 9.0 (cl 15.00.30729.01)
>
> 1
> 1
VC++ is wrong. void is not a POD type.
"Arithmetic types, enumeration types, pointer types, pointer to member
types, and std::nullptr_t, and cv-qualified versions of these types are
collectively called scalar types. Scalar types, POD classes, arrays of
such types and cv-qualified versions of these types are collectively
called POD types."
Since void is not a scalar type, nor a class, it cannot be a POD.
Sebastian
--
daniel....@googlemail.com
> May I kindly ask for interpretation of correct/standard behavior of type
> traits applied to void type?
>
> What is expected output of the test below according to n2857?
>
> #include <iostream>
> #include <type_traits>
> int main()
> {
> std::cout << std::is_pod<void>::value << std::endl;
> std::cout << std::has_trivial_destructor<void>::value << std::endl;
> }
>
> Here is what I get:
>
> 1) GCC 4.3.3
>
> 0
> 0
>
> 2) Visual C++ 9.0 (cl 15.00.30729.01)
>
> 1
> 1
>
The expected output is equivalent to that of gcc.
This can be easily read from the WP:
1) std::is_pod<void>: As of Table 33 the precondition is satisfied,
because cv-void is a feasible argument. The test conditions refers
to 3.9 [basic.types], where we find in p. 10:
"Arithmetic types (3.9.1), enumeration types, pointer types,
pointer to member types (3.9.2), and std::nullptr_t, and cv-
qualified versions of these types (3.9.3) are collectively called
scalar types. Scalar types, POD classes (Clause 9), arrays of
such types and cv-qualified versions of these types (3.9.3) are
collectively called POD types [..]"
and in 3.9.1 [basic.fundamental]/9:
"[..] Integral and floating types are collectively called arithmetic
types.[..]"
Therefore the test condition isn't satisfied, the result should
be false.
2) std::has_trivial_destructor<void>: The same Table 33
tells us that the test pre-conditions are satisfied, because
cv-void is a feasible argument.
Regarding the test result we end up in checking that
"T is a trivial type (3.9)" is the only relevant choice, but
according to 3.9 [basic.types]/10
"[..] Scalar types, trivial class types (Clause 9), arrays of such
types and cv-qualified versions of these types (3.9.3) are
collectively called trivial types."
we have a negative result again, because void is no scalar
type as shown above.
HTH & Greetings from Bremen,
Daniel Kr�gler
--
James Dennett
> Hi,
>
> May I kindly ask for interpretation of correct/standard behavior of type
> traits applied to void type?
>
> What is expected output of the test below according to n2857?
>
> #include <iostream>
> #include <type_traits>
> int main()
> {
> std::cout << std::is_pod<void>::value << std::endl;
void is not a POD type, so std::is_pod<void>::value must be false.
"Arithmetic types (3.9.1), enumeration types, pointer types, pointer
to member types (3.9.2), and std::nullptr_t, and cv-qualified versions
of these types (3.9.3) are collectively called scalar types. Scalar
types, POD classes (Clause 9), arrays of such types and cv-qualified
versions of these types (3.9.3) are collectively called POD types."
> std::cout << std::has_trivial_destructor<void>::value << std::endl;
has_trivial_destructor<T>::value is defined by "T is a trivial type
(3.9) or a reference type or a class type with a trivial destructor
(12.4) or an array of such a class type."
void is not a trivial type ("Scalar types, trivial class types (Clause
9), arrays of such types and cv-qualified versions of these types
(3.9.3) are collectively called trivial types."), so
has_trivial_destructor<void>::value is also false.
> Here is what I get:
>
> 1) GCC 4.3.3
>
> 0
> 0
I believe gcc has this right...
> 2) Visual C++ 9.0 (cl 15.00.30729.01)
>
> 1
> 1
VC++9 disagrees with me.
-- James
--
Mateusz Loskot
news:aaa536fd-909a-4607...@o18g2000yqi.googlegroups.com...
Daniel,
Now, everything is clear. Thanks to you too!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
pl.comp.lang.c FAQ: http://pl.cpp.wikia.com/wiki/FAQ
C++ FAQ: http://parashift.com/c++-faq-lite
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
Mateusz Loskot
news:a41628a4-e7d4-4546...@h28g2000yqd.googlegroups.com...
>
> On May 27, 6:55 pm, "Mateusz Loskot" <mate...@loskot.net> wrote:
>>
>> Hi,
>>
>> May I kindly ask for interpretation of correct/standard behavior of type
>> traits applied to void type?
>>
>> What is expected output of the test below according to n2857?
>>
>> #include <iostream>
>> #include <type_traits>
>> int main()
>> {
>> std::cout << std::is_pod<void>::value << std::endl;
>> std::cout << std::has_trivial_destructor<void>::value << std::endl;
>>
>> }
>>
>> Here is what I get:
>>
>> 1) GCC 4.3.3
>>
>> 0
>> 0
>>
>> 2) Visual C++ 9.0 (cl 15.00.30729.01)
>>
>> 1
>> 1
>
> VC++ is wrong. void is not a POD type.
>
> "Arithmetic types, enumeration types, pointer types, pointer to member
> types, and std::nullptr_t, and cv-qualified versions of these types are
> collectively called scalar types. Scalar types, POD classes, arrays of
> such types and cv-qualified versions of these types are collectively
> called POD types."
>
> Since void is not a scalar type, nor a class, it cannot be a POD.
Sebastian,
Understood. Thank you very much for confirmation.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
pl.comp.lang.c FAQ: http://pl.cpp.wikia.com/wiki/FAQ
C++ FAQ: http://parashift.com/c++-faq-lite
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
Pete Becker
>
> On May 27, 6:55 pm, "Mateusz Loskot" <mate...@loskot.net> wrote:
>>
>> Hi,
>>
>> May I kindly ask for interpretation of correct/standard behavior of type
>> traits applied to void type?
>>
>> What is expected output of the test below according to n2857?
>>
>> #include <iostream>
>> #include <type_traits>
>> int main()
>> {
>> std::cout << std::is_pod<void>::value << std::endl;
>> std::cout << std::has_trivial_destructor<void>::value << std::endl;
>>
>> }
>>
>> Here is what I get:
>>
>> 1) GCC 4.3.3
>>
>> 0
>> 0
>>
>> 2) Visual C++ 9.0 (cl 15.00.30729.01)
>>
>> 1
>> 1
>
> VC++ is wrong. void is not a POD type.
>
[tr.meta.req]/8 in TR1 requires is_pod<void>::value to be 1. n2857 is
not a standard, and implementations of previous standards are not
wrong for not doing what isn't yet required of them.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
James Dennett
> wasti.r...@gmx.net wrote:
>
> > On May 27, 6:55 pm, "Mateusz Loskot" <mate...@loskot.net> wrote:
>
> >> Hi,
>
> >> May I kindly ask for interpretation of correct/standard behavior of type
> >> traits applied to void type?
>
> >> What is expected output of the test below according to n2857?
>
> >> #include <iostream>
> >> #include <type_traits>
> >> int main()
> >> {
> >> std::cout << std::is_pod<void>::value << std::endl;
> >> std::cout << std::has_trivial_destructor<void>::value << std::endl;
>
> >> }
>
> >> Here is what I get:
>
> >> 1) GCC 4.3.3
>
> >> 0
> >> 0
>
> >> 2) Visual C++ 9.0 (cl 15.00.30729.01)
>
> >> 1
> >> 1
>
> > VC++ is wrong. void is not a POD type.
>
> [tr.meta.req]/8 in TR1 requires is_pod<void>::value to be 1. n2857 is
> not a standard, and implementations of previous standards are not
> wrong for not doing what isn't yet required of them.
TR1 does not define std::is_pod, only std::tr1::is_pod. The most
authoritative definitions of std::is_pod (and
std::has_trivial_destructor etc.) currently available are in the C++0x
drafts edited by your good self.
That said, I'd like to see real-world examples of code that depend on
the particular value of either of these traits for T=void. I can't
imagine how you'd use the knowledge that void is/is not POD, or does/
does not have a trivial destructor, when there are no objects of type
void.
-- James
--
Pete Becker
Under the current standard, using the name std::is_pod requires a
diagnostic. So if you want to be literal, both compilers are "wrong".
Nevertheless, neither is really "wrong", they just implement different
non-standard versions of is_pod.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
Rhialto
> That said, I'd like to see real-world examples of code that depend on
> the particular value of either of these traits for T=void. I can't
> imagine how you'd use the knowledge that void is/is not POD, or does/
> does not have a trivial destructor, when there are no objects of type
> void.
Once I dabbled in a C compiler which I extended to allow objects of type
void (and arrays with 0 elements, which was also officially forbidden).
You could write for instance
void func()
{
void a, b;
if (conditon)
a = func();
else
a = b;
return a;
}
all of which obviously without any "real assignment" activity. This
isn't very "useful" but I thought it was good for symmetry.
In this compiler, if it were a C++ compiler, void would be a POD type
and have a trivial destructor.
> -- James
-Olaf
--
___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse.
Joe Smith
"Rhialto" <rhi...@falu.nl> wrote in message
news:4a20fb36$0$194$e4fe...@news.xs4all.nl...
> James Dennett wrote:
>
>> That said, I'd like to see real-world examples of code that depend on
>> the particular value of either of these traits for T=void. I can't
>> imagine how you'd use the knowledge that void is/is not POD, or does/
>> does not have a trivial destructor, when there are no objects of type
>> void.
>
> Once I dabbled in a C compiler which I extended to allow objects of type
> void (and arrays with 0 elements, which was also officially forbidden).
> You could write for instance
>
> void func()
> {
> void a, b;
> if (conditon)
> a = func();
> else
> a = b;
> return a;
> }
>
> all of which obviously without any "real assignment" activity. This
> isn't very "useful" but I thought it was good for symmetry.
>
> In this compiler, if it were a C++ compiler, void would be a POD type
> and have a trivial destructor.
>
I agree that conceptually void is more of a pod type, than a non-pod type,
and logically the constructor is not non-trivial, so it would seem
reasonable for it to be considered trvially destructable.
So to me I actually slightly perfer the output of VC++9. Yes, it does not
match the current working paper, but I feel the working paper could
reasonably be changed there, and nobody would complain.
Of course your toy language above seems to have left out some of ther harder
decisions. Should the built-in types be implicitly convertible to void (or
should explicit casts to void be required)? Should a call to a function of
no paramaters be allowerd to have arguments of type void? Should a function
be allowed to have formal parameters of type void? Then if we look at a
similar C++ extention, we would need to consider how void arguments would
interact with overloading, and template deduction.
Of course, that might actually make "void()" (i.e. explictly creating an
rvalue of type void) actually useful in some circumstances (outside of
templates, which is the only place it might currently be useful.)
--
Rhialto
> Of course your toy language above seems to have left out some of the harder
> decisions.
I don't really recall if I tried to resolve those decisions in some way;
it was about 20 years ago and one of those night-time programming
projects. But I think I did it with the most minimal changes possible by
pretending in most places that variables of void type were similar to
other variables. So this would likely result in the following:
> Should the built-in types be implicitly convertible to void (or
> should explicit casts to void be required)?
Since both "func();" and "1;" are convertible to void without cast
(although some compilers give a warning on at least the second case),
"void a = func_returning_nonvoid();" would probably work the same.
> Should a call to a function of
> no paramaters be allowerd to have arguments of type void?
No. Although the declaration "int func(void);" (to indicate it has no
parameters) would confuse matters. I'm not sure what I did there. This C
syntax is weird anyway, and only needed for backwards compatibility with
pre-prototype C. C++ would not have this problem.
> Should a function
> be allowed to have formal parameters of type void?
Yes. And it would make different function signatures from "int func(int
a)" and "int func2(int a, void b);". Calling func2 would be a bit weird
if you have no variable of type void at hand, since you'd need a
denotation for a void object; something like "x = func2(1, (void)0);".
Somewhat weird. (The denotation "void()" you used looks better)
> Then if we look at a
> similar C++ extention, we would need to consider how void arguments would
> interact with overloading, and template deduction.
Expanding on the above, I'd say (if such a proposal were ever made) that
presence of void arguments would matter (i.e., they are not "optimized
away" before matching types for overloading and template deduction).
I am in fact just realising that a current wart in the overloading
system could have been done (slightly) more elegantly with a void
parameter: the difference between a pre- and post-inc/decrement operator
is currently made with a dummy "int" parameter. Using "void" there would
have been slightly neater.
-Olaf
--
___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
Mateusz Loskot
news:29d54583-85e6-4623...@r34g2000vba.googlegroups.com...
The is_pod<T> predicate is used in std library in Visual C++ 9.0 to implemet
other predicates, for instance has_trivial_destructor:
// TEMPLATE CLASS has_trivial_destructor
template<class _Ty>
struct has_trivial_destructor
: _Cat_base<is_pod<_Ty>::value || __has_trivial_destructor(_Ty)>
{ // determine whether _Ty has a trivial destructor
};
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
pl.comp.lang.c FAQ: http://pl.cpp.wikia.com/wiki/FAQ
C++ FAQ: http://parashift.com/c++-faq-lite
Mateusz Loskot
news:gvj6f4$4og$1...@inews.gazeta.pl...
> Hi,
>
> May I kindly ask for interpretation of correct/standard behavior of type
> traits applied to void type?
>
> What is expected output of the test below according to n2857?
>
> #include <iostream>
> #include <type_traits>
> int main()
> {
> std::cout << std::is_pod<void>::value << std::endl;
> std::cout << std::has_trivial_destructor<void>::value << std::endl;
> }
>
> Here is what I get:
>
> 1) GCC 4.3.3
>
> 0
> 0
>
> 2) Visual C++ 9.0 (cl 15.00.30729.01)
>
> 1
> 1
Just to complete the discussion, here is a short feedback from Microsoft:
ID:458570 - has_trivial_destructor applied to void returns true