You need to use a debugger, such as gdb. Google for "gdb tutorial".
Another option is to use some integrated development environment, such as free ones Eclipse or NetBeans. They may be much easier to start with for beginners.
On Sun, 2009-10-25, Maxim Yegorushkin wrote: > On 25/10/09 14:51, t wrote: >> Hi >> How to debuge programc in gcc
> You need to use a debugger, such as gdb. Google for "gdb tutorial".
Well, he doesn't actually need a debugger to debug.
Debugging is to me the activity of fixing bugs in general. You can do that by reading the code, inserting printf()s, writing unit tests, running it under strace/valgrind/etc, provoking it in various ways ... or stepping around in a symbolic debugger.
Personally I never learned to enjoy that last kind of debugging, not even in C with its usually simpler call chains. (Although naturally I use gdb for post-mortem debugging of core dumps -- I'm not stupid).
/Jorgen
-- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
> On Sun, 2009-10-25, Maxim Yegorushkin wrote: >> On 25/10/09 14:51, t wrote: >>> Hi >>> How to debuge programc in gcc >> You need to use a debugger, such as gdb. Google for "gdb tutorial".
> Well, he doesn't actually need a debugger to debug.
> Debugging is to me the activity of fixing bugs in general. You can do > that by reading the code, inserting printf()s, writing unit tests, > running it under strace/valgrind/etc, provoking it in various ways ... > or stepping around in a symbolic debugger.
> Personally I never learned to enjoy that last kind of debugging, not > even in C with its usually simpler call chains. (Although naturally I > use gdb for post-mortem debugging of core dumps -- I'm not stupid).
You never learned to use a debugger?
If you would have learned, then you would need to do post mortem debugging less often...
> On Sun, 2009-10-25, Maxim Yegorushkin wrote: >> On 25/10/09 14:51, t wrote: >>> Hi >>> How to debuge programc in gcc
>> You need to use a debugger, such as gdb. Google for "gdb tutorial".
> Well, he doesn't actually need a debugger to debug.
> Debugging is to me the activity of fixing bugs in general. You can do > that by reading the code, inserting printf()s, writing unit tests, > running it under strace/valgrind/etc, provoking it in various ways ... > or stepping around in a symbolic debugger.
Can not agree more.
> Personally I never learned to enjoy that last kind of debugging, not > even in C with its usually simpler call chains. (Although naturally I > use gdb for post-mortem debugging of core dumps -- I'm not stupid).
My first computer was a russian clone of Z80. Most of Z80 programs were naturally written in assembly language, so the first thing to learn was to inspect Z80 assembly code with a debugger and a pencil to comment, injecting printf() statements was science fiction for me at the time ;)
Jorgen Grahn wrote: > Debugging is to me the activity of fixing bugs in general. You can do > that by reading the code, inserting printf()s, writing unit tests, > running it under strace/valgrind/etc, provoking it in various ways ... > or stepping around in a symbolic debugger.
You forgot the liberal use of assert(). I cannot even count how many bugs I have caught very early on development thanks to my liberal use of assert().
On Tue, 2009-10-27, Juha Nieminen wrote: > Jorgen Grahn wrote: >> Debugging is to me the activity of fixing bugs in general. You can do >> that by reading the code, inserting printf()s, writing unit tests, >> running it under strace/valgrind/etc, provoking it in various ways ... >> or stepping around in a symbolic debugger.
> You forgot the liberal use of assert(). I cannot even count how many > bugs I have caught very early on development thanks to my liberal use of > assert().
Yeah -- including that one I half-jokingly wanted to have in the standard library: assume(), hope() or jump_to_conclusion().
(For when you want to assert() something in early prototyping, but know that you *will* have to handle it seriously later on.)
/Jorgen
-- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
> Jorgen Grahn a écrit : > > On Sun, 2009-10-25, Maxim Yegorushkin wrote: > >> On 25/10/09 14:51, t wrote: > >>> How to debuge programc in gcc > >> You need to use a debugger, such as gdb. Google for "gdb tutorial". > > Well, he doesn't actually need a debugger to debug. > > Debugging is to me the activity of fixing bugs in general. > > You can do that by reading the code, inserting printf()s, > > writing unit tests, running it under strace/valgrind/etc, > > provoking it in various ways ... or stepping around in a > > symbolic debugger. > > Personally I never learned to enjoy that last kind of > > debugging, not even in C with its usually simpler call > > chains. (Although naturally I use gdb for post-mortem > > debugging of core dumps -- I'm not stupid). > You never learned to use a debugger? > If you would have learned, then you would need to do post > mortem debugging less often...
More likely, you're confusing cause and effect. He's never learned to use a debugger because he hasn't needed it: some of the ways he has enumerated (code review, detailed unit tests) are more effective than a debugger in finding an eliminating bugs. I know that in situations where good code review and extensive unit tests are required, almost no one ends up using the debugger, and in general, I feel that if I need a debugger, I'm doing something wrong: programming too carelessly, for example, or not writing detailed enough unit tests. (Typically, I'll use one once or twice a year, at the most, and I've done whole projects without one.)
On Mon, 2009-10-26, jacob navia wrote: > Jorgen Grahn a écrit : >> On Sun, 2009-10-25, Maxim Yegorushkin wrote: >>> On 25/10/09 14:51, t wrote: >>>> Hi >>>> How to debuge programc in gcc >>> You need to use a debugger, such as gdb. Google for "gdb tutorial".
>> Well, he doesn't actually need a debugger to debug.
>> Debugging is to me the activity of fixing bugs in general. You can do >> that by reading the code, inserting printf()s, writing unit tests, >> running it under strace/valgrind/etc, provoking it in various ways ... >> or stepping around in a symbolic debugger.
>> Personally I never learned to enjoy that last kind of debugging, not >> even in C with its usually simpler call chains. (Although naturally I >> use gdb for post-mortem debugging of core dumps -- I'm not stupid).
> You never learned to use a debugger?
I never learned to *enjoy* it, that was what I wrote. But yes, I tend to get lost quickly, and I make frequent mistakes, like setting breakpoints in the wrong place.
I don't think this is embarrassing or unusual. Most programmers I know don't use debuggers that way. Maybe it's more common among Windows programmers -- I have seen one or two good ones use it a lot.
> If you would have learned, then you would need to do post > mortem debugging less often...
> :-)
I doubt that. I haven't seen people step around in a debugger and discover crashes they couldn't find more easily by just running the program (possibly under valgrind or a similar tool).
/Jorgen
-- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
Jorgen Grahn wrote: > Yeah -- including that one I half-jokingly wanted to have in the > standard library: assume(), hope() or jump_to_conclusion().
Actually an "assume()" function/keyword could be useful in that it could help the compiler to perform better optimizations. For example, you could have something like this:
If NDEBUG is not defined, the assume() would work as a regular assert(). In either case the compiler could use it to optimize the subsequent std::sqrt call because it can assume that d is always non-negative.
On Fri, 2009-10-30, Juha Nieminen wrote: > Jorgen Grahn wrote: >> Yeah -- including that one I half-jokingly wanted to have in the >> standard library: assume(), hope() or jump_to_conclusion().
> Actually an "assume()" function/keyword could be useful in that it > could help the compiler to perform better optimizations. For example, > you could have something like this:
> If NDEBUG is not defined, the assume() would work as a regular > assert(). In either case the compiler could use it to optimize the > subsequent std::sqrt call because it can assume that d is always > non-negative.
Hm, maybe -- but then you have a different definition than I had:
(For when you want to assert() something in early prototyping, but know that you *will* have to handle it seriously later on.)
It's not a hint to the compiler about what will be the usual case, it's a hint to the reader that the code isn't yet solid.
In your foo(double) example, I would have simply used assert(d >= 0.0).
/Jorgen
-- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
|
