This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A bug ( ? ) and a question

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
#include <stdio.h>

double d;

main() {
sscanf ("3.1415", "%lf", &d);
printf ("%f\n", d);
asm ("nop");
mrs $ g++ -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, line 6.
(gdb) run
Starting program: /private/tmp/a.out
Reading symbols for shared libraries .. done

Breakpoint 1, main () at
6         sscanf ("3.1415", "%lf", &d);
(gdb) list
1       #include <stdio.h>
3       double d;
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, line 8.
(gdb) cont

Breakpoint 2, main () at
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

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]