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

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

c++ compiler

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

Contents

  c++ compiler krishnakanth <kmanivan82@gmail.com> - 2011-08-03 13:34 -0700
    Re: c++ compiler Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-03 17:11 -0400
      Re: c++ compiler "Waldek M." <wm@localhost.localdomain> - 2011-08-04 21:40 +0200
        Re: c++ compiler BGB <cr88192@hotmail.com> - 2011-08-04 15:06 -0700
        Re: c++ compiler Qi <no@no.no> - 2011-08-05 10:14 +0800
          Re: c++ compiler Miles Bader <miles@gnu.org> - 2011-08-05 15:02 +0900
            Re: c++ compiler BGB <cr88192@hotmail.com> - 2011-08-05 02:11 -0700
              Re: c++ compiler Miles Bader <miles@gnu.org> - 2011-08-05 18:41 +0900
                Re: c++ compiler Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-05 07:58 -0400
                  Re: c++ compiler "Waldek M." <wm@localhost.localdomain> - 2011-08-05 21:30 +0200
                  Re: c++ compiler Ian Collins <ian-news@hotmail.com> - 2011-08-06 09:53 +1200
                    Re: c++ compiler BGB <cr88192@hotmail.com> - 2011-08-05 15:10 -0700
                      Re: c++ compiler Ian Collins <ian-news@hotmail.com> - 2011-08-06 10:20 +1200
                        Re: c++ compiler BGB <cr88192@hotmail.com> - 2011-08-05 18:30 -0700
                          Re: c++ compiler Ian Collins <ian-news@hotmail.com> - 2011-08-06 15:25 +1200
                            Re: c++ compiler Dombo <dombo@disposable.invalid> - 2011-08-06 10:42 +0200
                              Re: c++ compiler Ian Collins <ian-news@hotmail.com> - 2011-08-06 21:42 +1200
                                Re: c++ compiler Dombo <dombo@disposable.invalid> - 2011-08-06 15:38 +0200
                                  Re: c++ compiler BGB <cr88192@hotmail.com> - 2011-08-06 11:58 -0700
                                    Re: c++ compiler yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-08-09 13:28 +0000
                                  Re: c++ compiler Ian Collins <ian-news@hotmail.com> - 2011-08-07 08:33 +1200
                Re: c++ compiler BGB <cr88192@hotmail.com> - 2011-08-05 12:34 -0700
    Re: c++ compiler "Mel Smith" <med_cutout_syntel@aol.com> - 2011-08-05 15:13 -0600

Page 1 of 2  [1] 2  Next page →

#8441 — c++ compiler

Hi,

This is Krishnakanth working as a software engineer. I am interested
in learning c++. I am searching for a c++ compiler. I have downloaded
some of the c++ cmpiler TC++, also borland c++ 5.5. It is not working
in my machine.

Below is my laptop configuration.
core i3 processor
3GB RAM
windows 7 home edition

Please give me the link to download c++ compiler.


Krishnakanth

[toc] | [next] | [standalone]

#8442

On 8/3/2011 4:34 PM, krishnakanth wrote:
> This is Krishnakanth working as a software engineer. I am interested
> in learning c++. I am searching for a c++ compiler. I have downloaded
> some of the c++ cmpiler TC++, also borland c++ 5.5. It is not working
> in my machine.
>
> Below is my laptop configuration.
> core i3 processor
> 3GB RAM
> windows 7 home edition
>
> Please give me the link to download c++ compiler.

Look for "Express Edition" of Microsoft Visual C++. www.microsoft.com

V
-- 
I do not respond to top-posted replies, please don't ask

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

#8474

Dnia Wed, 03 Aug 2011 17:11:12 -0400, Victor Bazarov napisał(a):
>> Please give me the link to download c++ compiler.
> 
> Look for "Express Edition" of Microsoft Visual C++. www.microsoft.com

Or to Mingw (Windows port of GCC): www.mingw.org

MS VC++ is more "kosher" on Windows and some say - better for
Windows-specific, while MinGW might be useful if you've had any Unix/Linux
axperience and you like it.

Best regards,
Waldek

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

#8480

On 8/4/2011 12:40 PM, Waldek M. wrote:
> Dnia Wed, 03 Aug 2011 17:11:12 -0400, Victor Bazarov napisał(a):
>>> Please give me the link to download c++ compiler.
>>
>> Look for "Express Edition" of Microsoft Visual C++. www.microsoft.com
>
> Or to Mingw (Windows port of GCC): www.mingw.org
>
> MS VC++ is more "kosher" on Windows and some say - better for
> Windows-specific, while MinGW might be useful if you've had any Unix/Linux
> axperience and you like it.
>

I am using mostly a mashup of MSVC via the Windows SDK, and some of the 
GNU tools from Cygwin (mostly "make" and similar).

MinGW is also good, and there are good and bad points either way.

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

#8483

