Re: Including <iostream> affects whether or not program freezes?

["Chris Jefferson" <chris at bubblescope dot net>]

2008/7/9 James Gregory <james.jrg@gmail.com>:
> 1. Compile with MSVC 7.1, no optimization: my program doesn't freeze
> 2. Compile with MSVC 7.1, with optimization: my program doesn't freeze
> 3. Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program
> doesn't freeze
> 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my
> program freezes in a particular function
> 5. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization, and
> include <iostream> at the top of the file where the function which
> freezes is defined: my program doesn't freeze
>
> Debugging this is difficult.

While I could well be repeating what others say, my usual tools for
situations like this, which (touch wood) tend to get me out of it:

A) Turn on all warnings, and read what they say. I've found this kind
of thing can be caused by a missing return statement.
B) Turn on the debugging standard library, if you are using any of the
STL in your code.
C) Find the minimial set of optimisation flags you need to trigger
your problem (in particular if you can turn off inlining it will make
things easier). This makes the next stage easier.
D) Use valgrind and see what it comes up with.

The <iostream> problem sounds to me like your problem could well be
triggered by inlining, which is often very sensitive (at least in g++)
and can change from headers being included on occasion.


>
> James
>