Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #9438 > unrolled thread

Debugger Recommendation

Back to article view | Back to comp.lang.c++

Contents

  Debugger Recommendation Joseph Hesse <joeh@gmail.com> - 2011-08-29 09:40 -0500
    Re: Debugger Recommendation Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-29 11:01 -0400
    Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-29 19:19 +0200
      Re: Debugger Recommendation "Waldek M." <wm@localhost.localdomain> - 2011-08-29 21:37 +0200
        Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-08-30 07:51 +1200
          Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-29 22:52 +0200
            Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-08-30 08:56 +1200
              Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-29 23:00 +0200
                Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-08-30 09:21 +1200
                Re: Debugger Recommendation Nobody <nobody@nowhere.com> - 2011-08-30 04:58 +0100
          Re: Debugger Recommendation "Waldek M." <wm@localhost.localdomain> - 2011-08-31 21:45 +0200
            [OT] Re: Debugger Recommendation Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-10 02:17 -0500
              Re: [OT] Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-10 10:00 +0200
                Re: [OT] Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-10 21:14 +1200
                  Re: [OT] Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-10 11:26 +0200
                    Re: [OT] Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-10 21:33 +1200
                Re: [OT] Re: Debugger Recommendation Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-10 06:32 -0500
              Re: Debugger Recommendation Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-10 06:59 -0700
                Re: Debugger Recommendation Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-10 09:39 -0500
        Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-29 22:51 +0200
          Re: Debugger Recommendation "Waldek M." <wm@localhost.localdomain> - 2011-08-31 21:11 +0200
            Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-31 22:17 +0200
              Re: Debugger Recommendation "Waldek M." <wm@localhost.localdomain> - 2011-09-01 07:26 +0200
          Re: Debugger Recommendation dan <dan.campbell+nospam@gmail.com> - 2011-09-09 21:30 -0500
      Re: Debugger Recommendation DeMarcus <use_my_alias_here@hotmail.com> - 2011-09-22 08:57 +0200
        Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-22 09:16 +0200
          Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-22 19:46 +1200
          Re: Debugger Recommendation DeMarcus <use_my_alias_here@hotmail.com> - 2011-09-22 11:15 +0200
    Re: Debugger Recommendation Paul <pchristor@yahoo.co.uk> - 2011-08-29 22:02 -0700
      Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-30 11:09 +0200
        Re: Debugger Recommendation Paul <pchristor@yahoo.co.uk> - 2011-08-30 05:26 -0700
          Re: Debugger Recommendation Oliver Jackson <chexmofo@hotmail.com> - 2011-08-30 08:25 -0700
            Re: Debugger Recommendation Paul <pchristor@yahoo.co.uk> - 2011-08-30 10:34 -0700
    Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-11 20:37 +0000
      Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-12 00:40 +0200
        Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-12 21:58 +0000
          Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-13 00:52 +0200
            Re: Debugger Recommendation Juha Nieminen <nospam@thanks.invalid> - 2011-09-13 06:40 +0000
              Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 10:26 +1200
                Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 00:57 +0200
                  Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 11:13 +1200
                  Re: Debugger Recommendation Lynn McGuire <lmc@winsim.com> - 2011-09-14 18:16 -0500
                    Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 11:36 +1200
                  Re: Debugger Recommendation Juha Nieminen <nospam@thanks.invalid> - 2011-09-15 06:35 +0000
                    Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 09:29 +0200
                      Re: Debugger Recommendation Juha Nieminen <nospam@thanks.invalid> - 2011-09-15 07:46 +0000
                        Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 09:58 +0200
                          Re: Debugger Recommendation Juha Nieminen <nospam@thanks.invalid> - 2011-09-15 09:57 +0000
                            Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 19:30 +0900
                              Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 14:28 +0200
            Re: Debugger Recommendation yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-13 13:29 +0000
              Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-14 08:42 +1200
              Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 10:37 +0100
                Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 19:36 +0900
                Re: Debugger Recommendation yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-19 09:42 +0000
                  Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-19 10:59 +0000
            Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-13 20:09 +0000
          Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 10:11 +0100
            Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-16 21:29 +0000
      Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 10:08 +0100
        Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 21:23 +1200
          Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 11:38 +0200
            Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 21:41 +1200
          Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 10:43 +0100
        Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 11:34 +0200
          Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 21:54 +1200
          Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 11:44 +0100
            Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 18:56 +0200
              Re: Debugger Recommendation yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-19 09:53 +0000
                Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-19 22:34 +1200
                  Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-19 11:13 +0000
                    Re: Debugger Recommendation yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-22 11:41 +0000
                      Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-23 07:45 +1200
          Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-16 21:24 +0000
        Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 18:55 +0900
          Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 22:03 +1200
            Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 19:29 +0900
              Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 23:13 +1200
                Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 20:15 +0900
                  Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 23:22 +1200
          Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 11:52 +0100
            Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 20:13 +0900
            Re: Debugger Recommendation Marc <marc.glisse@gmail.com> - 2011-09-15 14:19 +0000

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#10116

