c++ compiler

Discussion in 'C++' started by krishnakanth, Aug 3, 2011.

  1. krishnakanth

    krishnakanth Guest

    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
     
    krishnakanth, Aug 3, 2011
    #1
    1. Advertising

  2. 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
     
    Victor Bazarov, Aug 3, 2011
    #2
    1. Advertising

  3. krishnakanth

    Waldek M. Guest

    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
     
    Waldek M., Aug 4, 2011
    #3
  4. krishnakanth

    BGB Guest

    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.
     
    BGB, Aug 4, 2011
    #4
  5. krishnakanth

    Qi Guest

    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
     
    Qi, Aug 5, 2011
    #5
  6. krishnakanth

    Miles Bader Guest

    Qi <> 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]
     
    Miles Bader, Aug 5, 2011
    #6
  7. krishnakanth

    BGB Guest

    On 8/4/2011 11:02 PM, Miles Bader wrote:
    > Qi<> 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...
     
    BGB, Aug 5, 2011
    #7
  8. krishnakanth

    Miles Bader Guest

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

    > 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.
     
    Miles Bader, Aug 5, 2011
    #8
  9. 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
     
    Victor Bazarov, Aug 5, 2011
    #9
  10. krishnakanth

    Waldek M. Guest

    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
     
    Waldek M., Aug 5, 2011
    #10
  11. krishnakanth

    BGB Guest

    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.
     
    BGB, Aug 5, 2011
    #11
  12. krishnakanth

    Mel Smith Guest

    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
     
    Mel Smith, Aug 5, 2011
    #12
  13. krishnakanth

    Ian Collins Guest

    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
     
    Ian Collins, Aug 5, 2011
    #13
  14. krishnakanth

    BGB Guest

    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.
     
    BGB, Aug 5, 2011
    #14
  15. krishnakanth

    Ian Collins Guest

    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
     
    Ian Collins, Aug 5, 2011
    #15
  16. krishnakanth

    BGB Guest

    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...
     
    BGB, Aug 6, 2011
    #16
  17. krishnakanth

    Ian Collins Guest

    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
     
    Ian Collins, Aug 6, 2011
    #17
  18. krishnakanth

    Dombo Guest

    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.
     
    Dombo, Aug 6, 2011
    #18
  19. krishnakanth

    Ian Collins Guest

    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
     
    Ian Collins, Aug 6, 2011
    #19
  20. krishnakanth

    Dombo Guest

    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.
     
    Dombo, Aug 6, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Yan
    Replies:
    0
    Views:
    1,138
  2. Jack Wright
    Replies:
    5
    Views:
    627
    Shiv Kumar
    Jan 19, 2004
  3. Ram
    Replies:
    0
    Views:
    2,846
  4. Andrey Batyuck

    Compiler compiler with C++ as output

    Andrey Batyuck, May 11, 2004, in forum: C++
    Replies:
    3
    Views:
    440
    Frederik Hertzum
    May 17, 2004
  5. RickMuller
    Replies:
    4
    Views:
    708
    Alexey Shamrin
    Mar 26, 2005
Loading...

Share This Page