iterators as members

[jeroen.haegebaert]

I'm wondering whether the following code construct is allowed according
to the C++ standard.

The following code fragment illustrates the situation:

#include <vector>
using namespace std;

// Class A has a member v of type std::vector<int>
class A
{
public :
std::vector<int> v;
};


// class B stores an iterator (i) to such a vector:
class B
{
public :
std::vector<int>::iterator i;
};


int main()
{
A *a = new A();

B b;
b.i = a->v.begin();

// make sure a is deleted before b goes out of scope
delete a;
}

We only found this to be a problem when compiling with the Microsoft
compiler using cl /EHsc /MTd /D_HAS_ITERATOR_DEBUGGING#0. In that case,
it results in a crash inside the destructor of B::i.

Now my question: does the standard allow storing iterators like that?

thx,
jeroen

 

[mlimber]

I'm wondering whether the following code construct is allowed according
to the C++ standard.

The following code fragment illustrates the situation:

#include <vector>
using namespace std;

// Class A has a member v of type std::vector<int>
class A
{
public :
std::vector<int> v;
};


// class B stores an iterator (i) to such a vector:
class B
{
public :
std::vector<int>::iterator i;
};


int main()
{
A *a = new A();

B b;
b.i = a->v.begin();

// make sure a is deleted before b goes out of scope
delete a;
}

We only found this to be a problem when compiling with the Microsoft
compiler using cl /EHsc /MTd /D_HAS_ITERATOR_DEBUGGING#0. In that case,
it results in a crash inside the destructor of B::i.

Now my question: does the standard allow storing iterators like that?

This code is legal albeit dangerous. B::i is certainly invalidated by
the destruction of A. If you have dereferenced it after the destruction
of A (e.g. in the destructor of B), you have undefined behavior.
Destroying an invalidated iterator should not cause a problem.

Does this exact code reproduce the problem for you, and if so, on which
version of the compiler?

Cheers! --M

 

[jeroen.haegebaert]

mlimber schreef:

This code is legal albeit dangerous. B::i is certainly invalidated by
the destruction of A. If you have dereferenced it after the destruction
of A (e.g. in the destructor of B), you have undefined behavior.
Destroying an invalidated iterator should not cause a problem.

Does this exact code reproduce the problem for you, and if so, on which
version of the compiler?

It's that exact code construct that reproduces the problem, but I
forgot to mention: we detected this problem after installing Service
Pack 1 for Visual Studio 2005 ...

compiler version:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
for 80x86



jeroen

 

[mlimber]

mlimber schreef:


It's that exact code construct that reproduces the problem, but I
forgot to mention: we detected this problem after installing Service
Pack 1 for Visual Studio 2005 ...

compiler version:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
for 80x86

I compiled it with those exact options with v. 14.00.50727.42, and it
works fine (well, it least it doesn't give any message about a crash).
You'll probably have more luck asking in a Microsoft-specific group
since this doesn't appear to be a standard C++ question any more.

Cheers! --M

 

[jeroen.haegebaert]

mlimber schreef:

I compiled it with those exact options with v. 14.00.50727.42, and it
works fine (well, it least it doesn't give any message about a crash).
You'll probably have more luck asking in a Microsoft-specific group
since this doesn't appear to be a standard C++ question any more.

Indeed. I just first wanted to get some confirmation about whether or
not the code
construct really was legal C++.

thx,
jeroen