When I try to compile
template<int dim>
struct Foo
{
Foo(const int (&i)[dim]) {}
};
int main()
{
Foo<2> f = Foo<2>((int[2]){0}); // line 9
return 0;
}
I get the compilation error
test.cpp:9:31: error: no matching function for call to ‘Foo<2>::Foo(int [1])’
Apparently, the argument I pass to the constructor is regarded as an int[1]. Why isn't it regarded as an int[2] (which could then be casted to a const reference as expected by the constructor)? Shouldn't the missing elements be value-initialized according to 8.5.1 (7)?
After all, replacing line 9 with
int arg[2] = {0};
Foo<2> f = Foo<2>(arg);
lets me compile the program. Additionally, when I try to pass (const int [2]){0, 0, 0} to the constructor, I get the error message too many initializers for ‘const int [2]’, so apparently, the compiler is trying to construct a const int[2].
Somebody please shed some light on this unintuitive behavior.
The construct (int[2]){0} is a C99 compound literal, which is not part of C++. How particular compilers interpret in the context of C++ is anyone's guess (or a matter of examining the source code).
PS. OK, it seems that gcc 4.7/gcc 4.8/clang-3.1 handle it quite sensibly - the type of the compound literal is the same as the C99 standard specifies it.
I guess the OP compiler is a bit older.
Related
This works:
int arr[10] = {};
All elements of arr are value-initialized to zero.
Why doesn't this work:
std::array<int, 10> arr({});
I get the following warning from g++ (version 4.8.2):
warning: missing initializer for member ‘std::array<int, 10ul>::_M_elems’
There are two issues one which is a matter of style and the warning.
Although it may not be obvious, aggregate initialization is happening on a temporary which is then being used as an argument to the copy constructor. The more idiomatic to do this initialization would be as follows:
std::array<int, 10> arr = {};
Although this still leaves the warning.
The warning is covered by gcc bug report: - -Wmissing-field-initializers relaxation request and one of the comments says:
[...]Surely, the C++ syntax of saying MyType x = {}; should be supported,
as seen here:
http://en.cppreference.com/w/cpp/language/aggregate_initialization
where for instance:
struct S {
int a;
float b;
std::string str;
};
S s = {}; // identical to S s = {0, 0.0, std::string};
That shouldn't warn for the reasons stated in earlier comments.
and a follow-up comment says:
My statement about zero-initialization was inaccurate (thanks), but
the general point still stands: in C you have to write ' = {0}' since
empty-braces initializer is not supported by the language (you get a
warning with -pedantic); in C++, you can write ' = {}' or 'T foo =
T();', but you don't need to write ' = {0}' specifically.
The latest versions of gcc does not produce this warning for this case, see it live working with gcc 5.1.
We can see this topic also covered in the Clang Developers lists in the thead: -Wmissing-field-initializers.
For reference the draft C++11 standard section 8.5.1 [dcl.init.aggr] says:
If there are fewer initializer-clauses in the list than there are
members in the aggregate, then each member not explicitly initialized
shall be initialized from an empty initializer list (8.5.4). [
Example:
struct S { int a; const char* b; int c; };
S ss = { 1, "asdf" };
initializes ss.a with 1, ss.b with "asdf", and ss.c with the value of
an expression of the form int(), that is, 0. —end example ]
So as this is valid C++, although as noted using {} is not valid C99. One could argue that it is only a warning, but this seems like idiomatic C++ using {} for aggregate initialization and is problematic if we are using -Werror to turn warnings into errors.
Firstly, you can use the ({}) initializer with an std::array object, but semantically that stands for direct-initialization using copy-constructor from a temporary value-initialized std::array object, i.e. it is equivalent to
std::array<int, 10> arr(std::array<int, 10>{});
And it is actually supposed to compile.
Secondly, you don't really have to go the ({}) way when you can just do
std::array<int, 10> arr = {};
or
std::array<int, 10> arr{};
The first of the two is the most syntactically similar to your int arr[10] = {};, which makes me wonder why you didn't try it at first. Why did you decide to use ({}) instead of = {} when you built the std::array version of = {} syntax?
Enough people have pointed this out as a "problem" when compiling with -Werror that I think it's worth mentioning that the problem goes away if you just double up:
std::array<int, 10> arr{{}};
Does not produce any warning for me on gcc 4.9.2.
To add a bit as to why this solves it: my understanding was that std::array is actually a class with a C array as its only member. So double up on the braces makes sense: the outer braces indicate you are initializing the class, and then the inner braces default initialize the one and only member of the class.
Since there is no possible ambiguity when there is only one variable in a class, just using one pair of {} should be reasonable, but gcc is overly pedantic here, and warns.
I was amazed to find out that GCC allows functions to return arrays when trailing return type is used instead of normal one. As you probably knows arrays can't be copied so this is quite limited but let me show you some cool example.
#include <iostream>
#include <typeinfo>
using namespace std;
auto func() -> int [5]
{
return {4, 56, 78, 4, 0};
}
int main()
{
cout << func()[2] << endl;
cout << typeid(func).name() << endl;
}
Is this a compiler bug or some new feature?
Interestingly 'typeid' returns 'FA5_ivE' which is demangled as 'int (()) [5]' and this means exactly what you think an function returning array of 5 int's.
EDIT: I tried bounding the returned array into rvalue reference but without any success (used most of the possible forms):
auto &&refArrayTemp{ func() };
Seems that this extensions is rather useless.
This was a bug in gcc (fixed as of 2017-07-03), caused by inconsistent treatment of trailing-return-types.
First note the difference in error message between two attempts to declare a function returning a function:
using Fv = void();
Fv f1(); // error: 'f1' declared as function returning a function
auto f2() -> Fv; // error: function return type cannot be function
The first error comes from decl.c, handling declarators, while the second is a lot deeper into the internals, from tree.c, attempting to build the function type preparatory to generating code.
Trailing-return-types are handled in decl.c 30 lines below the above error - too late to catch it with the above error code, and it is not handled separately.
With arrays, similarly using a trailing-return-type allows us to skip the checks in decl.c, the difference being that function-returning-array is actually valid in terms of gcc's internal representation.
Note that you can't do much with it; gcc doesn't allow you to assign, reference-bind, decay or pass the result of func() to another function:
auto a1 = func();
// error: invalid use of non-lvalue array
auto& a2 = func();
// error: invalid initialization of non-const reference of type 'int (&)[5]' from an rvalue of type 'int [5]'
auto&& a3 = func();
// error: lvalue required as unary '&' operand
Indeed, even your code is rejected at -Wpedantic:
warning: ISO C++ forbids subscripting non-lvalue array
Finally, by exploiting a similar bug (qualifiers are stripped from scalars before handling of trailing-return-types) we can create a function with type int const volatile():
int const volatile g1(); // warning: type qualifiers ignored on function return type
auto g2() -> int const volatile; // OK!!
Latest draft, [dcl.array]/p10:
Functions shall not have a return type of type array or function, although they may have a return type of
type pointer or reference to such things. There shall be no arrays of functions, although there can be arrays
of pointers to functions.
This could be a non-standard GCC extension. It doesn't compile in the trunk version of clang. However, this may also be a bug since it has inconsistent behavior with a non-trailing return type.
Do the following four different syntax do the same thing when initializing a constant data member, of type int for example, in C++ 11? If not, what is the difference?
{
const int a = 5; //usual initialization, "=" is not assignment operator here it is an initialization operator.
}
{
const int a(5); //calling the constructor function directly
}
{
const int a = {5}; //similar to initializing an array
}
{
const int a{5}; //it should work, but visual studio does not recognizing it
}
Why is the fourth one not recognized by Visual Studio as a valid statement?
They are all valid and the same in Visual Studio 2013 (the last one is not valid in VS2012 as #remyabel suggested).
The two {...} syntaxes can differ from the others in what constructor is called for a type, but the type int uses no constructor.
They will differ when constructing a class that accepts a std::initializer_list<T>.
Take, for example, this constructor that has - in some form - always been a part of std::vector
explicit vector( size_type count ... );
And this one that was added in C++11
vector( std::initializer_list<T> init, const Allocator& alloc = Allocator() );
Here, vector<int>(5) will call the first constructor and make a vector size 5.
And vector<int>{5} will call the second and make a vector of a single 5.
In C++03 these are equivalent
const int a = 3;
const int a(3);
In C++11 the uniform initialization syntax was introduced and thus
const int a{3};
const int a = {3};
are allowed and are equivalent. However, the first two and the second two are NOT equivalent in all cases. {} doesn't allow narrowing. For example
int abc = {12.3f};
int xyz(12.3f);
Here's what GCC says
error: type 'float' cannot be narrowed to 'int' in
initializer list [-Wc++11-narrowing]
int abc = {12.3f};
^~~~~
warning: implicit conversion from 'float' to 'int'
changes value from 12.3 to 12 [-Wliteral-conversion]
int abc = {12.3f};
~^~~~~
So the former begot an error, while the latter, just a warning.
Caveats in the uniform initialization syntax: If a was an object of a type accepting std::initializer_list, then const MyClass a = { 1 } would mean you're using that constructor and not the constructor taking a single int even if it was available (explained in Drew's anwer); If you want to choose the other constructor, then you've to use the () syntax. If a was an array, then you're using aggregate initialization.
See here for various initialization options available in C++.
Visual Studio 2012 doesn't support this syntax. It is however implemented in VS2013. The documentation for initializers in the VS2012 tab doesn't describe any way of using direct initialization with braces (aka,direct-list-initialization). The following is MSVC's documentation on valid initializer syntax, it doesn't necessarily reflect what's valid from a language lawyer point of view.
Declarators can specify the initial value for objects. The only way to
specify a value for objects of const type is in the declarator. The
part of the declarator that specifies this initial value is called the
initializer. There are two fundamental types of initializers:
Initializers invoked using the equal-sign syntax, including aggregate initializers:
= expression
= { expression-list }
= { { expression-list}, {expression-list}, . . . }
Initializers invoked using function-style syntax:
( expression )
Coding style is ultimately subjective, and it is highly unlikely that substantial performance benefits will come from it. But here's what I would say that you gain from liberal use of uniform initialization:
All 4 statements are valid and they are the same.
const int a = 5; -> Anyways, is the normal initialization syntax.
No need of explanation.!
const int a(5); -> function type initialization
const int a = {5}; -> Array type initialization
const int a{5}; -> It is not allowed in Visual Studio 2012, But, Initializer list support has been added in Visual Studio 2013. Hence const int a{5} , compiles fine with out any issues in VS2013.
But,
The only real power you give up is narrowing. You cannot initialize a smaller value with a larger one with uniform initialization.
int val{5.5};
That will not compile. You can do that with old-fashioned initialization, but not uniform initialization.
In C++11 a new feature was introduced where the programmer can initialize class member variables inside class's definition, see code below:
struct foo
{
int size = 3;
int id = 1;
int type = 2;
unsigned char data[3] = {'1', '2', '3'};
};
Is this initialization takes place during compile time or this feature is just syntactic sugar and member variables are initialized in the default constructor?
First of all yes, as stated before, it is syntactic sugar. But since the rules can be too much to remember, here's a logical experiment to help you figure out what happens in compile time and what not
You have your c++11 class that features in class initializers
struct foo { int size = 3; };
And another class that will help us with our experiment
template<int N>
struct experiment { enum { val = N }; };
Let our hypothesis H0 be that initialization does happen in compile time, then we could write
foo a;
experiment<a.size> b;
No luck, we fail to compile. One could argue that failure is due to foo::size being non constant so lets try with
struct foo { const int size = 3; }; // constexpr instead of const would fail as well
Again, as gcc informs us
the value of ‘a’ is not usable in a constant expression
experiment b;
or (more clearly) visual studio 2013 tells us
error C2975: 'N' : invalid template argument for 'example', expected compile-time constant expression
So, we have to discard H0 and deduce that initialization does not happen in compile time.
What would it take to happen in compile time
There is an old syntax that does the trick
struct foo { static const int size = 3; };
Now this compiles but beware this is (technically and logically) no longer in class initialization.
I had to lie for a little to make a point, but to expose the whole truth now : Message errors imply that a is the real problem. You see, since you have an instance for an object (Daniel Frey also mentions this) memory (for members) has to be initialized (at runtime). If the member was (const) static, as in the final example, then it's not part of the subobjects of a(ny) class and you can have your initialization at compile time.
In-class initialisers for member-variables are syntactic sugar for writing them in the constructor initialiser list, unless there's an explicit initialiser already there, in which case they are ignored.
In-class initialisers of static const members are for constant literals, a definition is still needed (though without initialiser).
C++ has the "as if"-rule from C, so anything resulting in the prescribed observed behavior is allowed.
Specifically, that means static objects may be initialised at compile-time.
It's just syntactic sugar. Also consider that an instance usually means memory which has to be initialized with the correct values. Just because these values are provided with a different syntax does not change the fact that the memory needs to be initialized - which happens at run-time.
Its essentially syntactic sugar for a user provided constructor which initializes the values. You are providing default values for data members. When you ask whether this happens at compile time or run time, the answer depends on the context its used in.
Hopefully, these examples will help. Try them in http://gcc.godbolt.org and see the dissassembly and compilation errors.
struct S { int size = 3; };
//s's data members are compile time constants
constexpr S s = {};
//r's data members are run time constants
const S r = {};
//rr's data members are run time constants,
//but we don't know the values in this translation unit
extern const S rr;
template <int X> class Foo {};
//Ok, s.size is a compile time expression
Foo<s.size> f;
//Error, r.size is not a compile time expression
Foo<r.size> g;
//Compile time expression, this is same as return 3;
int foo() { return s.size; }
//This also works
constexpr int cfoo() { return s.size; }
//Compiler will optimize this to return 3; because r.size is const.
int bar() { return r.size; }
//Compiler cannot optimize, because we don't know the value of rr.size
//This will have to read the value of rr.size from memory.
int baz() { return rr.size; }
As others have shown, static data members (and global variables, same thing essentially) for primitive types such as ints and floats have some weird rules where they can be const but still be used in compile time contexts as if they were constexpr. This is for backwards compatibility with C and the lack of the constexpr feature in the past. Its unfortunate now because it just makes understanding constexpr and what differentiates run time expressions from compile time expressions more confusing.
Having int size = 3; is exactly equivalent to having int size; and then each constructor that doesn't already have size in its initializer list (including compiler-generated constructors) having size(3) there.
Strictly speaking C++ doesn't have a distinction between "compile-time" and "run-time".
Why does the first commented line compile correctly, whereas the second doesn't?
Why can a be given itself as a constructor argument, but b can't?
Aren't the two doing the same thing?
class Foo { Foo &operator =(Foo const &); /* Disable assignment */ };
int main()
{
Foo a = a; // OK
Foo b(b); // error C2065: 'b' : undeclared identifier
}
Update
Since it seems like it's compiler-dependent, it seems like the problem is more severe than I thought.
So I guess another part of the question is, is the following code valid or no?
It gives an error in GCC but Visual C++ executes it just fine.
int main()
{
int i = 0;
{ int *i(&i); }
return i;
}
In your first code, both declarations should compile. GCC is right there. Visual C++ Compiler has bug.
And in the second code, the inner declaration should not compile. GCC is right there too, and VC++ is wrong.
GCC is right in both cases.
A code like int a=a+100; and int a(a+100); is fine from syntax point of view. They might invoke undefined behavior depending on whether they're created in static storage duration or automatic storage duration.
int a = a + 100; //well-defined. a is initialized to 100
//a on RHS is statically initialized to 0
//then a on LHS is dynamically initialized to (0+100).
void f()
{
int b = b + 100; //undefined-behavior. b on RHS is uninitialized
int a = a + 50; //which `a` is on the RHS? previously declared one?
//No. `a` on RHS refers to the newly declared one.
//the part `int a` declares a variable, which hides
//any symbol with same name declared in outer scope,
//then `=a+50` is the initializer part.
//since a on RHS is uninitialized, it invokes UB
}
Please read the comments associated with each declaration above.
Note that variables with static storage duration is statically initialized to zero at compile time, and if they've initializer, then they're dynamically initialized also at runtime. But variables of POD types with automatic storage duration are not statically initialized.
For more detail explanation on static initialization vs dynamic initialization, see this:
What is dynamic initialization of object in c++?
In your first example, as you note, the behavior is undefined even though the syntax is okay. A compiler is therefore permitted to refuse the code (the undefined behavior must be guaranteed however; it is here, but it wouldn't be if the invalid initializations were never actually executed).
Your second example has a type error: A declaration is visible as soon as its declarator is seen, and in particular it is visible in its own initializer. MSVC++ delays the visibility: That's a known non-conformance issue in that compiler. E.g., with the EDG compiler (which has a Microsoft mode):
$ ./cfe --strict x.c
"x.c", line 4: error: a value of type "int **" cannot be used to initialize an
entity of type "int *"
{ int *i(&i); }
^
1 error detected in the compilation of "x.c".
$ ./cfe --microsoft x.c
"x.c", line 4: warning: variable "i" was declared but never referenced
{ int *i(&i); }
^