On 09/15/11 10:57 AM, jacob navia wrote:
> Le 15/09/11 00:26, Ian Collins a écrit :
>> On 09/13/11 06:40 PM, Juha Nieminen wrote:
>>> jacob navia<jacob@spamsink.net>  wrote:
>>>> tools even better than valgrind,
>>>
>>> Are there any free ones? Because last time I chekced, there weren't
>>> (as incredible as that might sound).
>>
>> Are you (Jacob) going to answer this?
>
> http://msdn.microsoft.com/en-us/library/dd744766(v=vs.85).aspx

It's good to see they recommend RAII.

> The following Microsoft tools provide more-detailed information and can
> help to detect and diagnose leaks for the various allocation types in
> your application:
>
> Performance Monitor and Resource Monitor are part of Windows 7 and can
> monitor and graph resource use over time
> The latest version of Application Verifier can diagnose heap leaks on
> Windows 7
> UMDH, which is part of the Debugging Tools for Windows, analyzes the
> heap memory allocations for a given process and can help find leaks and
> other unusual usage patterns
> Xperf is a sophisticated performance analysis tool with support for heap
> allocation traces
> CRT Debug Heap tracks heap allocations and can help build your own heap
> debugging features

Do any of these offer the most useful feature of valgrind and dbx: 
memory access checking?

I am genuinely curious as I may have to update some windows based code!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#10118

On 9/14/2011 5:57 PM, jacob navia wrote:
> Le 15/09/11 00:26, Ian Collins a écrit :
>> On 09/13/11 06:40 PM, Juha Nieminen wrote:
>>> jacob navia<jacob@spamsink.net> wrote:
>>>> tools even better than valgrind,
>>>
>>> Are there any free ones? Because last time I chekced, there weren't
>>> (as incredible as that might sound).
>>
>> Are you (Jacob) going to answer this?
>>
>
> http://msdn.microsoft.com/en-us/library/dd744766(v=vs.85).aspx
>
> The following Microsoft tools provide more-detailed information and can help to detect and diagnose leaks for the various allocation
> types in your application:
>
> Performance Monitor and Resource Monitor are part of Windows 7 and can monitor and graph resource use over time
> The latest version of Application Verifier can diagnose heap leaks on Windows 7
> UMDH, which is part of the Debugging Tools for Windows, analyzes the heap memory allocations for a given process and can help find
> leaks and other unusual usage patterns
> Xperf is a sophisticated performance analysis tool with support for heap allocation traces
> CRT Debug Heap tracks heap allocations and can help build your own heap debugging features
>
>
> http://channel9.msdn.com/Shows/Going+Deep/RADAR-Windows-Automatic-Memory-Leak-Detection
>
> I didn't look the video but it looks promising.
>
> Another memory leak tool:
> http://winleak.sourceforge.net/
>
> All of those are free. Of course you can BUY maybe better tools,
> something you can't do under linux.
>
> :-)

You can buy Rational Purify for Windows, Lunix or Unix :
    http://www-01.ibm.com/software/awdtools/purify/

Excellent tool and the noise is not bad.  I haven't used
it in several years though.

Lynn

[toc] | [prev] | [next] | [standalone]

#10119

On 09/15/11 11:16 AM, Lynn McGuire wrote:
>
> You can buy Rational Purify for Windows, Lunix or Unix :
>      http://www-01.ibm.com/software/awdtools/purify/
>
> Excellent tool and the noise is not bad.  I haven't used
> it in several years though.

