Re: A bug ( ? ) and a question

[Mike Stump <mrs at apple dot com>]

First, let me say this is the wrong list for how to program in C++,  
comp.lang.c++ would be better, or even comp.lang.c would be better.   
gcc-help would the a second choice.

On Mar 5, 2006, at 8:47 AM, Nieuwenhuizen, JK wrote:
>     cout << "Done";

This doesn't output anything immediately.  Either use "Done\n" or use  
flush.  Any decent book should explain this.  Alternatively, use  
write.  You can see any UNIX C programming book for the gory details  
of stdio buffering.

> I can put a breakpoint in the subprogram, gdb says it has been put,  
> but it
> never stops there, and stepping through the program I see it pass  
> my break. Of
> course I collided to it in more complicated sources.

b main, run, either it stops at main, or it doesn't.  If it doesn't,  
then gdb is busted, report the bug to gdb.  If it does, then you're  
set.  You can step by instructions (si) and lines (s) and at any  
point of interest, you can print out the pc, say with x/1i $pc, and  
say b<return> on that line and rerun the program and it will stop at  
the point, or gdb is busted.  Then you can compare those pc values to  
the values when you break on a particular line, they should be the  
same at some point.  If you optimize, you'll just have to gain  
experience on how the code is transformed and what it means to  
debugging, that's kinda beyond the scope of this email, use machine  
instruction break points and things like x/30i $pc to see where you  
are and what its doing.  If you can, don't optimize, it will provide  
an easier to understand debugging experience.

>  `sscanf` has always been a stepchild for C and C++

I don't recall reading that in the standard, can you provide a  
quote?  I kinda like sscanf anytime I need to do that.  I like scan  
over << most of the time.

> and the debugger handles it terribly.

Gosh, I've never had a problem with it in the debugger.

> Integers and doubles read correctly by
> `sscanf ( s+60, "%lf", Myint )` are OK when printed ( `cout  
> << ...` ), but gdb
> gives them as e.g. 3.43567655+345.

You'd have to report gdb issues to a gdb list:

mrs $ cat t.cc
#include <stdio.h>

double d;

main() {
  sscanf ("3.1415", "%lf", &d);
  printf ("%f\n", d);
  asm ("nop");
}
mrs $ g++ t.cc -g
mrs $ gdb a.out
GNU gdb 6.3.50-20050815 (Apple version gdb-456) (Thu Feb  9 06:00:45  
GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols  
for shared libraries .... done

(gdb) b main
Breakpoint 1 at 0x29ac: file t.cc, line 6.
(gdb) run
Starting program: /private/tmp/a.out
Reading symbols for shared libraries .. done

Breakpoint 1, main () at t.cc:6
6         sscanf ("3.1415", "%lf", &d);
(gdb) list
1       #include <stdio.h>
2
3       double d;
4
5       main() {
6         sscanf ("3.1415", "%lf", &d);
7         printf ("%f\n", d);
8         asm ("nop");
9       }
(gdb) b 8
Breakpoint 2 at 0x2a10: file t.cc, line 8.
(gdb) cont
Continuing.
3.141500

Breakpoint 2, main () at t.cc:8
8         asm ("nop");
(gdb) p d
$1 = 3.1415000000000002
(gdb) quit
The program is running.  Exit anyway? (y or n) y

If you can reproduce the above, then you should pursue this as a bug  
in gdb.  If you can, then it looks like you can stop in the debugger  
and print out doubles at least in the debugger.

> Stroustrup ch 20 and 21 give very little information on sprintf

man sprintf will provide lots of details on sprintf.  Any decent book  
on C should give details, google should give lots of detail too.  A  
quick count shows 1,990,000 things on google, the first one looked  
fine to me.

> and only mentions sscanf once.

google found 730,000 things, again, the first one looked fine.

> On internet Google search on "C++ tutorial sstream"
> gives > 800 hits, but only three really on sstreams and 1, maybe 2  
> can be
> used.

Get a line, then crack it.  If you get the line into a string, you  
can use string to crack it.  Once cracked, you can use atoi, sscanf  
or other such routines to crack out the data.

> But I have, as said, to read from a file ( `is.getline ( line, 200 ) 
> ` ) a line
> formatted as an 2 integers from position 10, resp 20, a string on  
> positions 30
> - 70, and a number of doubles at well-defined positions after that.

Yes, but you provide no details on that.  I'd use fgets, validate the  
line length ("\n" must be last or your screwed (not done reading the  
current line), then validate the contents of the line, then sscan  
them, call me weird.  If you want help with a specific problem, show  
a specific program that shows that problem, then the input to the  
program, and what you see (from the debugger).  By omitting details  
you omit the chance for people to help you.

> The string may include spaces, and that is the problem since a  
> stringstream
> thinks it has done what I asked for as soon as it finds a space, so  
> I have to
> tell him that he should read all 40 chars, no matter the contents  
> are and then
> start reading the trailing doubles. In the sources I can't find the
> solution. setw(40) does not help me out. So I need some formatting  
> directives
> for sstream, such as `an integer from positions 1 to 10; possibly  
> another
> integer from positions 11 - 20; a string of chars, including spaces  
> from
> positions 30 - 70; ...' .

fgets doesn't stop at spaces.  getline should not either (unless  
delim is ' ' of course).

buf+10 is the first int, buf+20 is the second one, and buf+30 is the  
start of the string.  Since you didn't show what you were doing, I  
can't say what's wrong with it.  What I can say is that sscanf (buf 
+10, "%i", &intvar) will get the int at position 10. Likewise for all  
other things at other positions.  The string is a bit trickier,  
strncpy (newbuf, buf+30, 40); newbuf[70] = 0; will grab the string  
into newbuf.  I don't think you were using buf+10 to get to the 10th  
character on the line.

> A second question is: How must I interpret the avalanche of @'s in
> /usr/include/c++/3.3.5/ files?

Carefully; :-)  I can't even begin to comprehend this question.