«

On 8/5/2011 2:41 AM, Miles Bader wrote:
> BGB<> writes:
>>> Hmm, I've found VC's debugger pretty annoying actually.
>>>
>>> I suspect (as with most such things) that it depends as much on what
>>> you're used to, as it does on actual functionality...
>>
>> IME, once one gets use to the VS debugger, it is often a lot faster to
>> actually figure out what has gone on and why than with GDB.
>
> Hard to say; I don't use it so often, and even the people here who use
> it a lot seem to be rather clueless about anything except the simplest
> functionality...
>

yes, but often one gets a crash, and sees the code, variables,
back-trace, ... all at the same time.

in GDB, one only sees the offending/current line, need to type commands
to see the backtrace or values of local variables, ...


so, most often, one gets a crash/..., knows what the problem is in maybe
a few seconds or so, goes and fixes up the code, and runs it again.


>> likewise goes for WinDbg (another graphical debugger from MS, with some
>> interesting features, but generally more of a hassle to launch).
>>
>> the advantage of these graphical debuggers is that one can more often
>> see what is going on much more quickly, as there is often a lot more
>> information on screen at the same time, rather then requiring commands
>> to fetch these details. likewise, many commands are bound to keys, again
>> saving on typing.
>
> Well it's similar to any CLI vs. GUI debate I suppose. The GUI is
> often easier for raw beginners, for intrinsically graphical or spatial
> tasks, but slower and more awkward for complex tasks, or tasks that
> are "language like".
>

