SparseMat::clear() never called (Bug #1587)
Description
There seems to be a problem with the clear()
method and all methods that call clear()
: I noticed that the iterator on a just cleared sparse mat is not empty. Looking into the debugger revealed that the hash table is not cleared. Trying to trace into the clear()
method revealed that the actual method is never called. I observed this with 2.3.1 on a Mac OS X 10.7.2 withh gcc 4.2.
The following code works if and only if the commented line remains commented out:
1int main (int argc, const char * argv[])
2{
3 int sizesr2 = {10, 20};
4 cv::SparseMat_<float> v(2,sizes);
5 v.ref(2,4) = 7.0f;
6 //v.clear();
7 cv::SparseMatIterator_<float> i = v.begin();
8 cv::SparseMatIterator_<float> ie = v.end();
9 for (; i != ie; ++i)
10 std::cout << *i;
11 std::cout << '\n';
12 return 0;
13}
Commenting out v.clear()
, I would expect the hash table to be cleared and the iterator to be on an empty set, i.e., never executed. This is not the case and any iterator on SparseMat
needs to be embraced by
1if (my_matrix.nzcount()) {
2...
3}
Associated revisions
fixed a few compile problems in SparseMat code; fixed iteration over an empty sparse matrix (ticket #1587)
Merge pull request #1587 from alalek:opencl_khronos_headers
History
Updated by Alexander Shishkov about 13 years ago
- Description changed from There seems to be a problem with the clear() method and all methods that call... to There seems to be a problem with the clear() method and all methods that call... More
Updated by Andrey Kamaev about 13 years ago
- Description changed from There seems to be a problem with the clear() method and all methods that call... to There seems to be a problem with the @clear()@ method and all methods that ca... More
Updated by Alexander Shishkov almost 13 years ago
- Target version deleted ()
Updated by Alexander Shishkov almost 13 years ago
- Status set to Open
Updated by Alexander Shishkov almost 13 years ago
- Assignee deleted (
Vadim Pisarevsky)
Updated by Vadim Pisarevsky almost 13 years ago
thanks! the problem has been fixed in SVN trunk, r7663
- Status changed from Open to Done
- Assignee set to Vadim Pisarevsky
Updated by Alexander Shishkov almost 13 years ago
- Target version set to 2.4.0