Last time I tried Purify it did the job, but it didn't offer any 
benefits over the native OS (Solaris/Linux) tools.  They also suffer 
from the usual shifting sand problems keeping up to date with Linux kernels!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#10124

jacob navia <jacob@spamsink.net> wrote:
> Performance Monitor and Resource Monitor are part of Windows 7 and can 
> monitor and graph resource use over time

  It doesn't make completely clear whether it simply reports possible leaks,
or whether it actually tells you which line of code made the allocation
(that is then leaked).

  Anyways, not everybody has Windows 7 (including me).

[toc] | [prev] | [next] | [standalone]

#10129

Le 15/09/11 08:35, Juha Nieminen a écrit :
> jacob navia<jacob@spamsink.net>  wrote:
>> Performance Monitor and Resource Monitor are part of Windows 7 and can
>> monitor and graph resource use over time
>
>    It doesn't make completely clear whether it simply reports possible leaks,
> or whether it actually tells you which line of code made the allocation
> (that is then leaked).
>
>    Anyways, not everybody has Windows 7 (including me).

Well, you should use a maintained windows system. For instance I was
using an old version of Ubuntu and could not load updates any more.
I had to upgrade.

Now, windows is not very different.

The performance monitor reports memory usage, so, if you have a leak
you know how serious it is.

See the documentation for further information.

[toc] | [prev] | [next] | [standalone]

#10130

jacob navia <jacob@spamsink.net> wrote:
> Well, you should use a maintained windows system. For instance I was
> using an old version of Ubuntu and could not load updates any more.
> I had to upgrade.
> 
> Now, windows is not very different.

  There's one big difference: Windows costs money, and not even a very
insignificant amount. (It might be different on the MacOS X side, where
an upgrade costs, what, something like 10 dollars?)

  I didn't upgrade from XP to Vista when it came out, and I certainly don't
regret that decision. Why should have I wasted money on Vista, when XP worked
just fine, and a few years forward and we have an even better version of
"Vista", with most of the problems polished out.

  So far I have seen no compelling reason to upgrade to Windows 7 either.
Maybe Windows 8 in a couple of years.

  (Of course it also affects this decision that Windows is not my main OS.
I only use it to play games. So far games still support XP. When they stop
supporting it, that's when the purchase of a new Windows might be relevant
for me.)

[toc] | [prev] | [next] | [standalone]

#10131

