c++ compiler

[krishnakanth]

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

 

[Victor Bazarov]

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

 

[Waldek M.]

Dnia Wed, 03 Aug 2011 17:11:12 -0400, Victor Bazarov napisa³(a):

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

 

[BGB]

Dnia Wed, 03 Aug 2011 17:11:12 -0400, Victor Bazarov napisa³(a):

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.

 

[Qi]

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.

 

[Miles Bader]

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

 

[BGB]

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

 

[Miles Bader]

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

 

[Victor Bazarov]

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

 

[Waldek M.]

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

 

[BGB]

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.

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.

 

[Mel Smith]

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

 

[Ian Collins]

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

 

[BGB]

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

 

[Ian Collins]

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

 

[BGB]

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

 

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

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.

 

[Dombo]

Op 06-Aug-11 5:25, Ian Collins schreef:

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.

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

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.

 

[Ian Collins]

Op 06-Aug-11 5:25, Ian Collins schreef:

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.

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


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.

 

[Dombo]

Op 06-Aug-11 11:42, Ian Collins schreef:

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.

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.