To value initialize an object of type T
, one would do something along the lines of one of the following:
T x = T();
T x((T()));
My question concerns types specified by a combination of simple type specifiers, e.g., unsigned int
:
unsigned int x = unsigned int();
unsigned int x((unsigned int()));
Visual C++ 2008 and Intel C++ Compiler 11.1 accept both of these without warnings; Comeau 4.3.10.1b2 and g++ 3.4.5 (which is, admittedly, not particularly recent) do not.
According to the C++ standard (C++03 5.2.3/2, expr.type.conv):
The expression T()
, where T
is a simple-type-specifier (7.1.5.2) for a non-array complete object type or the (possibly cv-qualified) void
type, creates an rvalue of the specified type, which is value-initialized
7.1.5.2 says, "the simple type specifiers are," and follows with a list that includes unsigned
and int
.
Therefore, given that in 5.2.3/2, "simple-type-specifier" is singular, and unsigned
and int
are two type specifiers, are the examples above that use unsigned int
invalid? (and, if so, the followup is, is it incorrect for Microsoft and Intel to support said expressions?)
This question is more out of curiosity than anything else; for all of the types specified by a combination of multiple simple type specifiers, value initialization is equivalent to zero initialization. (This question was prompted by comments in response to this answer to a question about initialization).
I posted this question to comp.lang.c++.moderated.
Daniel Krügler of the C++ standards committee agreed with the interpretation that unsigned int
is a combination of simple type specifiers, and is not itself a simple type specifier.
Concerning the caption of table 7 referenced by Jerry Coffin, Krügler says:
I agree that the header of Table 7 (which is Table 9 in the most
recent draft N3000) is somewhat misleading, but the preceeding
text in [dcl.type.simple]/2 looks very clear to me, when it says:
Table 7 summarizes the valid combinations of simple-type-specifiers
and the types they specify."
(I apologize it took me so long to post this back here from the newsgroup; it completely slipped my mind)
In §7.1.5.2, keep reading down to table 7, which has the full list of what's allowed as a simple specifier (which does include "unsigned int").
Hmm, sometimes you need a typedef. If it doesn't say a diagnostic is required, then it's not incorrect for them to support this. Nevertheless, for portability, you can use a typedef (uint16_t
or uint64_t
, although those might not be right), or quote the typename with a template:
iterator<void, unsigned long>::value_type( 5 )
How's that for unreasonably verbose?
Edit: Duh, or simply 5ul
. That leaves unsigned short
, unsigned char
, and signed char
as the only types you can't easily explicitly construct.
7.1.5.2:
The simple-type-specifiers specify either a previously-declared user-defined type or one of the fundamental types`
This implies that unsigned int i = unsigned int()
is legal, since unsigned int
is a fundamental type (and thus a simple-type-specifier, see 3.9.1).
same applies for types like:
long double
long long
long long int
unsigned long
unsigned long long int
short int
...