I want to initialize a std::vector to have a specific length.
in the .hpp file I use
#include <vector>
class foo
{
foo(){};
~foo(){};
std::vector<double> pressure (4,0); //vector 4 elements = 0
void readPressure()
{
pressure.at(0) = 1;
pressure.at(1) = 2;
pressure.at(2) = 3;
pressure.at(3) = 4;
}
...
};
But I get the error:
error: expected identifier before numeric constant
std::vector<double> pressure(4,0);
^
error: expected ',' or '...' before numeric constant
I read that this might be due to not using C++11 but I specify in my makefile
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_CXX_FLAGS_RELEASE "-O3")
I am compiling on a raspberry 4, g++ version is 8.3
***edited the .hpp file
Default member initializer (since C++11) only supports brace and equal-sign initializer. E.g.
class foo
{
std::vector<double> pressure = std::vector<double>(4,0); //vector 4 elements = 0
...
};
BTW: We can't use braced-initializer as std::vector<double> pressure{4,0};, because it would initialize the vector containing 2 elements with value 4 and 0, which is not what you want.
Related
Good day. Building program without using cmake
''' g++ -lpthread src/how2thread.cpp src/main.cpp -ggdb3 -std=c++17 -Wextra '''
produces no errors.
Although, using
'''
cmake . && make
'''
generates following build errors:
[ 25%] Building CXX object CMakeFiles/how2thread_lib.dir/src/how2thread.cpp.obj
D:/Scizzors/Dsktp/cpp/how2thread/src/how2thread.cpp: In member function 'how2thread::Request how2thread::Scheduler::get_request()':
D:/Scizzors/Dsktp/cpp/how2thread/src/how2thread.cpp:103:67: error: use of deleted function 'std::lock_guard<_Mutex>::lock_guard(const std::lock_guard<_Mutex>&) [with _Mutex = std::mutex]'
103 | auto m_lock = std::lock_guard<std::mutex>(data_arr_protect);
| ^
In file included from C:/msys64/mingw64/include/c++/12.1.0/mutex:43,
from D:/Scizzors/Dsktp/cpp/how2thread/src/how2thread.hpp:8,
from D:/Scizzors/Dsktp/cpp/how2thread/src/how2thread.cpp:4:
C:/msys64/mingw64/include/c++/12.1.0/bits/std_mutex.h:237:7: note: declared here
237 | lock_guard(const lock_guard&) = delete;
I specify in my header file, that data_arr_protect is std::mutex object
class Scheduler
{
// class for schedule slicers, processors and collecting data
public:
Scheduler(const std::vector<char>& data,
const std::string& mask); // construct and parse data
Request get_request(); // used to get another batch
void write_request(Request&&);
void write_finding(Finding&& find);
using Find_it = decltype(std::declval<std::vector<Finding>&>().cbegin());
Find_it cbegin();
Find_it cend();
const auto& get_slicing_status(){return is_slicing;} //
std::string mask;
#ifndef DEBUG_V
private:
#endif
const size_t slicer_num;
std::queue<Request> data_arr; // consider switching to deQ
std::mutex data_arr_protect;//for mt rw to vec // might be switching to semaphores
std::queue<Actor_processor> proc_instances_q;
std::queue<Actor_slicer> slicer_instances_q;
std::vector<Finding> result_arr;
std::mutex result_protect;//for mt write to vec
protected:
friend class Actor_slicer; // we need access from slicers to mutexes as they're pretty lowlvl
std::vector<std::mutex> char_segments_protect;
std::vector<size_t> finish_line_no;
std::atomic<size_t> is_slicing; // for break cond
};
My cmake file looks next
cmake_minimum_required(VERSION 3.10.0)
project(how2thread
VERSION 0.0.1
DESCRIPTION "simple mt parser app"
LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(THREADS_PREFER_PTHREAD_FLAG ON)
find_package(Threads REQUIRED)
file(GLOB_RECURSE src_files src/*.cpp)
add_library(how2thread_lib src/how2thread.cpp src/how2thread.hpp)
add_executable(how2thread src/main.cpp)
target_link_libraries(how2thread PRIVATE how2thread_lib)
target_link_libraries(how2thread PRIVATE Threads::Threads)
What can cause compiler's misinterpretation and how i must fix it?
I tried different linking options, as building my how2thread.cpp file with main.cpp file, although it didn't help. And I do not get errors about undefined class or something, so, I guess, header file being included by .cpp one
Nothing is being misinterpreted. The issue is the following line: (Which appears only in the error message, not the code you show. Please always provide a minimal reproducible example!)
auto m_lock = std::lock_guard<std::mutex>(data_arr_protect);
This is copy-initialization of m_lock from the initializer expression which before C++17 required the type to be move-constructible, which std::lock_guard is not. Direct-initialization with auto (e.g. auto m_lock(std::lock_guard<std::mutex>(data_arr_protect));) would also not work for the same reason.
To compile this line you need to use C++17 or later, but you are asking cmake to set C++14 with
set(CMAKE_CXX_STANDARD 14)
So change the 14 to 17.
Or if you require compatibility with C++14, you will have to avoid the auto initialization idiom for non-movable types:
std::lock_guard<std::mutex> m_lock(data_arr_protect);
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.
I am using the MSVC2013 64bit compiler under Windows 10.
According to:
std::cout << arma::arma_version::as_string() << std::endl;
I have version 6.100.1 (Midnight Blue) of the Armadillio library.
I have C++11 enabled, for example
auto il = { 10, 20, 30 };
for(auto ele : il)
cout<<ele<<endl;
is working. Also the library is correctly added, as the following code runs:
vec v;
v<<10<<20<<30;
cout<<v;
But trying to use initializer lists for Armadillio fails.
vec v = { 1.0, 2.0, 3.0 };
causes the compile error:
error: C2440: 'initializing' : cannot convert from 'initializer-list' to 'arma::Col'
No constructor could take the source type, or constructor overload resolution was ambiguous
In the folder armadillo-6.100.1\include\armadillo_bits
there is a config file called config.hpp.
There you find a paragraph saying:
#if !defined(ARMA_USE_CXX11)
// #define ARMA_USE_CXX11
//// Uncomment the above line to forcefully enable use of C++11 features (eg. initialiser lists).
//// Note that ARMA_USE_CXX11 is automatically enabled when a C++11 compiler is detected.
#endif
So it looks like the MSVC2013 64bit is not detected as a C++11 compiler from Armadillio. So uncommenting the line
// #define ARMA_USE_CXX11
Solved my problem. Now this is working like charm:
vec v = { 1.0, 2.0, 3.0 };
cout<<v;
The documentation says that vec is a typedef for Col<double:
For convenience the following typedefs have been defined:
vec = colvec = Col< double >
If we look on the Col constructors, we will find the following constructor that accepts an initializer list:
#if defined(ARMA_USE_CXX11)
template<typename eT>
inline
Col<eT>::Col(const std::initializer_list<eT>& list)
{
<...>
}
So my guess would be that ARMA_USE_CXX11 is not defined, and thus this constructor is not accessible.
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.
The following 3 code blocks are the main.cpp, static_class_array.cpp, and static_class_array.h respectively. I'm getting the following error:
static_class_array.cpp||In constructor 'static_array_class::static_array_class()':|
static_class_array.cpp|5|error: cannot convert '<brace-enclosed initializer list>' to 'int' in assignment|
||=== Build finished: 1 errors, 0 warnings ===|
#include "static_class_array.h"
int main()
{
static_array_class* array_class;
array_class = new static_array_class();
delete array_class;
return 0;
}
#include "static_class_array.h"
static_array_class::static_array_class()
{
static_array_class::array[3] = {0,1,2};
}
static_array_class::~static_array_class(){}
#ifndef STATIC_CLASS_ARRAY_H
#define STATIC_CLASS_ARRAY_H
class static_array_class
{
private:
static int array[3];
public:
static_array_class();
~static_array_class();
};
#endif
I think that what you want in the implementation file is:
static_array_class::static_array_class()
{
}
static_array_class::~static_array_class(){}
int static_array_class::array[3] = {0,1,2};
Explanation of error message
"cannot convert 'brace-enclosed initializer list' to 'int' in
assignment"
in submitted code.
This is because the code:
static_array_class::array[3] = {0,1,2};
is interpreted as meaning that {0,1,2} should be assigned to element 3 in the array. Element 3 is of type int, (and incidentally not allocated being the fourth element), so this is like:
int i = 0;
i = {0,1,2};
Hence the error message.
They are not the same type;
Your class is a class which includes a an array -- they other is just an array.
With a static definition of a class member you need to declare the actual instance outside the class, just like with any other static,
int static_array_class::array[3] = {0,1,2}; // note this line is outside the constructor
static_array_class::static_array_class()
{
}
static_array_class::~static_array_class(){}