realize though that there are also immediate evaluation and
command-entry tabs available, at least in the VS debugger I have (I have
the 'Professional' version given out as part of the whole "MSDN Academic
Alliance" thing, being a college student and all...).


I actually used GDB for the most part first, and more recently switched
over to GUI debuggers (mostly due to having switched over to using MSVC
as the backend compiler on Windows). I still use GDB when debugging on
Linux though.

WinDbg also allows command-based control (it has a small mIRC-like
window for typing commands and reading status messages).

I used WinDbg first, but mostly ended up using VS debugger as it summons
itself when an app crashes, vs WinDbg which has to be launched and
directed to launch an app more manually (and, thus, less conviniently).


generally, I build from the command-line though, as these IDEs offer
more drawbacks than advantages when it comes to non-trivial projects (so
command-line + multiple Windows-Explorer windows, and a pile of open
text editors, are used instead...).


> My general issue with the VS debugger was that very often there would
> be cases where you could _see_ interesting data, but not be able to
> manipulate it, or be able to manipulate it, but only rather awkwardly
> (o-n-e-s-t-e-p-a-t-a-t-i-m-e... argh!) For complex debugging tasks,
> this quickly became absolutely miserable
>
> With gdb, on the other hand, which is largely based on expression
> evaluation, while it was harder to visualize data, manipulation of it
> was vastly faster and easier (and more easily repeatable; often one
> wants to do the weird manipulation several times).
>

fair enough, VS debugger is better for "ok, why did it crash?", but
maybe not so good for exploratory tasks.

K said:
> Please give me the link to download c++ compiler.
>

Krishnakanth:

To download the latest MinGW 4.5.2 C compiler, visit www.whosaway.com,
enter the password: 'HB', then scroll to the bottom of the download table,
and download the .rar file for MinGw 4.5.2

Good Luck !

-Mel

On 08/ 5/11 11:58 PM, Victor Bazarov wrote:
> On 8/5/2011 5:41 AM, Miles Bader wrote:
>> [..]
>> My general issue with the VS debugger was that very often there would
>> be cases where you could _see_ interesting data, but not be able to
>> manipulate it, or be able to manipulate it, but only rather awkwardly
>> (o-n-e-s-t-e-p-a-t-a-t-i-m-e... argh!) For complex debugging tasks,
>> this quickly became absolutely miserable
>>
>> With gdb, on the other hand, which is largely based on expression
>> evaluation, while it was harder to visualize data, manipulation of it
>> was vastly faster and easier (and more easily repeatable; often one
>> wants to do the weird manipulation several times).
>
> In other words, with VC++'s debugger you're actually deBUGging, finding
> out what's wrong, one step at a time, stopping to think, exiting to
> change the code, compile, run again, etc.. With gdb you're actually
> developing by tweaking the data, tweaking the program, altering
> execution, etc.. Yes, no, maybe? It's a style debate, not the quality
> of tools debate.

If you need a debugger, your unit tests aren't good enough!

Dives for cover

--
Ian Collins

On 8/5/2011 2:53 PM, Ian Collins wrote:
> On 08/ 5/11 11:58 PM, Victor Bazarov wrote:
>> On 8/5/2011 5:41 AM, Miles Bader wrote:
>>> [..]
>>> My general issue with the VS debugger was that very often there would
>>> be cases where you could _see_ interesting data, but not be able to
>>> manipulate it, or be able to manipulate it, but only rather awkwardly
>>> (o-n-e-s-t-e-p-a-t-a-t-i-m-e... argh!) For complex debugging tasks,
>>> this quickly became absolutely miserable
>>>
>>> With gdb, on the other hand, which is largely based on expression
>>> evaluation, while it was harder to visualize data, manipulation of it
>>> was vastly faster and easier (and more easily repeatable; often one
>>> wants to do the weird manipulation several times).
>>
>> In other words, with VC++'s debugger you're actually deBUGging, finding
>> out what's wrong, one step at a time, stopping to think, exiting to
>> change the code, compile, run again, etc.. With gdb you're actually
>> developing by tweaking the data, tweaking the program, altering
>> execution, etc.. Yes, no, maybe? It's a style debate, not the quality
>> of tools debate.
>
> If you need a debugger, your unit tests aren't good enough!
>
> Dives for cover
>

unit tests wont help finding out where and why one is experiencing a
segfault or similar...

boom. program crashes. why?... a debugger will help point this out.
most of the time it is due to something having been mistyped or failing
to check for NULL pointers or similar...

unit tests are much better with dealing with non-crash bugs.

On 08/ 6/11 10:10 AM, BGB wrote:
> On 8/5/2011 2:53 PM, Ian Collins wrote:
>> On 08/ 5/11 11:58 PM, Victor Bazarov wrote:
>>> On 8/5/2011 5:41 AM, Miles Bader wrote:
>>>> [..]
>>>> My general issue with the VS debugger was that very often there would
>>>> be cases where you could _see_ interesting data, but not be able to
>>>> manipulate it, or be able to manipulate it, but only rather awkwardly
>>>> (o-n-e-s-t-e-p-a-t-a-t-i-m-e... argh!) For complex debugging tasks,
>>>> this quickly became absolutely miserable
>>>>
>>>> With gdb, on the other hand, which is largely based on expression
>>>> evaluation, while it was harder to visualize data, manipulation of it
>>>> was vastly faster and easier (and more easily repeatable; often one
>>>> wants to do the weird manipulation several times).
>>>
>>> In other words, with VC++'s debugger you're actually deBUGging, finding
>>> out what's wrong, one step at a time, stopping to think, exiting to
>>> change the code, compile, run again, etc.. With gdb you're actually
>>> developing by tweaking the data, tweaking the program, altering
>>> execution, etc.. Yes, no, maybe? It's a style debate, not the quality
>>> of tools debate.
>>
>> If you need a debugger, your unit tests aren't good enough!
>>
>> Dives for cover
>>
>
> unit tests wont help finding out where and why one is experiencing a
> segfault or similar...

If a change causes a crash, back it out and try again...

--
Ian Collins

On 8/5/2011 3:20 PM, Ian Collins wrote:
> On 08/ 6/11 10:10 AM, BGB wrote:
>> On 8/5/2011 2:53 PM, Ian Collins wrote:
>>> On 08/ 5/11 11:58 PM, Victor Bazarov wrote:
>>>> On 8/5/2011 5:41 AM, Miles Bader wrote:
>>>>> [..]
>>>>> My general issue with the VS debugger was that very often there would
>>>>> be cases where you could _see_ interesting data, but not be able to
>>>>> manipulate it, or be able to manipulate it, but only rather awkwardly
>>>>> (o-n-e-s-t-e-p-a-t-a-t-i-m-e... argh!) For complex debugging tasks,
>>>>> this quickly became absolutely miserable
>>>>>
>>>>> With gdb, on the other hand, which is largely based on expression
>>>>> evaluation, while it was harder to visualize data, manipulation of it
>>>>> was vastly faster and easier (and more easily repeatable; often one
>>>>> wants to do the weird manipulation several times).
>>>>
>>>> In other words, with VC++'s debugger you're actually deBUGging, finding
>>>> out what's wrong, one step at a time, stopping to think, exiting to
>>>> change the code, compile, run again, etc.. With gdb you're actually
>>>> developing by tweaking the data, tweaking the program, altering
>>>> execution, etc.. Yes, no, maybe? It's a style debate, not the quality
>>>> of tools debate.
>>>
>>> If you need a debugger, your unit tests aren't good enough!
>>>
>>> Dives for cover
>>>
>>
>> unit tests wont help finding out where and why one is experiencing a
>> segfault or similar...
>
> If a change causes a crash, back it out and try again...
>

or, just invoke the debugger and see why it has crashed...

On 08/ 6/11 01:30 PM, BGB wrote:
> On 8/5/2011 3:20 PM, Ian Collins wrote:
>> On 08/ 6/11 10:10 AM, BGB wrote:
>>> On 8/5/2011 2:53 PM, Ian Collins wrote:
>>>> On 08/ 5/11 11:58 PM, Victor Bazarov wrote:
>>>>> On 8/5/2011 5:41 AM, Miles Bader wrote:
>>>>>> [..]
>>>>>> My general issue with the VS debugger was that very often there would
>>>>>> be cases where you could _see_ interesting data, but not be able to
>>>>>> manipulate it, or be able to manipulate it, but only rather awkwardly
>>>>>> (o-n-e-s-t-e-p-a-t-a-t-i-m-e... argh!) For complex debugging tasks,
>>>>>> this quickly became absolutely miserable
>>>>>>
>>>>>> With gdb, on the other hand, which is largely based on expression
>>>>>> evaluation, while it was harder to visualize data, manipulation of it
>>>>>> was vastly faster and easier (and more easily repeatable; often one
>>>>>> wants to do the weird manipulation several times).
>>>>>
>>>>> In other words, with VC++'s debugger you're actually deBUGging, finding
>>>>> out what's wrong, one step at a time, stopping to think, exiting to
>>>>> change the code, compile, run again, etc.. With gdb you're actually
>>>>> developing by tweaking the data, tweaking the program, altering
>>>>> execution, etc.. Yes, no, maybe? It's a style debate, not the quality
>>>>> of tools debate.
>>>>
>>>> If you need a debugger, your unit tests aren't good enough!
>>>>
>>>> Dives for cover
>>>
>>> unit tests wont help finding out where and why one is experiencing a
>>> segfault or similar...
>>
>> If a change causes a crash, back it out and try again...
>
> or, just invoke the debugger and see why it has crashed...

If that's quicker than redoing the change, you are changing too much
between test runs.

--
Ian Collins

Op 06-Aug-11 5:25, Ian Collins schreef:
> On 08/ 6/11 01:30 PM, BGB wrote:
>> On 8/5/2011 3:20 PM, Ian Collins wrote:
>>> On 08/ 6/11 10:10 AM, BGB wrote:
>>>> On 8/5/2011 2:53 PM, Ian Collins wrote:
>>>>> On 08/ 5/11 11:58 PM, Victor Bazarov wrote:
>>>>>> On 8/5/2011 5:41 AM, Miles Bader wrote:
>>>>>>> [..]
>>>>>>> My general issue with the VS debugger was that very often there
>>>>>>> would
>>>>>>> be cases where you could _see_ interesting data, but not be able to
>>>>>>> manipulate it, or be able to manipulate it, but only rather
>>>>>>> awkwardly
>>>>>>> (o-n-e-s-t-e-p-a-t-a-t-i-m-e... argh!) For complex debugging tasks,
>>>>>>> this quickly became absolutely miserable
>>>>>>>
>>>>>>> With gdb, on the other hand, which is largely based on expression
>>>>>>> evaluation, while it was harder to visualize data, manipulation
>>>>>>> of it
>>>>>>> was vastly faster and easier (and more easily repeatable; often one
>>>>>>> wants to do the weird manipulation several times).
>>>>>>
>>>>>> In other words, with VC++'s debugger you're actually deBUGging,
>>>>>> finding
>>>>>> out what's wrong, one step at a time, stopping to think, exiting to
>>>>>> change the code, compile, run again, etc.. With gdb you're actually
>>>>>> developing by tweaking the data, tweaking the program, altering
>>>>>> execution, etc.. Yes, no, maybe? It's a style debate, not the quality
>>>>>> of tools debate.
>>>>>
>>>>> If you need a debugger, your unit tests aren't good enough!

Unit tests never are. Even when the code coverage is 100% there is still
no guarantee that you have covered all possible execution flows.

>>>>> Dives for cover
>>>>
>>>> unit tests wont help finding out where and why one is experiencing a
>>>> segfault or similar...

Unless you can reproduce the problem with your unit test (extend it if
needed).

>>> If a change causes a crash, back it out and try again...
>>
>> or, just invoke the debugger and see why it has crashed...
>
> If that's quicker than redoing the change, you are changing too much
> between test runs.

Invoking a debugger to see the point where a process has crashed, see
the call stack and see the variables takes less than a second. How many
changes can you make in that time, recompile and running your unit tests?

I love unit tests, but they are not the ultimate solution for every
problem. Sometimes a debugger and more importantly logging and stack
dumps in case things do go wrong can help a lot.

On 08/ 6/11 08:42 PM, Dombo wrote:
> Op 06-Aug-11 5:25, Ian Collins schreef:
>> On 08/ 6/11 01:30 PM, BGB wrote:
>>> On 8/5/2011 3:20 PM, Ian Collins wrote:
>>>> On 08/ 6/11 10:10 AM, BGB wrote:
>>>>> On 8/5/2011 2:53 PM, Ian Collins wrote:
>>>>>> On 08/ 5/11 11:58 PM, Victor Bazarov wrote:
>>>>>>> On 8/5/2011 5:41 AM, Miles Bader wrote:
>>>>>>>> [..]
>>>>>>>> My general issue with the VS debugger was that very often there
>>>>>>>> would
>>>>>>>> be cases where you could _see_ interesting data, but not be able to
>>>>>>>> manipulate it, or be able to manipulate it, but only rather
>>>>>>>> awkwardly
>>>>>>>> (o-n-e-s-t-e-p-a-t-a-t-i-m-e... argh!) For complex debugging tasks,
>>>>>>>> this quickly became absolutely miserable
>>>>>>>>
>>>>>>>> With gdb, on the other hand, which is largely based on expression
>>>>>>>> evaluation, while it was harder to visualize data, manipulation
>>>>>>>> of it
>>>>>>>> was vastly faster and easier (and more easily repeatable; often one
>>>>>>>> wants to do the weird manipulation several times).
>>>>>>>
>>>>>>> In other words, with VC++'s debugger you're actually deBUGging,
>>>>>>> finding
>>>>>>> out what's wrong, one step at a time, stopping to think, exiting to
>>>>>>> change the code, compile, run again, etc.. With gdb you're actually
>>>>>>> developing by tweaking the data, tweaking the program, altering
>>>>>>> execution, etc.. Yes, no, maybe? It's a style debate, not the quality
>>>>>>> of tools debate.
>>>>>>
>>>>>> If you need a debugger, your unit tests aren't good enough!
>
> Unit tests never are. Even when the code coverage is 100% there is still
> no guarantee that you have covered all possible execution flows.

There should be if you wrote the tests first.

>>>>>> Dives for cover
>>>>>
>>>>> unit tests wont help finding out where and why one is experiencing a
>>>>> segfault or similar...
>
> Unless you can reproduce the problem with your unit test (extend it if
> needed).
>
>>>> If a change causes a crash, back it out and try again...
>>>
>>> or, just invoke the debugger and see why it has crashed...
>>
>> If that's quicker than redoing the change, you are changing too much
>> between test runs.
>
> Invoking a debugger to see the point where a process has crashed, see
> the call stack and see the variables takes less than a second. How many
> changes can you make in that time, recompile and running your unit tests?

That all depends whether the platform (and language) you are using has a
decent debugger.

--
Ian Collins

Op 06-Aug-11 11:42, Ian Collins schreef:
> On 08/ 6/11 08:42 PM, Dombo wrote:
>> Op 06-Aug-11 5:25, Ian Collins schreef:
>>> On 08/ 6/11 01:30 PM, BGB wrote:
>>>> On 8/5/2011 3:20 PM, Ian Collins wrote:
>>>>> On 08/ 6/11 10:10 AM, BGB wrote:
>>>>>> On 8/5/2011 2:53 PM, Ian Collins wrote:
>>>>>>> On 08/ 5/11 11:58 PM, Victor Bazarov wrote:
>>>>>>>> On 8/5/2011 5:41 AM, Miles Bader wrote:
>>>>>>>>> [..]
>>>>>>>>> My general issue with the VS debugger was that very often there
>>>>>>>>> would
>>>>>>>>> be cases where you could _see_ interesting data, but not be
>>>>>>>>> able to
>>>>>>>>> manipulate it, or be able to manipulate it, but only rather
>>>>>>>>> awkwardly
>>>>>>>>> (o-n-e-s-t-e-p-a-t-a-t-i-m-e... argh!) For complex debugging
>>>>>>>>> tasks,
>>>>>>>>> this quickly became absolutely miserable
>>>>>>>>>
>>>>>>>>> With gdb, on the other hand, which is largely based on expression
>>>>>>>>> evaluation, while it was harder to visualize data, manipulation
>>>>>>>>> of it
>>>>>>>>> was vastly faster and easier (and more easily repeatable; often
>>>>>>>>> one
>>>>>>>>> wants to do the weird manipulation several times).
>>>>>>>>
>>>>>>>> In other words, with VC++'s debugger you're actually deBUGging,
>>>>>>>> finding
>>>>>>>> out what's wrong, one step at a time, stopping to think, exiting to
>>>>>>>> change the code, compile, run again, etc.. With gdb you're actually
>>>>>>>> developing by tweaking the data, tweaking the program, altering
>>>>>>>> execution, etc.. Yes, no, maybe? It's a style debate, not the
>>>>>>>> quality
>>>>>>>> of tools debate.
>>>>>>>
>>>>>>> If you need a debugger, your unit tests aren't good enough!
>>
>> Unit tests never are. Even when the code coverage is 100% there is still
>> no guarantee that you have covered all possible execution flows.
>
> There should be if you wrote the tests first.

If you believe that than those tests give you a false sense of security.
If you write the test first (as I do) you still have no guarantee it
covers every possible scenario (even when the code coverage is 100%).
Usually code fails on scenarios that weren't anticipated, rather than
the scenario's that were anticipated (and tested). As long as tests (and
specifications for that matter) are created by humans chances are that
they are flawed as well.

>>>>>>> Dives for cover
>>>>>>
>>>>>> unit tests wont help finding out where and why one is experiencing a
>>>>>> segfault or similar...
>>
>> Unless you can reproduce the problem with your unit test (extend it if
>> needed).
>>
>>>>> If a change causes a crash, back it out and try again...
>>>>
>>>> or, just invoke the debugger and see why it has crashed...
>>>
>>> If that's quicker than redoing the change, you are changing too much
>>> between test runs.
>>
>> Invoking a debugger to see the point where a process has crashed, see
>> the call stack and see the variables takes less than a second. How many
>> changes can you make in that time, recompile and running your unit tests?
>
> That all depends whether the platform (and language) you are using has a
> decent debugger.

If it doesn't I consider that a handicap, no matter how good the unit
tests are. Sometimes things you depend on just don't work as advertised,
a decent debugger can help analyzing what is really going a lot.
Debuggers don't make unit tests obsolete, nor vise versa.