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.
