A colleague has provided me with a package of c++ code based on some Celestrak satellite code https://celestrak.org/software/vallado/cpp.zip.
In several places the code, i.e coordfk5.cpp declares vectors of vectors like
std::vector< std::vector<double> > prec, nut(3,3), st, stdot, pm, pmp
The nut(3,3) and similar declarations won't compile on my system yet does for the colleague on his and presumably others who have downloaded the original package.
stl_vector.h: In instantiation of 'void std::vector<_Tp, _Alloc>::_M_initialize_dispatch(_Integer, _Integer, std::__true_type) [with _Integer = int; _Tp = std::vector; _Alloc = std::allocatorstd::vector<double >]':
stl_vector.h:404:55: required from 'std::vector<_Tp, _Alloc>::vector(_InputIterator, _InputIterator, const allocator_type&) [with _InputIterator = int; _Tp = std::vector; _Alloc = std::allocatorstd::vector<double >; std::vector<_Tp, _Alloc>::allocator_type = std::allocatorstd::vector<double >]'
stl_vector.h:1166:59: error: no matching function for call to 'std::vectorstd::vector<double >::_M_fill_initialize(std::vectorstd::vector<double >::size_type, int&)'
_M_fill_initialize(static_cast<size_type>(__n), __value);
I'm on gcc version 4.8.1, the colleague is on 4.6.3. I've tried adding -std=c++98 etc options to no avail.
I can get the code to compile by changing to eg
nut(3,std::vector<double>(3))
but not sure if this is right as the code then seg faults.
So two questions,
Is it possible with some options/switches to compile the code as is?
If not any idea how these vectors should be declared and set-up?
The nut(3,3) attempts to use 3 as initializer for the inner std::vector<int>.
However, std::vector has an explicit constructor which is why it doesn't compile. As you have found, explicit constructors have to have the type explicitly written, with nut(3, std::vector<int>(3)).
Some older compilers came with a vector that didn't mark the constructor as explicit which would explain your colleagues' observations.
Related
Earlier today, gcc gave me a warning that I belive to be erroneous and now I am very unsure if it is an actual compiler bug(usually highly unlikely) or a bug in my code(usually highly likely). I managed to reduce it down to the following code:
#include <algorithm>
#include <array>
#include <iostream>
int main()
{
std::array<int,8> test{};
int valid = 0;
for(int i=0;i<8;++i)
{
if(i==0)
test[valid++] = 0;
}
// if(valid<8)
std::sort(test.begin(),test.begin()+valid);
}
Here it is on Compiler explorer
When compiled with optimization level -O2 or higher with gcc 12.1 or trunk, this warning about an out-of-bounds access is emitted:
In file included from /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/algorithm:61,
from <source>:1:
In function 'void std::__final_insertion_sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]',
inlined from 'void std::__final_insertion_sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]' at /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_algo.h:1844:5,
inlined from 'void std::__sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]' at /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_algo.h:1940:31,
inlined from 'void std::__sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]' at /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_algo.h:1932:5,
inlined from 'void std::sort(_RAIter, _RAIter) [with _RAIter = int*]' at /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_algo.h:4820:18,
inlined from 'int main()' at <source>:16:15:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_algo.h:1849:32: error: array subscript 16 is outside array bounds of 'std::array<int, 8> [1]' [-Werror=array-bounds]
1849 | std::__insertion_sort(__first, __first + int(_S_threshold), __comp);
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>: In function 'int main()':
<source>:7:27: note: at offset 64 into object 'test' of size 32
7 | std::array<int,8> test{};
I believe that to be mistaken. According to my limited understanding, valid is only incremented once and will always be 1.
Even if the condition were replaced with some unpredictable function call, in the worst case it would be true every time, yielding valid==8 at the end of the loop, which should still be alright?
Additionally, I have thus far made the following observations:
The warning is not produced at lower optimization levels, on gcc <=11 or on clang.
Interestingly, the warning is also not produce with array sizes >8 or <6, only for sizes 6,7, and 8.
When I remove the condition inside the loop body(the "if(i==0)", to increment every time and always yield valid==8), the warning disappears.
When I add the condition before the sort call(and thereby provide the compiler with an additional hint about the limits of valid), the warning disappears.
Especially the latter two make me believe I might have managed to confuse gcc's analysis somehow, but also make me question if I am overlooking something obvious or managed to introduce some subtle undefined behaviour in my code.
Am I misunderstanding something in my sleep deprived state or did I encounter a genuine, mostly harmless, compiler bug?
It is indeed a compiler bug, as can be seen in this bugzilla report, which contains almost identical code to the one in my question.
Thanks to Marc Glisse for providing this link to a lot of similar bugs and thereby helping me track down the relevant one.
I have a bit of code (which I didn't write, but am trying to compile) -- iostream_combo.cc--, and doing so gives me the following error:
./moses/moses/comboreduct/combo/iostream_combo.cc: In function ‘std::__cxx11::string opencog::combo::l2ph(const string&, const std::vector<std::__cxx11::basic_string<char> >&)’:
./moses/moses/comboreduct/combo/iostream_combo.cc:543:64: error: call of overloaded ‘distance(std::vector<std::__cxx11::basic_string<char> >::const_iterator, __gnu_cxx::__normal_iterator<const std::__cxx11::basic_string<char>*, std::vector<std::__cxx11::basic_string<char> > >&)’ is ambiguous
arity_t idx = distance(labels.begin(), found_it) + 1;
^ In file included from /usr/include/c++/8/bits/stl_algobase.h:66,
from /usr/include/c++/8/bits/char_traits.h:39,
from /usr/include/c++/8/ios:40,
from /usr/include/c++/8/ostream:38,
from /usr/include/c++/8/iostream:39,
from ./moses/moses/comboreduct/combo/iostream_combo.h:28,
from ./moses/moses/comboreduct/combo/iostream_combo.cc:24:
/usr/include/c++/8/bits/stl_iterator_base_funcs.h:138:5: note: candidate: ‘typename std::iterator_traits<_Iterator>::difference_type std::distance(_InputIterator, _InputIterator) [with _InputIterator = __gnu_cxx::__normal_iterator<const std::__cxx11::basic_string<char>*, std::vector<std::__cxx11::basic_string<char> > >; typename std::iterator_traits<_Iterator>::difference_type = long int]’
distance(_InputIterator __first, _InputIterator __last)
^~~~~~~~ In file included from /usr/local/include/boost/range/distance.hpp:18,
from /usr/local/include/boost/range/functions.hpp:21,
from /usr/local/include/boost/range/iterator_range_core.hpp:38,
from /usr/local/include/boost/lexical_cast.hpp:30,
from ./moses/moses/comboreduct/combo/iostream_combo.h:30,
from ./moses/moses/comboreduct/combo/iostream_combo.cc:24:
/usr/local/include/boost/iterator/distance.hpp:49:9: note: candidate: ‘constexpr typename boost::iterators::iterator_difference<Iterator>::type boost::iterators::distance_adl_barrier::distance(SinglePassIterator, SinglePassIterator) [with SinglePassIterator = __gnu_cxx::__normal_iterator<const std::__cxx11::basic_string<char>*, std::vector<std::__cxx11::basic_string<char> > >; typename boost::iterators::iterator_difference<Iterator>::type = long int]’
distance(SinglePassIterator first, SinglePassIterator last)
^~~~~~~~
I'm using Ubuntu 16.04 x64, Boost 1.68 and gcc 8.2. So, the steps to reproduce the problem would be as follows:
On Ubuntu 16.04
install gcc-8
Use it to build boost 1.68 from source
Git clone the moses repository sand follow the instructions from there: basically 1) git clone and build cogutil; 2) try to make moses:
cd build, cmake .., make.
I understand C++ enough (I think) that I can see that the call to std::distance is overloaded. What I don't see is the way to disambiguate it, although I guess it must include some re-writing of found_it or some explicit castings instead of auto.
The calls are like:
arity_t idx = distance(labels.begin(), found_it) + 1;
This means that distance is found via ADL and hence all associated namespaces are considered. This might prove problematic if e.g. there are two namespaces providing an equally applicable overload for distance:
Live On Coliru
#include <iterator>
#include <vector>
namespace OyVeh {
struct X { };
template <typename It>
size_t distance(It, It) { return 42; } // just to throw in a wrench
}
int main() {
std::vector<OyVeh::X> v{3};
auto f = v.begin();
auto l = v.end();
// now f and l have both `::std` and `::OyVeh` as associated namespaces. The following is ambiguous:
return distance(f, l);
}
There are roughly 2 ways to fix it:
remove the ambigious distance declaration from the associated namespace (this might not be possible if e.g. the ones competing are std::distance and boost::distance)
edit the calls to remove the reliance on ADL (e.g. qualify them like std::distance(...) or parenthesize them (distance)(...))
Showing the workarounds:
Live On Coliru
{
using OyVeh::distance;
return (distance)(f, l); // parentheses suppress ADL
}
return std::distance(f, l); // also works, obviously
return OyVeh::distance(f, l); // but beware the meaning might change
I have a simple c++ std::vector and inside it, i am storing threads as shown below. Can you please explain why the line with comment "does not compile" shows error during compilation? And why the line with comment "compiles" work?
#include<thread>
#include<vector>
using namespace std;
void abc() {}
int main()
{
vector<thread> workers;
workers.push_back(thread(abc)); // compiles
thread t(abc);
workers.push_back(t); // does not compile
return 0;
}
UPDATE: i am using g++ 4.4.6 on linux. Below is the error
[jim#cola c++]$ g++ -std=c++0x -pthread -g -Wall t.cpp -o t
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/x86_64-redhat-linux/bits/c++allocator.h:34,
from /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/bits/allocator.h:48,
from /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/string:43,
from /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/bits/locale_classes.h:42,
from /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/bits/ios_base.h:43,
from /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/ios:43,
from /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/ostream:40,
from /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/iostream:40,
from t.cpp:1:
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/thread: In member function ‘void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, const _Tp&) [with _Tp = std::thread]’:
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/bits/stl_vector.h:737: instantiated from ‘void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = std::thread, _Alloc = std::allocator<std::thread>]’
t.cpp:29: instantiated from here
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/thread:122: error: deleted function ‘std::thread::thread(const std::thread&)’
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/ext/new_allocator.h:105: error: used here
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/vector:69,
from t.cpp:4:
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/thread: In member function ‘void std::vector<_Tp, _Alloc>::_M_insert_aux(__gnu_cxx::__normal_iterator<typename std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::pointer, std::vector<_Tp, _Alloc> >, _Args&& ...) [with _Args = const std::thread&, _Tp = std::thread, _Alloc = std::allocator<std::thread>]’:
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/bits/stl_vector.h:741: instantiated from ‘void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = std::thread, _Alloc = std::allocator<std::thread>]’
t.cpp:29: instantiated from here
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/thread:122: error: deleted function ‘std::thread::thread(const std::thread&)’
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/bits/vector.tcc:314: error: used here
You're getting the error because std::thread is noncopyable, and you're trying to insert a copy of t into the vector.
The only way you could make this work would be to do:
workers.push_back(std::move(t));
However, this would mean that after you do that, t no longer represents a thread (the thread it represented was moved into the vector).
The reason is that std::thread has a move constructor, but doesn't have a copy constructor.
Here is a cleaner and faster solution that requires neither copying nor moving:
workers.emplace_back(abc);
Because std::thread is not copyable, you could move it to vector though:
thread t(abc);
workers.push_back(std::move(t));
Better solution is to store smart pointer in vector:
std::vector<std::shared_ptr<std::thread>> workers;
Because when work with lambda, there is no way to capture a move only type, a workaround is to store a move-only type in std::shared_ptr<std::thread>.
i'm using gcc 4.6.2.
I'm trying to push_back in a vector shared_ptr's.
But gcc gives me everytime an error.
Here my codelines:
std::vector< std::tr1::shared_ptr<Process> > procs;
std::string line;
while (getline(file, line) && line.find(JobMask) != std::string::npos)
{
std::string procName = line.substr(line.find(JobMask) + JobMask.size());
std::vector<Instruction> procInstructions = extractProgram(file);
std::queue<int> procInputs = extractInputs(file);
if (!procInstructions.empty())
procs.push_back(std::make_shared<Process>(Process(procName, procInputs, procInstructions))); //line 51
}
return procs;
The Error my gcc is giving is:
Process.cpp: In static member function 'static std::vector<std::tr1::shared_ptr<RMMIX::Process> > RMMIX::Process::createProcesses(const string&)':
Process.cpp:51:95: error: no matching function for call to 'std::vector<std::tr1::shared_ptr<RMMIX::Process> >::push_back(std::shared_ptr<RMMIX::Process>)'
Process.cpp:51:95: note: candidates are:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4/bits/stl_vector.h:826:7: note: void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = std::tr1::shared_ptr<RMMIX::Process>, _Alloc = std::allocator<std::tr1::shared_ptr<RMMIX::Process> >, std::vector<_Tp, _Alloc>::value_type = std::tr1::shared_ptr<RMMIX::Process>]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4/bits/stl_vector.h:826:7: note: no known conversion for argument 1 from 'std::shared_ptr<RMMIX::Process>' to 'const value_type& {aka const std::tr1::shared_ptr<RMMIX::Process>&}'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4/bits/stl_vector.h:839:7: note: void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&) [with _Tp = std::tr1::shared_ptr<RMMIX::Process>, _Alloc = std::allocator<std::tr1::shared_ptr<RMMIX::Process> >, std::vector<_Tp, _Alloc>::value_type = std::tr1::shared_ptr<RMMIX::Process>]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4/bits/stl_vector.h:839:7: note: no known conversion for argument 1 from 'std::shared_ptr<RMMIX::Process>' to 'std::vector<std::tr1::shared_ptr<RMMIX::Process> >::value_type&& {aka std::tr1::shared_ptr<RMMIX::Process>&&}'
In my eyes the error say's, that std::make_shared create a std::shared_ptr.
But in gcc shared_ptr is in the namespace std::tr1.
How could i fix it?
If I understand correctly, make_shared is new in C++11 and is in namespace std, but it is only available if you compile with -std=gnu++0x or similar. But if you do that, then shared_ptr is also in std.
The problem is that there is another version of shared_ptr in std::tr1, but in C++11 mode you should not use it: it should be considered deprecated.
Your solution is simply to remove every use of tr1 and use the full C++11 version of these classes.
C++ template error message can be a beast to read. But the answer is in the 2nd note.
no known conversion for argument 1 from 'std::shared_ptr<RMMIX::Process>' to 'const value_type& {aka const std::tr1::shared_ptr<RMMIX::Process>&}'
The problem is you're using std::make_shared (which creates a std::shared_ptr) and passing it into a vector of std::tr1::shared_ptr.
The simplest solution is drop the TR1. The stuff from the TR1 was some of first features implemented by compilers when adding C++11 support.
std::vector< std::shared_ptr<Process> > procs;
If you are unable to stop using std::tr1::shared_ptr. You'll have to forgo using make_shared as it was not part of the TR1.
When programming in c++ STL, or intensively using 'templatization', and some compiling error happens, often the error report is really long, and often too much not needed information is given.
I'm talking about gcc, i don't know if with other compilers is different, but some times even for just a typo, it takes a while to catch the error purging the
<ns::type<ns::type<ns::type, ns::type<...><ns::type<...> > > > >
I'm looking for some compiler flag, trick, workaround or methodology ( i currently copy past the error and put on two lines what i have and what compiler use to want and removing variables bookmarks... (kinda sad procedure for a not-so-uncommon ctrl+s non well performed)) that could make this task quicker or just helping me ( even only some IDE error syntax highlight... )
STLFilt: An STL Error Message Decryptor for C++ is a popular tool to filter these verbose error messages and turn them into something more legible.
From their website:
STLFilt was initially conceived as a teaching aid, to allow students
taking C++ and/or STL-specific workshops to make sense of typically
overbloated STL error messages. Today, however, even some C++ experts
have adopted STLFilt for use in everyday development. The results may
not always be perfect, but most of the time the information lost
during Decryption is not critical to the application being debugged.
The rest of the time, Decryption is easy enough to bypass.
The distribution for each platform (compiler/library set) is
self-contained and tuned to the idiosyncrasies of that platform. Each
Perl script performs basic regex substitutions for all the standard
(and extended, if present in the library) STL components, while
certain versions of the script go further with respect to message
ordering, line wrapping, library header error treatment, etc., as I
unilaterally deemed appropriate for that platform.
Here's a demo run that shows how it can be useful:
The source program:
#include <map>
#include <algorithm>
#include <cmath>
const int values[] = { 1,2,3,4,5 };
const int NVALS = sizeof values / sizeof (int);
int main()
{
using namespace std;
typedef map<int, double> valmap;
valmap m;
for (int i = 0; i < NVALS; i++)
m.insert(make_pair(values[i], pow(values[i], .5)));
valmap::iterator it = 100; // error
valmap::iterator it2(100); // error
m.insert(1,2); // error
return 0;
}
First, an unfiltered run using the MinGW gcc 3.2 compiler:
d:\src\cl\demo>c++2 rtmap.cpp
rtmap.cpp: In function `int main()':
rtmap.cpp:19: invalid conversion from `int' to `
std::_Rb_tree_node<std::pair<const int, double> >*'
rtmap.cpp:19: initializing argument 1 of `std::_Rb_tree_iterator<_Val, _Ref,
_Ptr>::_Rb_tree_iterator(std::_Rb_tree_node<_Val>*) [with _Val =
std::pair<const int, double>, _Ref = std::pair<const int, double>&, _Ptr =
std::pair<const int, double>*]'
rtmap.cpp:20: invalid conversion from `int' to `
std::_Rb_tree_node<std::pair<const int, double> >*'
rtmap.cpp:20: initializing argument 1 of `std::_Rb_tree_iterator<_Val, _Ref,
_Ptr>::_Rb_tree_iterator(std::_Rb_tree_node<_Val>*) [with _Val =
std::pair<const int, double>, _Ref = std::pair<const int, double>&, _Ptr =
std::pair<const int, double>*]'
E:/GCC3/include/c++/3.2/bits/stl_tree.h: In member function `void
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::insert_unique(_II,
_II) [with _InputIterator = int, _Key = int, _Val = std::pair<const int,
double>, _KeyOfValue = std::_Select1st<std::pair<const int, double> >,
_Compare = std::less<int>, _Alloc = std::allocator<std::pair<const int,
double> >]':
E:/GCC3/include/c++/3.2/bits/stl_map.h:272: instantiated from `void std::map<_
Key, _Tp, _Compare, _Alloc>::insert(_InputIterator, _InputIterator) [with _Input
Iterator = int, _Key = int, _Tp = double, _Compare = std::less<int>, _Alloc = st
d::allocator<std::pair<const int, double> >]'
rtmap.cpp:21: instantiated from here
E:/GCC3/include/c++/3.2/bits/stl_tree.h:1161: invalid type argument of `unary *
'
And a filtered run using the gcc-specific Proxy c++:
d:\src\cl\demo>c++ rtmap.cpp
*** {BD Software Proxy c++ for gcc v3.01} STL Message Decryption is ON! ***
rtmap.cpp: In function `int main()':
rtmap.cpp:19: invalid conversion from `int' to `iter'
rtmap.cpp:19: initializing argument 1 of `iter(iter)'
rtmap.cpp:20: invalid conversion from `int' to `iter'
rtmap.cpp:20: initializing argument 1 of `iter(iter)'
stl_tree.h: In member function `void map<int,double>::insert_unique(_II, _II)':
[STL Decryptor: Suppressed 1 more STL standard header message]
rtmap.cpp:21: instantiated from here
stl_tree.h:1161: invalid type argument of `unary *'
STL Decryptor reminder:
Use the /hdr:L option to see all suppressed standard lib headers
[Note: demo runs were performed in an 80-column console window with
STLFilt's intelligent line wrapping enabled, and with internal
switches set to produce messages as terse as possible. More detail is
available by tailoring the Decryptor's options.]
The only downside I can see is that it mislabels the C++ Standard Library. :(
Here's a relevant journal article by STLFilt's author.
A few people have made tools to perform this, as there's nothing inbuilt. Tonnes on Google, but the top result returns: http://www.bdsoft.com/tools/stlfilt.html
It should be compatible with visual studio and gcc.
edit::
I need to type less to actually get input in time :)