[ 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 ]
"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
-- [ 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 ]
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
-- [ 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 ]
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."
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
-- [ 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 ]
> 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.
[ 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 ]
> "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.
[ 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 ]
[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.
[ 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 ]
> [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
-- [ 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 ]
James Dennett wrote: > On May 29, 1:25 pm, Pete Becker <p...@versatilecoding.com> wrote: >> 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.
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.
[ 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 ]
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.
> -- James
-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 ] [ 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 ]
>> 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.)
-- [ 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 ]
Joe Smith wrote: > 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 ] [ 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 ]
>> [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.
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 };
[ 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 ]
[ 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 ]
