Very Computer

When I step through a program that has been compiled with g++ and come
to a cout or a cin I get the following error message about ten or so
times:

iostream.cc:###: No such file or directory.  If I wasn't debugging the
program the problem would be transparent to me since cin and cout seem
to be working just fine.  I checked my system for iostream.cc and it was
not found however iostream.h was found at location /usr/include/g++.  

I would greatly appreaciate any info on this problem if it is really a
problem.  

                                             Thank,
                                             Scott Gray

This is the same message you'd get if you tried to step into a .cc file
*you* wrote, if you didn't compile it with the -g option.  It is
annoying, though, isn't it?  The best thing to do is just type "finish",
and then gdb will run your program until the iostream function you've
entered returns.

I wonder how many of us there are left, using gdb?  I believe X has a
better (or at least flashier) de*.  Anyway, as long as I have you on
the line :) I'll pose a question: do you ever find that gdb gives you the
wrong answer when you try to print ('p') a variable that was an argument
to the function you're in?  This is my own beef with gdb...or maybe I'm
doing something wrong?

Ted Sternberg
Parametric Economic Research
San Jose, California, USA

-----BEGIN PGP SIGNED MESSAGE-----

Most other de*s are merely front-ends to gdb. One of the most
powerful ones is "ddd"; but even with all its nice GUI features, you
can still use plain old gdb commands in one of the windows :-) I would
strongly recommend that you try out "ddd" if you have not done so
before.

Quote:> Anyway, as long as I have you on
> the line :) I'll pose a question: do you ever find that gdb gives you the
> wrong answer when you try to print ('p') a variable that was an argument
> to the function you're in?  This is my own beef with gdb...or maybe I'm
> doing something wrong?

There are two situations when this can happen:
  1) You compiled your code with optimization enabled and the optimizer
     detected that the variable is no longer used in this function. It
     might then reuse the register that stored this variable for a
     different variable. This can sometimes be quite confusing as it
     is not always obvious when the optimizer decided to load and
     unload registers. In general, optimization does not do much harm
     and you will usually want it to be enabled, but every once in a
     while it might be helpful to turn it off, in order to ease
     debugging.
  2) You compiled with "-fomit-frame-pointer". While this is arguably
     a good idea for the final version of your program (as it results
     in slightly better code), it will most certainly result in your
     de* being seriously confused, because it cannot properly
     locate variables (and parameters) that are accessible from the
     stack. If you intend on debugging the excutable never use this
     option.

So long,

Markus

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAgUBMXqrthqJqDLErwMxAQFPdAQAvVt8XRKqd8ZsYrFTNATHAKkeCILqad3f
/05P/jmf7yeaf2qWxFCuTPsXsG8O2vfp7i0S0Xh0sdoggeyf/SH2MQF9dvWwGbaJ
oH5WttIFr7FHFzRNfwhtqnK1J0ece6rIWmMX4vCi0dwYs3ODPR4BwCE4zsYPfp8k
6kZ6o3RJ0wk=
=Abpm
-----END PGP SIGNATURE-----
--

Schlage 5a
D-48268 Greven-Gimbte
Germany