On 2011-8-5 3:40, Waldek M. wrote:
>
> Or to Mingw (Windows port of GCC): www.mingw.org
>
> MS VC++ is more "kosher" on Windows and some say - better for
> Windows-specific, while MinGW might be useful if you've had any Unix/Linux
> axperience and you like it.

The debugger in VC is unbeatable.
And its IDE is also awesome.

For me the biggest problem is that VC is not quite standard
compliant.

So I also use MingW gcc to check standard issue. :-)


-- 
WQ

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

#8484

Qi <no@no.no> writes:
> The debugger in VC is unbeatable.
> And its IDE is also awesome.

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...

-Miles


-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

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

#8486

On 8/4/2011 11:02 PM, Miles Bader wrote:
> Qi<no@no.no>  writes:
>> The debugger in VC is unbeatable.
>> And its IDE is also awesome.
>
> 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.

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.

granted, I guess there are graphical frontends to GDB, but I haven't 
tried them personally.

profilers are a different matter though, as I prefer the information I 
get out of gprof over what I can get from graphical profilers such as 
CodeAnalyst, but it has its own merits as well, such as the ability to 
know where time is going in terms of various system libraries, which can 
also be useful, ...


much more relevant though is that in both cases, the choice of tools is 
largely driven by the choice of compiler (as neither set of tools 
understands the others' debug info).

or such...

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

#8489

BGB <cr88192@hotmail.com> 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...

> 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".

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).

-Miles

-- 
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.

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

#8491

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.

V
-- 
I do not respond to top-posted replies, please don't ask

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

#8493

On Fri, 05 Aug 2011 07:58:34 -0400, Victor Bazarov wrote:
> 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.

Well, since I've started this off-topic... :-)

I love gdb on Linux. If I need GUI for it, I'll always find
one. I don't use VC's debugger - but what I heard from my colleagues
is all good. But I must say, I'm not always happy with gdb on Windows.

It's fine, all right. But I can't really rely on it while debugging
anything built with VC. Moreover, gdb uses concepts that
make great sense on Unix (like pid and attaching to it)
but not so much on Windows.
So while I strongly prefer gdb - and not for altering the 
code flow, but just for simple debugging tasks like breakpoints,
watches, running some commands on watches' hit, inspecting backtraces
 - I definitely understand why my admiration is rare ;-)

Best regards,
Waldek

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

#8497

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

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

#8498

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.

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

#8499

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

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

#8500

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...

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

#8501

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

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

#8503

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.

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

#8504

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

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

#8505

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.

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

#8508

On 8/6/2011 6:38 AM, Dombo wrote:
> 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.
>

yep.

unit tests are good at testing that the thing does what it is defined as 
doing, so one can write out a basic spec, and tests to make sure that 
behavior is what it is supposed to be (most often, some things are 
harder to run automated tests on than others).

debuggers are better at finding random errors and edge cases which may 
not have been adequately tested for, or which may fall outside the scope 
of its defined behavior, for example:
what happens when the API is called prior to initialization?
what happens if the API's Init functions are called during operation or 
multiple times?
what happens if NULL is passed in unexpected places?
...

these things are not normally tested in unit tests, which typically 
handle defined behavior and use, and not anomalous behavior and 
use-patterns (for which there may be far more anomalous patterns to test 
for than to test for defined behavior, but programming errors are often 
much better at stepping on these edge cases).

or such...

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

#8590

In article <j1k35l$uhv$1@news.albasani.net>, BGB  <cr88192@hotmail.com> wrote:
>
>yep.
>
>unit tests are good at testing that the thing does what it is defined as 
>doing, so one can write out a basic spec, and tests to make sure that 
>behavior is what it is supposed to be (most often, some things are 
>harder to run automated tests on than others).
>
>debuggers are better at finding random errors and edge cases which may 
>not have been adequately tested for, or which may fall outside the scope 
>of its defined behavior, for example:
>what happens when the API is called prior to initialization?
>what happens if the API's Init functions are called during operation or 
>multiple times?
>what happens if NULL is passed in unexpected places?
>...
>
>these things are not normally tested in unit tests, which typically 
>handle defined behavior and use, and not anomalous behavior and 
>use-patterns (for which there may be far more anomalous patterns to test 
>for than to test for defined behavior, but programming errors are often 
>much better at stepping on these edge cases).

Wow!  Ian was a bit tongue-in-cheek with his unit test comments but
you are way off the mark.  Unit tests are absolutely not meant to only
cover normal execution path.  In fact, you will never reach high code
coverage stats if you only unit test the normal success path.  The
proportion of code that exist to handle error is huge.  If you write
it, test it.

You should have a unit test for calling the API prior to
initialisation (assuming your API requires initialisation)
You should have unit tests to verify that calling init more that
once. 
If your interface takes pointers, you should test what happens with
NULL pointers. 
Etc. 

You probably never reach 100% coverage but really, at least try to
cover the basic failure scenarios you listed above. Plus you should
run your unit test in a memory analyser so that leaks and boundary
violation are detected.   

That said, I have nothing against debuggers.  I've even been know to
run through some unit tests in a debuggers :-)

Yannick

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web