By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,925 Members | 1,129 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,925 IT Pros & Developers. It's quick & easy.

iterators as members

P: n/a
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<intv;
};
// 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

Dec 28 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
jeroen.haegeba...@gmail.com wrote:
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<intv;
};
// 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

Dec 28 '06 #2

P: n/a

mlimber schreef:
jeroen.haegeba...@gmail.com wrote:
I'm wondering whether the following code construct is allowed according
to the C++ standard.

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

Dec 28 '06 #3

P: n/a
je***************@gmail.com wrote:
mlimber schreef:
jeroen.haegeba...@gmail.com wrote:
I'm wondering whether the following code construct is allowed according
to the C++ standard.
>
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
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

Dec 28 '06 #4

P: n/a

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

Dec 28 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.