strange runtime error caused by enum

Hi,

I've been trying to debug a strange runtime error for the last 5
hours... I'm hoping someone might have an insight about it.

I have an application that creates a vector of MyDisplay objects
(MyDisplay is a custom class) and then uses them in various ways. The
application has been compiling and running fine. Then I added a
member variable of type enum to MyDisplay. So my class def now looks
like this:

class MyDisplay {
enum DisplayType {SMALL,MEDIUM,LARGE};
private:
DisplayType _displayType;
//....
// all the rest of the def is the same as before
}

I also added a default value in the constructor initialization list:

MyDisplay::MyDisplay() : _displayType(MEDIUM),
//rest of ctor def is same as before

Those are the ONLY two changes I've made so far. The app still
compiles without error. However, it now crashes when I run it. (If I
remove those changes, it will run perfectly). In particular, it
crashes when the vector of MyDisplay objects is being created. The
code creates 10 of them in total, and it crashes after the fourth one
has been constructed and added to the vector.

However, there does not seem to be a memory overload. The app never
uses more 3.5 MG memory, and each MyDisplay adds less than
200K.

PLEASE NOTE: I know that I'm leaving many possibly relevant details
out of my description, but it would be too much to ask anyone to look
at the whole app, as its fairly large. I'm just hoping that the
description above might ring some bells for someone.

Thanks for any thoughts,
cpp

cppaddict

* cppaddict:
>
> I've been trying to debug a strange runtime error for the last 5
> hours... I'm hoping someone might have an insight about it.
>
> I have an application that creates a vector of MyDisplay objects
> (MyDisplay is a custom class) and then uses them in various ways. The
> application has been compiling and running fine. Then I added a
> member variable of type enum to MyDisplay. So my class def now looks
> like this:
>
> class MyDisplay {
> enum DisplayType {SMALL,MEDIUM,LARGE};
> private:
> DisplayType _displayType;
> //....
> // all the rest of the def is the same as before
> }
>
> I also added a default value in the constructor initialization list:
>
> MyDisplay::MyDisplay() : _displayType(MEDIUM),
> //rest of ctor def is same as before
>
> Those are the ONLY two changes I've made so far. The app still
> compiles without error. However, it now crashes when I run it. (If I
> remove those changes, it will run perfectly). In particular, it
> crashes when the vector of MyDisplay objects is being created. The
> code creates 10 of them in total, and it crashes after the fourth one
> has been constructed and added to the vector.

Most probably the problem is with the definition of DisplayType.

Does it support copy construction? Does it support assignment? Those
are requirements of std::vector, if I recall correctly.

Btw., it's a good idea to always use all uppercase names for _macros_,
and never for anything else (it's a convention that avoids name clashes).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach

Alf,

Thanks for you reply. Could you clarify one point?

>Most probably the problem is with the definition of DisplayType.
>
>Does it support copy construction? Does it support assignment? Those
>are requirements of std::vector, if I recall correctly.
>

DisplayType is just an enum defined inside MyDisplay (which is the
type that the vector is made up of). I didn't think that you would
make a copy constructor of an enum type. Am I wrong here?

>Btw., it's a good idea to always use all uppercase names for _macros_,
>and never for anything else (it's a convention that avoids name clashes).

Thanks for the tip. Is there a standard way to indicate an constant?
That's what I was trying to do.

Thanks again,
cpp

cppaddict

* cppaddict:
> Alf,
>
> Thanks for you reply. Could you clarify one point?
>
> >Most probably the problem is with the definition of DisplayType.
> >
> >Does it support copy construction? Does it support assignment? Those
> >are requirements of std::vector, if I recall correctly.
> >
>
> DisplayType is just an enum defined inside MyDisplay (which is the
> type that the vector is made up of). I didn't think that you would
> make a copy constructor of an enum type. Am I wrong here?

Mea culpa. I didn't connect the two things.

The following compiles & runs fine; perhaps you can add more and more
in an effort to identify the problem:


#include <vector>

class MyDisplay
{
private:
enum DisplayType {SMALL,MEDIUM,LARGE};
DisplayType _displayType;
public:
MyDisplay(): _displayType(MEDIUM) {}
};

int main()
{
std::vector<MyDisplay> v( 10 );
std::vector<MyDisplay> v2 = v;
}

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach

"cppaddict" <> wrote in message
news...
> Hi,
>
> I've been trying to debug a strange runtime error for the last 5
> hours... I'm hoping someone might have an insight about it.
>
> I have an application that creates a vector of MyDisplay objects
> (MyDisplay is a custom class) and then uses them in various ways. The
> application has been compiling and running fine. Then I added a
> member variable of type enum to MyDisplay. So my class def now looks
> like this:
>
> class MyDisplay {
> enum DisplayType {SMALL,MEDIUM,LARGE};
> private:
> DisplayType _displayType;
> //....
> // all the rest of the def is the same as before
> }
>
> I also added a default value in the constructor initialization list:
>
> MyDisplay::MyDisplay() : _displayType(MEDIUM),
> //rest of ctor def is same as before
>
> Those are the ONLY two changes I've made so far. The app still
> compiles without error. However, it now crashes when I run it. (If I
> remove those changes, it will run perfectly). In particular, it
> crashes when the vector of MyDisplay objects is being created. The
> code creates 10 of them in total, and it crashes after the fourth one
> has been constructed and added to the vector.
>

From my experiance, a problem like this is usually caused by apparently
unrelated code. Often, it is caused by writing past the end of a local
array. When you do that, you trash the memory beyond the array's bounds,
which may or may not cause problems (at least not obvious ones, especially
in a debug build). When you later add something to the program, suddenly
that memory location just beyond the array becomes important, and
overwriting it causes a crash.

I'd look very carefully for something like this. I can't say how many times
I've seen it happen. Not that *I've* ever written beyond the end of an
array, of course!

-Howard

Howard

****UPDATE****

I have tried chaning the data type of _truncType to int.

When I do so I still see the problem, which means that it is not
specific to enum, but simply due to adding a new data member. Please
let me know if that gives you any new ideas.

>
>From my experiance, a problem like this is usually caused by apparently
>unrelated code. Often, it is caused by writing past the end of a local
>array. When you do that, you trash the memory beyond the array's bounds,
>which may or may not cause problems (at least not obvious ones, especially
>in a debug build). When you later add something to the program, suddenly
>that memory location just beyond the array becomes important, and
>overwriting it causes a crash.
>
>I'd look very carefully for something like this. I can't say how many times
>I've seen it happen. Not that *I've* ever written beyond the end of an
>array, of course!

Howard,

Thanks for thoughts.

Two things:

1. It couldn't be an array problem per se, because my code only uses
vectors.

2. Nevertheless, it may be a problem similar to what you describe.
Can you offer any ideas about specific things I should be on the alert
for?

thanks again,
cpp

cppaddict

On Tue, 13 Jul 2004 21:01:19 GMT in comp.lang.c++, cppaddict
<> wrote,
>1. It couldn't be an array problem per se, because my code only uses
>vectors.

It could easily be a ~"array problem"~ if you use vector:perator[]
since the subscript is unchecked just as for bare naked arrays.
Try changing some or all of your operator[] to vector::at().

David Harmon

>It could easily be a ~"array problem"~ if you use vector:perator[]
>since the subscript is unchecked just as for bare naked arrays.
>Try changing some or all of your operator[] to vector::at().

Thanks for that tip.

It turns out that the problem was much more mundane: My Makefile was
not updating one of the files that needed to be updated, so it was
using an outdated object file.

Thanks anyway for your help,
cpp

cppaddict