I can specify -std=c++0x for compilation with my g++ 4.4, and initializer lists are correct, I may use them (in c++98 I can't) but still get errors when try use auto keyword:
std::list< std::vector<int> > li2;
li2.push_back({1, 2, 3}); //push_back vector
li2.push_back({4, 2, 6}); //again, vector implicitly
for (auto& vv : li2) {
for (auto &i : v)
printf("element: %d\n", 8);
}
so I assume I can't use C++11 functionallities with g++4.4. I have 4.4 because of compatibility with CUDA.
This link shows you the different C++11 features supported by GCC. auto appeared in GCC 4.4.
Your real problem is probably that the ranged-based for loop appeared only in GCC 4.6.
Related
I have this snippet.
#include <algorithm>
#include <vector>
int main() {
std::vector<int> v1 = {1, 2, 3};
std::vector<int> v2 = {4, 5, 6};
return std::ranges::equal(v1, v2);
}
I compile it with GCC 10 (Debian stable) and everything's alright:
$ g++ -std=c++20 test.cpp -o test
<compiles fine>
I compile it with Clang 14 and libc++14 (Debian stable, installed from packages from apt.llvm.org):
$ clang++-14 -std=c++20 -stdlib=libc++ test.cpp -o test
test.cpp:8:25: error: no member named 'equal' in namespace 'std::ranges'
return std::ranges::equal(v1, v2);
~~~~~~~~~~~~~^
1 error generated.
Same for a lot of other things. Is libc++ support for the ranges library really so behind or am I missing something?
You can find an exhaustive table for implementations feature support here: https://en.cppreference.com/w/cpp/compiler_support
For C++20s "The One Ranges Proposal" where std::equal is part of the table says "13 (partial)".
There is another overview for clang here: https://clang.llvm.org/cxx_status.html#cxx20. Though it only lists language features.
I just came across a weird problem that happens ONLY on MSVC with Clion but not on other compilers(I tried gcc on Linux and Visual Studio both no such problem, with the same code).
With these codes:
#include <vector>
#include <algorithm>
using namespace std;
int main() {
vector<int>v = {1,2,3,4,5};
make_heap(v.begin(), v.end());
v.push_back(6);
push_heap(v.begin(), v.end());
}
an error "In instantiation of function template specialization 'std::push_heapstd::_Vector_iterator<std::_Vector_val<std::_Simple_types<int > > >' no type named 'value_type' in 'std::indirectly_readable_traitsstd::_Vector_iterator<std::_Vector_val<std::_Simple_types<int > > >'" will then be shown
is it a bug of Clion or MSVC?
P.S.
I can still build and run it so it might not be a compiler error; (Making me even more confused)
It looks like you cannot intialize vector with the following command:
vector<int>v = {1,2,3,4,5};
Change it to:
vector<int> vect{ 1, 2, 3, 4, 5 };
Compile and run the code and see if it still has problems.
EDIT:
Some people are saying it is unlikely however look at the link:
What is the easiest way to initialize a std::vector with hardcoded elements?
If you scroll down to the second answer it says:
If your compiler supports C++11, you can simply do:
std::vector<int> v = {1, 2, 3, 4};
As you did not tell us your compiler version and environment it is very hard to determine if this is the problem. Also note that:
This is available in GCC as of version 4.4.
Unfortunately, VC++ 2010 seems to be lagging behind in this respect.
So if you are using an older version of VC++ then you are out of luck...
Hi I am working through some C++ issues and I'm not familiar with the language.
I am trying to initialize a std::pair, double> with this syntax:
std::pair<std::vector<int>, double> output = { {}, 0.0f };
gcc 5.4.0 on Ubuntu 16.04 generates this error:
no known conversion for argument 1 from ‘std::pair<std::vector<int>, double>’ to ‘std::initializer_list<int>
The same error happens if I use this syntax:
std::pair<std::vector<int>, double> output{{}, 0.0f };
What is the issue?
You are using an extended initializer list (std::initializer_list) which is available since C++11.
For the gcc 5.4.0 compiler, you need to compile it with C++11 flag:
$ g++ main.cpp -std=c++11
https://gcc.godbolt.org/z/SHzREE
Consider the following program:
#include <array>
int main()
{
std::array<int, 1> x = { 0 }; // warning!
x = { { 0 } }; // no warning
return 0;
}
The first initialization leads to warnings on gcc 4.7.2...
main.cpp:5:22: warning: unused variable ‘x’ [-Wunused-variable]
... and clang 3.1
main.cpp:5:28: warning: suggest braces around initialization of subobject [-Wmissing-braces]
std::array<int, 1> x = { 0 };
As far as the standard goes, there should be no difference between double or single curly braces, at least in this example.
There are two ways to deal with the warning:
Just turn it off
Fix the code, so the compiler is happy
What do you propose? IMHO, the double curly expression looks somewhat ugly. On the other hand, the warning might detect real problems in more complicated examples. Do you know an example where the warning would have helped you?
-Wmissing-braces will no longer be enabled in GCC's -Wall (for C++ mode), as of 4.8, for precisely the reason you describe. For current versions of GCC, either disable or ignore the warning, the code you have is written the way it should be.
The warning is probably meant to cover code such as
struct A { int a; int b; };
struct B { A a; int b; };
B b = {
1,
2 // initialises b.a.b, not b.b
};
However, IMHO, that is already handled well enough by -Wmissing-field-initializers, which does not warn about your original code.
I get the same warning in Xcode 6.1.1 (the current version as of March 9, 2015). When I add the extra braces around each subobject I get an error. When I add an extra set of braces around the entire initialization list then the warning goes away. According to the standard specification 14882:2011 23.3.2.1 [array.overview] subsection 2 explicitly states
array<T, N> a = { initializer-list };
where initializer-list is a comma-separated list of up to N elements
whose types are convertible to T
result of code in Xcode 6.1.1 (below)
array<int, 2> key1 = {1, 2}; // warning: suggest braces around initialization of subobject
array<int, 2> key2 = { {1}, {2} }; // error: no viable overload =
array<int, 2> key3 = array<int, 2> { {1}, {2} }; // error: excess elements in struct initializer
array<int, 2> key4 = { {1, 2} }; // no warning and no error
When we look at 14882:2011 8.5 [dcl.init] subsection 1 we see that an 'initializer-list' can optionally contain an 'initializer-clause', which itself can be a 'braced-init-list'. So either way should be correct. Though based on the spec I personally think single braces shouldn't output a compiler warning for a std::array initializer-list, and double braces is overkill.
Clang 6.0 suppresses the warning about missing braces. The svn log says:
Suppress -Wmissing-braces warning when aggregate-initializing a struct with a single field that is itself an aggregate. In C++, such initialization of std::array types is guaranteed to work by the standard, is completely idiomatic, and the "suggested" alternative from
Clang was technically invalid.
So I would omit the braces and disable -Wmissing-braces for Clang prior to 6.0 if it needs to be supported.
When ignoring the Clang warning with -Wno-missing-braces, I would recommend to enable -Wmissing-field-initializers (or use -Wextra, which also includes it). Otherwise, you miss a useful warning like in this example:
#include <cstdio>
struct A
{
int i;
int arr[2];
int j;
};
void print(const A& a)
{
printf("i=%d, arr={%d,%d}, j=%d\n", a.i, a.arr[0], a.arr[1], a.j);
}
int main() {
A a = {1, 2, 3}; // this is the critical line
print(a); // output: i=1, arr={2,3}, j=0
A b = {1, {2}, 3};
print(b); // output: i=1, arr={2,0}, j=3
A c = {1, {2,0}, 3};
print(c); // output: i=1, arr={2,0}, j=3
return 0;
}
$ clang++ -Wall example.cpp
example.cpp:16:13: warning: suggest braces around initialization of
subobject [-Wmissing-braces]
A a = {1, 2, 3};
^~~~
{ }
1 warning generated.
$ clang++ -Wall -Wno-missing-braces example.cpp
(no warnings)
$ clang++ -Wall -Wno-missing-braces -Wmissing-field-initializers example.cpp
example.cpp:16:17: warning: missing field 'j' initializer
[-Wmissing-field-initializers]
A a = {1, 2, 3};
^
1 warning generated.
$ clang++ --version
clang version 3.8.1 (tags/RELEASE_381/final)
For comparison, this is what GCC does:
$ g++ -Wall -Wextra example.cpp
(no warning)
$ g++ -Wall -Wmissing-field-initializers example.cpp
example.cpp: In function ‘int main()’
example.cpp:16:17: warning: missing initializer for member ‘A::j’ [-Wmissing-field-initializers]
A a = {1, 2, 3};
^
In summary:
For Clang, I would recommend -Wno-missing-braces -Wmissing-field-initializers to silence the warning without loosing other useful warnings
GCC does not complain in the original std::array<int, 1> x = { 0 }; example, so there is no need to disable any warnings. However, I would recommend to enable -Wmissing-field-initializers (or use -Wextra), as it is not enabled by -Wall.
Consider the following program:
#include <array>
int main()
{
std::array<int, 1> x = { 0 }; // warning!
x = { { 0 } }; // no warning
return 0;
}
The first initialization leads to warnings on gcc 4.7.2...
main.cpp:5:22: warning: unused variable ‘x’ [-Wunused-variable]
... and clang 3.1
main.cpp:5:28: warning: suggest braces around initialization of subobject [-Wmissing-braces]
std::array<int, 1> x = { 0 };
As far as the standard goes, there should be no difference between double or single curly braces, at least in this example.
There are two ways to deal with the warning:
Just turn it off
Fix the code, so the compiler is happy
What do you propose? IMHO, the double curly expression looks somewhat ugly. On the other hand, the warning might detect real problems in more complicated examples. Do you know an example where the warning would have helped you?
-Wmissing-braces will no longer be enabled in GCC's -Wall (for C++ mode), as of 4.8, for precisely the reason you describe. For current versions of GCC, either disable or ignore the warning, the code you have is written the way it should be.
The warning is probably meant to cover code such as
struct A { int a; int b; };
struct B { A a; int b; };
B b = {
1,
2 // initialises b.a.b, not b.b
};
However, IMHO, that is already handled well enough by -Wmissing-field-initializers, which does not warn about your original code.
I get the same warning in Xcode 6.1.1 (the current version as of March 9, 2015). When I add the extra braces around each subobject I get an error. When I add an extra set of braces around the entire initialization list then the warning goes away. According to the standard specification 14882:2011 23.3.2.1 [array.overview] subsection 2 explicitly states
array<T, N> a = { initializer-list };
where initializer-list is a comma-separated list of up to N elements
whose types are convertible to T
result of code in Xcode 6.1.1 (below)
array<int, 2> key1 = {1, 2}; // warning: suggest braces around initialization of subobject
array<int, 2> key2 = { {1}, {2} }; // error: no viable overload =
array<int, 2> key3 = array<int, 2> { {1}, {2} }; // error: excess elements in struct initializer
array<int, 2> key4 = { {1, 2} }; // no warning and no error
When we look at 14882:2011 8.5 [dcl.init] subsection 1 we see that an 'initializer-list' can optionally contain an 'initializer-clause', which itself can be a 'braced-init-list'. So either way should be correct. Though based on the spec I personally think single braces shouldn't output a compiler warning for a std::array initializer-list, and double braces is overkill.
Clang 6.0 suppresses the warning about missing braces. The svn log says:
Suppress -Wmissing-braces warning when aggregate-initializing a struct with a single field that is itself an aggregate. In C++, such initialization of std::array types is guaranteed to work by the standard, is completely idiomatic, and the "suggested" alternative from
Clang was technically invalid.
So I would omit the braces and disable -Wmissing-braces for Clang prior to 6.0 if it needs to be supported.
When ignoring the Clang warning with -Wno-missing-braces, I would recommend to enable -Wmissing-field-initializers (or use -Wextra, which also includes it). Otherwise, you miss a useful warning like in this example:
#include <cstdio>
struct A
{
int i;
int arr[2];
int j;
};
void print(const A& a)
{
printf("i=%d, arr={%d,%d}, j=%d\n", a.i, a.arr[0], a.arr[1], a.j);
}
int main() {
A a = {1, 2, 3}; // this is the critical line
print(a); // output: i=1, arr={2,3}, j=0
A b = {1, {2}, 3};
print(b); // output: i=1, arr={2,0}, j=3
A c = {1, {2,0}, 3};
print(c); // output: i=1, arr={2,0}, j=3
return 0;
}
$ clang++ -Wall example.cpp
example.cpp:16:13: warning: suggest braces around initialization of
subobject [-Wmissing-braces]
A a = {1, 2, 3};
^~~~
{ }
1 warning generated.
$ clang++ -Wall -Wno-missing-braces example.cpp
(no warnings)
$ clang++ -Wall -Wno-missing-braces -Wmissing-field-initializers example.cpp
example.cpp:16:17: warning: missing field 'j' initializer
[-Wmissing-field-initializers]
A a = {1, 2, 3};
^
1 warning generated.
$ clang++ --version
clang version 3.8.1 (tags/RELEASE_381/final)
For comparison, this is what GCC does:
$ g++ -Wall -Wextra example.cpp
(no warning)
$ g++ -Wall -Wmissing-field-initializers example.cpp
example.cpp: In function ‘int main()’
example.cpp:16:17: warning: missing initializer for member ‘A::j’ [-Wmissing-field-initializers]
A a = {1, 2, 3};
^
In summary:
For Clang, I would recommend -Wno-missing-braces -Wmissing-field-initializers to silence the warning without loosing other useful warnings
GCC does not complain in the original std::array<int, 1> x = { 0 }; example, so there is no need to disable any warnings. However, I would recommend to enable -Wmissing-field-initializers (or use -Wextra), as it is not enabled by -Wall.