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

Is there something wrong with this OO/STL code?

P: n/a
Hi,

the following is a boiled-down version of a problem
we're plagued with. It's still a rather complicated
class hierarchy, but if we remove one more item, the
problem disappears.
This is the class hierarchy ('v' indicates virtual
inheritance):

A
|
v
|
B
| \
v v
| \
C B_
| \ \
v v \
| \ \
D C_ |
| \ \ |
v v | |
| \ | |
E \|/
\ D_
\ |
\ |
\ |
\|
E_

In code:

#include <map>

struct A {virtual ~A() {}; bool b1;};
struct B : public virtual A {bool b2[21];};
struct C : public virtual B {};
struct D : public virtual C {};
struct E : public virtual D {};

struct B_ : public virtual B {};
struct C_ : public virtual C {};
struct D_ : public virtual D
, public C_
, public B_{};
struct E_ : public D_
, public E {};

int main()
{
typedef std::map< unsigned long, E_* > M;
M m;
E_* p = new E_();
m.insert( M::value_type( 1, p ) );
for( M::iterator it = m.begin(); it != m.end(); ++it ) {
delete (*it).second; // *1
(*it).second = NULL;
}
m.clear(); // *2
}

The problem is in the line marked with *2: With
CodeWarrior 9.4 on MacOS X, it crashs with an
access fault. When we debug into the call to
'clear()' it seems as if (due to the delete in
line *1), the map somehow is messed up.
We could reproduce the crash with CW9.3, which
also usees MSL as their std lib. We could not
reproduce it with CW8 (MSL), GCC3.3 (either
libstd or Dinkumware) and VC7.1 (Dinkumware).
I have verified that Comeau (Online) compiles
the code without any warnings or errors.

Now here's my question: Is there anything wrong
with the code or is this a bug in the MSL?

TIA,

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett

Jul 23 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Hendrik Schober wrote:
the following is a boiled-down version of a problem
we're plagued with. It's still a rather complicated
class hierarchy, but if we remove one more item, the
problem disappears.
This is the class hierarchy ('v' indicates virtual
inheritance):

A
|
v
|
B
| \
v v
| \
C B_
| \ \
v v \
| \ \
D C_ |
| \ \ |
v v | |
| \ | |
E \|/
\ D_
\ |
\ |
\ |
\|
E_

In code:

#include <map>

struct A {virtual ~A() {}; bool b1;};
struct B : public virtual A {bool b2[21];};
struct C : public virtual B {};
struct D : public virtual C {};
struct E : public virtual D {};

struct B_ : public virtual B {};
struct C_ : public virtual C {};
struct D_ : public virtual D
, public C_
, public B_{};
struct E_ : public D_
, public E {};

int main()
{
typedef std::map< unsigned long, E_* > M;
M m;
E_* p = new E_();
m.insert( M::value_type( 1, p ) );
for( M::iterator it = m.begin(); it != m.end(); ++it ) {
delete (*it).second; // *1
(*it).second = NULL;
}
m.clear(); // *2
}

The problem is in the line marked with *2: With
CodeWarrior 9.4 on MacOS X, it crashs with an
access fault. When we debug into the call to
'clear()' it seems as if (due to the delete in
line *1), the map somehow is messed up.
We could reproduce the crash with CW9.3, which
also usees MSL as their std lib. We could not
reproduce it with CW8 (MSL), GCC3.3 (either
libstd or Dinkumware) and VC7.1 (Dinkumware).
I have verified that Comeau (Online) compiles
the code without any warnings or errors.

Now here's my question: Is there anything wrong
with the code or is this a bug in the MSL?


There is nothing wrong with the code.

Have you tried to debug the library code to see where and when
the map gets "messed up"? That's what I'd do if I were to make
sure that 'MSL' is the culprit.

V
Jul 23 '05 #2

P: n/a
Victor Bazarov <v.********@comAcast.net> wrote:
[...]
There is nothing wrong with the code.

Have you tried to debug the library code to see where and when
the map gets "messed up"? [...]
Yes. -- And got lost in some proprietary
tree implementation. :) Honestly, if the
code is correct, I'll report thisas a bug
and let MW do the debugging.
V

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
Jul 23 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.