Le 15/09/11 09:46, Juha Nieminen a écrit :
>    So far I have seen no compelling reason to upgrade to Windows 7 either.
> Maybe Windows 8 in a couple of years.
>
>    (Of course it also affects this decision that Windows is not my main OS.
> I only use it to play games.

The why the hell are you looking for a leak detector under windows
then????

To see if your games leak memory and debug them with the disassembler?

YOU asked for a free leak detector under windows. I researched the
subject, spent time answering, then...

"I use windows to play games".

Of course your whole point is to write about how bad windows
is and how clever you are because you use linux. Typical of
linux "fans".

[toc] | [prev] | [next] | [standalone]

#10156

jacob navia <jacob@spamsink.net> wrote:
> Le 15/09/11 09:46, Juha Nieminen a écrit :
>>    So far I have seen no compelling reason to upgrade to Windows 7 either.
>> Maybe Windows 8 in a couple of years.
>>
>>    (Of course it also affects this decision that Windows is not my main OS.
>> I only use it to play games.
> 
> The why the hell are you looking for a leak detector under windows
> then????

  Because sometimes I have to write some tools for Windows as my payjob.
(And yes, we ended up purchasing a commercial valgrind equivalent because
there were no free alternatives.)

> Of course your whole point is to write about how bad windows
> is and how clever you are because you use linux. Typical of
> linux "fans".

  I don't see the connection between "there are no free leak detectors
for Windows" and "windows is bad". Is it somehow the fault of Windows
that there are no free tools for something?

[toc] | [prev] | [next] | [standalone]

#10159

Juha Nieminen <nospam@thanks.invalid> writes:
> jacob navia <jacob@spamsink.net> wrote:
>> Of course your whole point is to write about how bad windows
>> is and how clever you are because you use linux. Typical of
>> linux "fans".
>
>   I don't see the connection between "there are no free leak detectors
> for Windows" and "windows is bad". Is it somehow the fault of Windows
> that there are no free tools for something?

jacob is verrrrry prickly whenever he thinks somebody is dissing
windows...

-miles

-- 
gravity a demanding master ... soft soft snow

[toc] | [prev] | [next] | [standalone]

#10169

Le 15/09/11 12:30, Miles Bader a écrit :
> Juha Nieminen<nospam@thanks.invalid>  writes:
>> jacob navia<jacob@spamsink.net>  wrote:
>>> Of course your whole point is to write about how bad windows
>>> is and how clever you are because you use linux. Typical of
>>> linux "fans".
>>
>>    I don't see the connection between "there are no free leak detectors
>> for Windows" and "windows is bad". Is it somehow the fault of Windows
>> that there are no free tools for something?
>
> jacob is verrrrry prickly whenever he thinks somebody is dissing
> windows...
>
> -miles
>

I develop under Mac OSX since a year or so. I left windows for several
reasons, maybe one of them is that Mac seems a better platform.

But I dislike this "If you use windows you are a microsoft slave"
attitude, that's all.

[toc] | [prev] | [next] | [standalone]

#10075

In article <j4m2fd$fc4$1@speranza.aioe.org>,
jacob navia  <jacob@jspamsink.org> wrote:
>Le 12/09/11 23:58, Jorgen Grahn a écrit :
>> On Sun, 2011-09-11, jacob navia wrote:
>>> Le 11/09/11 22:37, Jorgen Grahn a écrit :
>>>> You might want to know that many C++ users rarely or never use a
>>>> traditional debugger[1]. I'm one of them -- I used gdb for a while last
>>>> Friday, but the time before that was many years ago.
>>>>
>>>
>>> WOW Batman!!!
>>>
>>> You are just GREAT Batman.
>>>
>>> I have always looked in awe when you passed dressed in black,
>>> going to fight the forces of the evil bugs, without a debugger,
>>> just with your resolve and heroic lack of fear.
>>>
>>> Thanks for saving us Batman!
>>
>> Do you have a point of some kind?  Let me also repeat the part you
>> neglected to quote:
>>
>> [1] Not trying to start the debugger-versus-no-debugger war again. Just
>>      stating a fact.  And no, I don't have any idea how many "many" is.
>>
>Look Jorgen, I can't really stand people that tell:
>
> > On Unix, you need to be able to debug core dumps but when dealing with
> > *running* programs it's more important to know tools like
> > - the compiler
> > - valgrind
> > - strace and ltrace,
> > and knowing how to write unit tests. All of that is IMHO more
> > important than live debugging.
>
>Implicitly you say that people that use a debugger are kind of
>slightly moronic, being unable to use
>- the compiler
>- valgrind
>- strace and ltrace
>and (of course) they do not know how to write unit tests.
>
>THAT is what bothers me, that condescending tone (On Unix... etc)
>as windows wouldn't have compilers, tools even better than valgrind,
>and windows programmers do not know what unit tests are.

You chose to read it as condescending and then chose to reply in an
extremely rude and childish manner.  That's unfortunate.

If we try to get the conversation back on track:

I use debuggers.  I find them useful.  However, one thing that I
strongly believe and that I have observed in some professional
developpers is a far too great readiness to resort to the debugger as
a first port of call.

I believe the point that Jorgen was trying to make is that:

- You should use compilers capabilities to help verify your code.
- You should write unit tests and try to have high code coverage.
  With good unit test, a lot less debugging is required.
- You should use tools like valgrind on your unit test and on your
  full program.  Valgrind will often detect errors in one short run
  that will only be noticed after a "long time" in the field.

Once you have done the above, a lot of the basic bugs have already
been detected and fixed.  That often leaves you with more difficult to
find and more difficult to reproduce bugs.  For these, stepping
through with a debugger is often far from efficient (and often useless
if there is a timing issue involved).  In addition, for complex
application, running through a debugger is often an extremely
labourious task.  

For hard to find / hard to recreate bug, often observing the system
using tools like strace, ltrace or even just high log level (it's a
good idea to build in adjustable logging levels).  By analysing what
you observe for the above, you then figure out the location of the
bug.  At which point, often you can find more by improving your local
unit tests but if you want, you can then finally open up the debugger
and place a breakpoint near the area of interest.  

Maybe the above sound condescending to you but I have far too often
seen a developper start with a debugger immediately and try to use a
debugger to locate a problem in a >100Kloc multithreaded application.  

Yannick

[toc] | [prev] | [next] | [standalone]

#10086

On 09/14/11 01:29 AM, none Yannick Tremblay wrote:
> jacob navia<jacob@jspamsink.org>  wrote:
>>
>> THAT is what bothers me, that condescending tone (On Unix... etc)
>> as windows wouldn't have compilers, tools even better than valgrind,
>> and windows programmers do not know what unit tests are.
>
> You chose to read it as condescending and then chose to reply in an
> extremely rude and childish manner.  That's unfortunate.
>
> If we try to get the conversation back on track:
>
> I use debuggers.  I find them useful.  However, one thing that I
> strongly believe and that I have observed in some professional
> developpers is a far too great readiness to resort to the debugger as
> a first port of call.
>
> I believe the point that Jorgen was trying to make is that:
>
> - You should use compilers capabilities to help verify your code.
> - You should write unit tests and try to have high code coverage.
>    With good unit test, a lot less debugging is required.
> - You should use tools like valgrind on your unit test and on your
>    full program.  Valgrind will often detect errors in one short run
>    that will only be noticed after a "long time" in the field.

I agree with all of the above, with the slight difference that on my 
platform of choice (OpenSolaris derivatives), the functionality of 
valgrind in a component of the debugger (dbx).

In most of my work, tools that allow me to selectively observe a running 
system are more important that a debugger.  It's only when you use a 
tool like Solaris' dtrace 
(http://hub.opensolaris.org/bin/view/Community+Group+dtrace/) that you 
realise how useful they are.

In my new code, I work to the rule that if I have to use the debugger to 
find a bug, my unit tests aren't good enough...

As a tool for understanding someone else's code, the debugger is invaluable.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#10149

none wrote:

> I believe the point that Jorgen was trying to make is that:
> 
> - You should use compilers capabilities to help verify your code.
> - You should write unit tests and try to have high code coverage.
> With good unit test, a lot less debugging is required.
> - You should use tools like valgrind on your unit test and on your
> full program.  Valgrind will often detect errors in one short run
> that will only be noticed after a "long time" in the field.

Unit tests help run some tests to check if components work as expected and 
valgrind helps with memory leaks.  By employing those, a programmer wouldn't 
need a debug if all the problems that a programmer could ever stumble on 
were only due to a combination of components failing preconceived tests and 
memory leaks.  This isn't true.  Sometimes a program simply behaves 
unexpectedly, and a programmer is therefore faced with the need to run a 
program step by step, evaluating the outcome of each step, to be able to 
understand what is happening and why is it happening.  Unit checks don't do 
this, neither does valgrind.  Without a debugger, all you end up having is a 
nasty cycle of sprinkling your code with cout/cerr, recompiling it and 
running the program to analyze the output of your set of cout/cerr.  And 
this is a less than adequate solution to a frequent problem.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#10160

Rui Maciel <rui.maciel@gmail.com> writes:
> Sometimes a program simply behaves unexpectedly, and a programmer is
> therefore faced with the need to run a program step by step,
> evaluating the outcome of each step, to be able to understand what
> is happening and why is it happening.  Unit checks don't do this,
> neither does valgrind.  Without a debugger, all you end up having is
> a nasty cycle of sprinkling your code with cout/cerr, recompiling it
> and running the program to analyze the output of your set of
> cout/cerr.

But the converse is also true:  people often over-rely on debuggers,
and spent huge amounts of time stepping and examining, when a
different tool / technique would find the problem much more quickly.

As with most things, the balance lies somewhere in the middle:
sometimes a debugger is the best tool for a debugging task, at other
times valgrind-type tools are, and sometimes "printf debugging" is the
right thing.  A good programmer can use all of these techniques, and
has an intuition as to when each is called for.

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

[toc] | [prev] | [next] | [standalone]

#10277

In article <4e71c76b$0$24022$a729d347@news.telepac.pt>,
Rui Maciel  <rui.maciel@gmail.com> wrote:
>none wrote:
>
>> I believe the point that Jorgen was trying to make is that:
>> 
>> - You should use compilers capabilities to help verify your code.
>> - You should write unit tests and try to have high code coverage.
>> With good unit test, a lot less debugging is required.
>> - You should use tools like valgrind on your unit test and on your
>> full program.  Valgrind will often detect errors in one short run
>> that will only be noticed after a "long time" in the field.
>
>Unit tests help run some tests to check if components work as expected and 
>valgrind helps with memory leaks.  By employing those, a programmer wouldn't 
>need a debug if all the problems that a programmer could ever stumble on 
>were only due to a combination of components failing preconceived tests and 
>memory leaks.  This isn't true.  

Euh... Not sure of your point.  Obviously, unit tests will only test
what they test.  If some things are not tested, then they haven't been
tested and you will need to diagnosed the error in a different way.
Using a debugger is a possible way.

However, the fact that you will never be able to cover 100% of
possible failure scenarios with unit test does not change that good
use of unit tests will help detecting errors early and reducing time
and effort required to do step-by-step debugging.

Note: I never claimed that unit tests + valgrind finds *all* bugs.  

>Sometimes a program simply behaves 
>unexpectedly, and a programmer is therefore faced with the need to run a 
>program step by step, evaluating the outcome of each step, to be able to 
>understand what is happening and why is it happening.  

Yes, agree sometimes you need to uswe the debugger. In fact, I have
sometimes even run my unit tests in a debugger.

> Unit checks don't do this, neither does valgrind.  

Unit tests don't do what a debugger do.  They are a different tool.  

>Without a debugger, all you end up having is a 
>nasty cycle of sprinkling your code with cout/cerr, recompiling it and 
>running the program to analyze the output of your set of cout/cerr.  And 
>this is a less than adequate solution to a frequent problem.

I disagree with your use of pejorative qualifier here.  The so-called
"printf" debugging can often be much more efficient than the use of a
debugger.  It depends.  

Generally, I would not put raw cout but use a macro that can be turned
on and off but regardless this is far from an invalid technique.  

[toc] | [prev] | [next] | [standalone]

#10280

On Mon, 2011-09-19, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
> In article <4e71c76b$0$24022$a729d347@news.telepac.pt>,
> Rui Maciel  <rui.maciel@gmail.com> wrote:
...
>>Without a debugger, all you end up having is a 
>>nasty cycle of sprinkling your code with cout/cerr, recompiling it and 
>>running the program to analyze the output of your set of cout/cerr.  And 
>>this is a less than adequate solution to a frequent problem.
>
> I disagree with your use of pejorative qualifier here.  The so-called
> "printf" debugging can often be much more efficient than the use of a
> debugger.  It depends.  
>
> Generally, I would not put raw cout but use a macro that can be turned
> on and off but regardless this is far from an invalid technique.  

You can always find someone who disagrees in new and interesting ways...

I too see the merit in printf debugging, and happily use it.

But if your "can be turned on and off" implies trace messages which is
part of the code base, then I'm not so sure it's generally a good idea.

Trace messages everywhere makes the code harder to read, and when you
do need them, chances are the ones you need don't exist, and the ones
that *are* there are so many that you can't enable them without
drowning in text.

I'd rather have logging (to Unix syslog) of a few well-defined events,
and insert specific trace messages only during debugging.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#10084

On Mon, 2011-09-12, jacob navia wrote:
> Le 12/09/11 23:58, Jorgen Grahn a écrit :
>> On Sun, 2011-09-11, jacob navia wrote:
>>> Le 11/09/11 22:37, Jorgen Grahn a écrit :
>>>> On Mon, 2011-08-29, Joseph Hesse wrote:
>>>>> Hi,
>>>>>
>>>>> I have never used a debugger and would like to know which one(s) are the
>>>>> best.  I prefer one with a graphic interface.
>>>>>
>>>>> I use gnu c++ and Linux.
>>>>
>>>> You might want to know that many C++ users rarely or never use a
>>>> traditional debugger[1]. I'm one of them -- I used gdb for a while last
>>>> Friday, but the time before that was many years ago.
>>>>
>>>
>>> WOW Batman!!!
>>>
>>> You are just GREAT Batman.
...
>>
>> Do you have a point of some kind?  Let me also repeat the part you
>> neglected to quote:
>>
>> [1] Not trying to start the debugger-versus-no-debugger war again. Just
>>      stating a fact.  And no, I don't have any idea how many "many" is.
>>
> Look Jorgen, I can't really stand people that tell:
>
> > On Unix, you need to be able to debug core dumps but when dealing with
> > *running* programs it's more important to know tools like
> > - the compiler
> > - valgrind
> > - strace and ltrace,
> > and knowing how to write unit tests. All of that is IMHO more
> > important than live debugging.
>
> Implicitly you say that people that use a debugger are kind of
> slightly moronic, being unable to use
>
> - the compiler
> - valgrind
> - strace and ltrace
> and (of course) they do not know how to write unit tests.
>
> THAT is what bothers me, that condescending tone (On Unix... etc)
> as windows wouldn't have compilers, tools even better than valgrind,
> and windows programmers do not know what unit tests are.

Ironically, I wrote "on Unix" so that people wouldn't call me a Unix
bigot when I mentioned Unix-specific tools.

On another day and in another mood I might have said the above
condescendingly. But here I just tried to state facts as I see them.

Remember the original poster? Yes, I believe that if he's familiar
with none of the tools mentioned above, the interactive debugger
shouldn't be at the top of his list.

(BTW, I *do* know at least two programmers who are better at it than
me, and who use the Visual Studio interactive debugger as one of their
main tools.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#10142

Jorgen Grahn wrote:

> Do you have a point of some kind?  Let me also repeat the part you
> neglected to quote:
> 
> [1] Not trying to start the debugger-versus-no-debugger war again. Just
> stating a fact.  And no, I don't have any idea how many "many" is.

Actually, you haven't expressed a fact, only an opinion.  Unless you can 
actually demonstrate in an objective way that " many C++ users rarely or 
never use a traditional debugger" and that your definition of "many" refers 
to a relevant part of the C++ community, you can't claim it's a relevant 
statement with any relation to reality, let alone a fact.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#10202

On Thu, 2011-09-15, Rui Maciel wrote:
> Jorgen Grahn wrote:
>
>> Do you have a point of some kind?  Let me also repeat the part you
>> neglected to quote:
>> 
>> [1] Not trying to start the debugger-versus-no-debugger war again. Just
>> stating a fact.  And no, I don't have any idea how many "many" is.
>
> Actually, you haven't expressed a fact, only an opinion.  Unless you can 
> actually demonstrate in an objective way that " many C++ users rarely or 
> never use a traditional debugger" and that your definition of "many" refers 
> to a relevant part of the C++ community, you can't claim it's a relevant 
> statement with any relation to reality, let alone a fact.

Well, it's my opinion that it is a fact. This isn't Wikipedia ...
And again: no, I don't have any idea how many "many" is.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#10141

Jorgen Grahn wrote:

> You might want to know that many C++ users rarely or never use a
> traditional debugger[1]. I'm one of them -- I used gdb for a while last
> Friday, but the time before that was many years ago.
> 
> On Unix, you need to be able to debug core dumps but when dealing with
> running programs it's more important to know tools like
> - the compiler
> - valgrind
> - strace and ltrace,
> and knowing how to write unit tests. All of that is IMHO more
> important than live debugging.

It can be said that one of the reasons why "many C++ users" tend not to use 
a debugger in linux is that gdb doesn't work well with C++, and once we 
ignore gdb there isn't much left to consider.  Nonetheless, if there was a 
decent debugger that adequately supported C++ then "many C++ users" would 
use it, including for stuff where valgrind and other tools are employed.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web