CODEWITHSUNDEEP
c++value-initialization
James McNellis
James McNellis

Reputation: 355207

Explicit Type Conversion and Multiple Simple Type Specifiers

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).

Upvotes: 8

Views: 2077

Answers (4)

James McNellis
James McNellis

Reputation: 355207

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)

Upvotes: 8

smerlin
smerlin

Reputation: 6566

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
...

Upvotes: -2

Potatoswatter
Potatoswatter

Reputation: 137880

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.

Upvotes: 1

Jerry Coffin
Jerry Coffin

Reputation: 490398

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").

Upvotes: 1

Related Questions