Class Vectors constructors expects a const Vectors&, but the iterator in the loop is declared Vectors::iterator, and my compiler complains. However, if I change it to Vectors::const_iterator, the complaint vanishes.
These are lines 1171--1175 of the constructor at hand of ControlAlgorithm.h:
Vectors(const Vectors<T>& that)
{
for (typename Vectors<T>::iterator iter = that.begin(); iter != that.end(); ++iter)
vectors.push_back(*iter);
}
I believe this also affects Vectors::operator=, though I am not sure because SWIG (which I am using to build a Python interface to this library) does not expose any operator= method to Python (because Python does not have any equivalent semantic). These are lines 1177--1186 defining such method:
Vectors_<T>& operator=(const Vectors_<T>& that)
{
if (this != that)
{
vectors.clear();
for (typename Vectors_<T>::iterator iter = that.begin(); iter != that.end(); ++iter)
vectors.push_back(*iter);
}
return *this;
}
Similarly, the same problem affects Ranges constructor and possible Ranges::operator=. Following are lines 328--343 of Mathema.h:
Ranges_(const Ranges_<T>& that)
{
for (typename Ranges_<T>::const_iterator iter = that.begin(); iter != that.end(); ++iter)
ranges.push_back(*iter);
}
Ranges_<T>& operator=(const Ranges_<T>& that)
{
if (this != that)
{
ranges.clear();
for (typename Ranges_<T>::iterator iter = that.begin(); iter != that.end(); ++iter)
ranges.push_back(*iter);
}
return *this;
}
It is possible that other operator= functions are affected by this problem, but my compiler is not complaining because SWIG is not exposing any operator= for the same reason as above.
Class Vectors constructors expects a const Vectors&, but the iterator in the loop is declared Vectors::iterator, and my compiler complains. However, if I change it to Vectors::const_iterator, the complaint vanishes.
These are lines 1171--1175 of the constructor at hand of ControlAlgorithm.h:
I believe this also affects Vectors::operator=, though I am not sure because SWIG (which I am using to build a Python interface to this library) does not expose any operator= method to Python (because Python does not have any equivalent semantic). These are lines 1177--1186 defining such method:
Similarly, the same problem affects Ranges constructor and possible Ranges::operator=. Following are lines 328--343 of Mathema.h:
It is possible that other operator= functions are affected by this problem, but my compiler is not complaining because SWIG is not exposing any operator= for the same reason as above.