«

Hello,

I have a file with about 1400 lines of C++ code most of which
consists of a single class. An oversimplified version of the
file is the following...

--- BEGIN ORIGINAL FILE ---

#include <iostream>

class Foo {
public:
Foo(int x): _x(x) { init(); }
private:
void init();
int _x;
};

void Foo::init() {
std::cout << "Hello, World!" << std::endl;
}

int main(void) {
Foo foo(1024);
}

--- END ORIGINAL FILE ---

I then make the following change to the file, and would expect the
output to be the same, but alas, what I see is that the code compiles
with no errors, even runs, but when it runs I get unexpected run time
errors that seem to depend on the amount of methods I add to the class
(i.e. if I add one more the whole things starts to malfunction). So
here is what I think should be equivalent, but g++ produces an
executable file that does NOT do the same thing:

--- BEGIN MODIFIED EXAMPLE ---

#include <iostream>

class Foo {
public:
Foo(int x): _x(x) { init(); }
private:
void initialize();
void init();
int _x;
};

void Foo::initialize() {
init();
}

void Foo::init() {
std::cout << "Hello, World!" << std::endl;
}

int main(void) {
Foo foo(1024);
}

--- END MODIFIED EXAMPLE ---

Now this is a trivial modification. On this small code snippet,
everything works fine, but on my 1400 line class it's not the case,
and I am using GNU g++ 3.2.2 on a Debian Linux box.

So, can anyone please provide a hint as to what the problem may be???

This must be the most obscure bug I've ever come across.

Thanks,

Neil

"Neil Zanella" <> wrote in message
newsine.LNX.4.44.0310090331210.25500-...
> [...]
> Now this is a trivial modification. On this small code snippet,
> everything works fine, but on my 1400 line class it's not the
> case, and I am using GNU g++ 3.2.2 on a Debian Linux box.
>
> So, can anyone please provide a hint as to what the problem
> may be???

Incorrect assumptions about the failure mode? ;>

> This must be the most obscure bug I've ever come across.

Perhaps the bug is not in the compiler, but in the source. ;>
Without seeing your code, it is impossible to determine
which. If you really think it is a compiler bug, you should
post your code to the gcc bug list or GNATS.

Dave



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

Neil Zanella <> writes:

> Hello,
>
> I have a file with about 1400 lines of C++ code most of which
> consists of a single class. An oversimplified version of the
> file is the following...

<snip oversimplified example>

> Now this is a trivial modification. On this small code snippet,
> everything works fine, but on my 1400 line class it's not the case,
> and I am using GNU g++ 3.2.2 on a Debian Linux box.
>
> So, can anyone please provide a hint as to what the problem may be???

I bet you are overwriting memory you aren't supposed to - e.g.
stepping over the bounds of an array or sth like that.
Without the real source code, it's impossible to tell - you are
in for a really exciting debugging session
You might want to check out efence or valgrind - useful tools to
find / prevent this kind of programming error.

HTH & kind regards
frank

--
Frank Schmitt
4SC AG phone: +49 89 700763-0
e-mail: frankNO DOT SPAMschmitt AT 4sc DOT com

On Thu, 9 Oct 2003 03:39:50 -0230, Neil Zanella <>
wrote:

>Now this is a trivial modification. On this small code snippet,
>everything works fine, but on my 1400 line class it's not the case,

1400 lines is a bit long for a class. They shouldn't normally be
longer than a few hundred lines. You should probably split the
responsibilities of your class between several smaller ones.

>and I am using GNU g++ 3.2.2 on a Debian Linux box.
>
>So, can anyone please provide a hint as to what the problem may be???
>
>This must be the most obscure bug I've ever come across.

The problem will likely be an obscure bug - an uninitialized variable,
out of bounds array access, double deletion of a pointer or other
undefined behaviour. The only way to find it is careful use of a
debugger. The bug might be in code from a completely different class,
or it might be how you are using another class.

There is a vague possibility that it might be a compiler bug, but this
is orders of magnitude less likely than it being a "simple" bug in
your code.

Tom

Neil Zanella wrote:
....
-
>
> Now this is a trivial modification. On this small code snippet,
> everything works fine, but on my 1400 line class it's not the case,
> and I am using GNU g++ 3.2.2 on a Debian Linux box.
>
> So, can anyone please provide a hint as to what the problem may be???
>
> This must be the most obscure bug I've ever come across.

try running your code under valgrind (preferred) or efence and see what
it says.