Captain Pedantic to the Rescue!
If you write
int(value)
This is what's known as an explicit type conversion and is governed by §5.2.3. The exact wording says that
A simple-type-specifier (7.1.5) followed by a parenthesized expression-list constructs a value of the specified type given the expression list. If the expression list is a single expression, the type conversion expression is equivalent (in definedness, and if defined in meaning) to the corresponding cast expression (5.4)
(My emphasis). So this means that
int(value)
and
(int)value
are completely identical to one another. It's up to you to pick whichever of these you find easier to write.
As for your second question, in the example you gave with the templates and array, I believe that what you meant to write was something like this.
template <typename T, size_t N>
size_t (T (&)[N]) {
return N;
}
Here, N as well as T is a template parameter, which allows you to pass in any array that you'd like while having the compiler fill in N with the number of elements in the array. In case this looks confusing (what on earth is T (&)[N]?), it's because this function is taking in a parameter of type T (&)[N]. To make this a bit easier to read, let's give this parameter a name, as shown here:
template <typename T, size_t N>
size_t (T (&array)[N]) {
return N;
}
I think this makes this a bit easier to read. But what does this declaration mean?
T (&array)[N]
This declares a variable called array that is a reference to an array of Ts of exactly N elements. You can indeed declare references to arrays, just as you can declare pointers to arrays. This is not very common in practice, but in this particular template idiom is a great way of having the compiler infer the size of the array for you as it tries to match the array to the template argument.
The reason for the parentheses in this case is that if you write
T& array[N]
The compiler would parse this as "a variable called array that's an array of N objects, each of which is a T&. However, the C++ spec specifically disallows arrays of references, and this would be illegal. The parentheses explicitly disambiguate this. This is similar to function pointers - you write
void (*functionPointer)()
instead of
void *functionPointer()
To make the compiler realize that the * means that functionPointer is a pointer, rather than a function that returns a void *.
As for how the compiler determines when to treat parentheses in each way, the rules are fairly complex and there are actually a few circumstances in which the compiler will not parse your expression in the intended way. One of these cases is something colloquially referred to as "the most vexing parse" in which the compiler treats what looks like object construction as a function prototype. As an example, this code:
vector<int> v();
Does not create a vector<int> called v initialized using the default constructor. Instead, it treats this as a function prototype for a function called v that takes no arguments and produces a vector<int>! However, if you were to write
vector<int> v(10);
Then the compiler can unambiguously infer that this is a declaration of a vector<int> passing 10 as a constructor argument, because there's no way that it could be treated as a function prototype. §6.8 and §8.2 of the spec handles these cases by saying that anything that can be treated as a declaration will be, and anything that can be treated as a function prototype will be as well.
The case of parentheses in the context of the array (that is, T (&array)[N]) is handled by a different piece of logic because in the context in which you're declaring a variable or defining a parameter whose type requires explicit parenthesis, there can be no ambiguity about your intention because it's clear from context that you're naming a type in order to declare a variable.
To summarize -
- Casts of the form
T(value) and (T)value are identical.
- The parentheses in
T (&array)[N] are to prevent the compiler from binding the & to T instead of to array as intended.
- The particular use of parenthesis is usually inferred from context, though some issues can come up between variable declarations and function prototypes.
Hope this helps!
