c++ interpreter

[hanch]

Hi,

I'm looking for a comfortable IDE for c++ with c++ interpreter, so i'd
be able to execute c scripts and alter code during debug.
thnks

[Pete]

hanch wrote:

Hi,

I'm looking for a comfortable IDE for c++ with c++ interpreter, so i'd
be able to execute c scripts and alter code during debug.
thnks

It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard is a
great IDE, plus it lets you edit while debugging.

- Pete

[Pete]

hanch wrote:

Hi,

I'm looking for a comfortable IDE for c++ with c++ interpreter, so i'd
be able to execute c scripts and alter code during debug.
thnks

It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard is a
great IDE, plus it lets you edit while debugging.

- Pete

[Phlip]

Pete wrote:

hanch wrote:

I'm looking for a comfortable IDE for c++ with c++ interpreter, so i'd
be able to execute c scripts and alter code during debug.

It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard is a
great IDE, plus it lets you edit while debugging.

Editing while debugging is a bad habit because you have less incentive to
decouple.

If I write a function that only gets called by other methods in delicate
states, I must execute a program, step thru it, get to that function in that
state, and debug it. The ability to change code while debugging is now a fix
for a symptom, not a cure.

If, by contrast, my function is decoupled, and I can call it from a test
rig, then for each little change I would want to run the tests again.
Changing the code while under test could obscure problems.

So debugging less, and writing more test rigs, encourages decoupling which
boosts velocity.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Phlip]

Pete wrote:

hanch wrote:

I'm looking for a comfortable IDE for c++ with c++ interpreter, so i'd
be able to execute c scripts and alter code during debug.

It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard is a
great IDE, plus it lets you edit while debugging.

Editing while debugging is a bad habit because you have less incentive to
decouple.

If I write a function that only gets called by other methods in delicate
states, I must execute a program, step thru it, get to that function in that
state, and debug it. The ability to change code while debugging is now a fix
for a symptom, not a cure.

If, by contrast, my function is decoupled, and I can call it from a test
rig, then for each little change I would want to run the tests again.
Changing the code while under test could obscure problems.

So debugging less, and writing more test rigs, encourages decoupling which
boosts velocity.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Pete]

Phlip wrote:

Pete wrote:

hanch wrote:

I'm looking for a comfortable IDE for c++ with c++ interpreter, so
i'd be able to execute c scripts and alter code during debug.

It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard
is a great IDE, plus it lets you edit while debugging.

Editing while debugging is a bad habit because you have less
incentive to decouple.

If I write a function that only gets called by other methods in
delicate states, I must execute a program, step thru it, get to that
function in that state, and debug it. The ability to change code
while debugging is now a fix for a symptom, not a cure.

If, by contrast, my function is decoupled, and I can call it from a
test rig, then for each little change I would want to run the tests
again. Changing the code while under test could obscure problems.

So debugging less, and writing more test rigs, encourages decoupling
which boosts velocity.

I agree, but he asked for an IDE with that capability, not for (good) advice
on how to program well. ;)
Besides, VC++2003 is a great IDE + compiler, anyway.

- Pete

[Pete]

Phlip wrote:

Pete wrote:

hanch wrote:

I'm looking for a comfortable IDE for c++ with c++ interpreter, so
i'd be able to execute c scripts and alter code during debug.

It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard
is a great IDE, plus it lets you edit while debugging.

Editing while debugging is a bad habit because you have less
incentive to decouple.

If I write a function that only gets called by other methods in
delicate states, I must execute a program, step thru it, get to that
function in that state, and debug it. The ability to change code
while debugging is now a fix for a symptom, not a cure.

If, by contrast, my function is decoupled, and I can call it from a
test rig, then for each little change I would want to run the tests
again. Changing the code while under test could obscure problems.

So debugging less, and writing more test rigs, encourages decoupling
which boosts velocity.

I agree, but he asked for an IDE with that capability, not for (good) advice
on how to program well. ;)
Besides, VC++2003 is a great IDE + compiler, anyway.

- Pete

[Julie]

Phlip wrote:

Pete wrote:

hanch wrote:

I'm looking for a comfortable IDE for c++ with c++ interpreter, so i'd
be able to execute c scripts and alter code during debug.

It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard is a
great IDE, plus it lets you edit while debugging.

Editing while debugging is a bad habit because you have less incentive to
decouple.

Wrong. Not decoupling when appropriate is a 'bad habit'. Editing while
debugging is a _feature_.

[Julie]

Phlip wrote:

Pete wrote:

hanch wrote:

I'm looking for a comfortable IDE for c++ with c++ interpreter, so i'd
be able to execute c scripts and alter code during debug.

It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard is a
great IDE, plus it lets you edit while debugging.

Editing while debugging is a bad habit because you have less incentive to
decouple.

Wrong. Not decoupling when appropriate is a 'bad habit'. Editing while
debugging is a _feature_.

[Steven T. Hatton]

Julie wrote:

Wrong. Not decoupling when appropriate is a 'bad habit'.
Editing while debugging is a _feature_.

I have that option with some tools I use with that other language. In
general, I consider editing while debugging to be a form of insanity. ;-)
It may have it's place, but as a general rule, it just never made sense to
me. I find the problem, stop the debugger, and take a clean look at it.

But with syntax checking in the editor, I really don't have that many
runtime bugs.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[Steven T. Hatton]

Julie wrote:

Wrong. Not decoupling when appropriate is a 'bad habit'.
Editing while debugging is a _feature_.

I have that option with some tools I use with that other language. In
general, I consider editing while debugging to be a form of insanity. ;-)
It may have it's place, but as a general rule, it just never made sense to
me. I find the problem, stop the debugger, and take a clean look at it.

But with syntax checking in the editor, I really don't have that many
runtime bugs.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[Julie]

"Steven T. Hatton" wrote:

Julie wrote:

Wrong. Not decoupling when appropriate is a 'bad habit'.
Editing while debugging is a _feature_.
I have that option with some tools I use with that other language. In
general, I consider editing while debugging to be a form of insanity. ;-)
It may have it's place, but as a general rule, it just never made sense to
me. I find the problem, stop the debugger, and take a clean look at it.

Part of my job is fixing bugs (in mostly legacy code).

It is invaluable to be able to finally locate a bug, fix it, re-step over it
and verify the results in one pass. In some test cases, the setup to the bug
is 10s of minutes and/or numerous steps and configurations. Edit and continue
is invaluable in this case.

There are other beneficial cases as well. I was just trying to point out to
the prior respondent that his statement was incorrect.

Let's not get into the mindset that just because someone don't use a feature,
that it has no value.
But with syntax checking in the editor, I really don't have that many
runtime bugs.

??? Syntax checking has absolutely nothing to do w/ runtime bugs. Regardless
of the editor features, a syntax error will be caught during the compile, and
unless your compiler builds an executable w/ errors, there is no runtime bug.

[Julie]

"Steven T. Hatton" wrote:

Julie wrote:

Wrong. Not decoupling when appropriate is a 'bad habit'.
Editing while debugging is a _feature_.
I have that option with some tools I use with that other language. In
general, I consider editing while debugging to be a form of insanity. ;-)
It may have it's place, but as a general rule, it just never made sense to
me. I find the problem, stop the debugger, and take a clean look at it.

Part of my job is fixing bugs (in mostly legacy code).

It is invaluable to be able to finally locate a bug, fix it, re-step over it
and verify the results in one pass. In some test cases, the setup to the bug
is 10s of minutes and/or numerous steps and configurations. Edit and continue
is invaluable in this case.

There are other beneficial cases as well. I was just trying to point out to
the prior respondent that his statement was incorrect.

Let's not get into the mindset that just because someone don't use a feature,
that it has no value.
But with syntax checking in the editor, I really don't have that many
runtime bugs.

??? Syntax checking has absolutely nothing to do w/ runtime bugs. Regardless
of the editor features, a syntax error will be caught during the compile, and
unless your compiler builds an executable w/ errors, there is no runtime bug.

[Steven T. Hatton]

Julie wrote:

"Steven T. Hatton" wrote:

I have that option with some tools I use with that other language. In
general, I consider editing while debugging to be a form of insanity. ;-)
It may have it's place, but as a general rule, it just never made sense
to me. I find the problem, stop the debugger, and take a clean look at
it.

Part of my job is fixing bugs (in mostly legacy code).

It is invaluable to be able to finally locate a bug, fix it, re-step over
it
and verify the results in one pass. In some test cases, the setup to the
bug
is 10s of minutes and/or numerous steps and configurations. Edit and
continue is invaluable in this case.

There are other beneficial cases as well. I was just trying to point out
to the prior respondent that his statement was incorrect.

Let's not get into the mindset that just because someone don't use a
feature, that it has no value.

But with syntax checking in the editor, I really don't have that many
runtime bugs.

??? Syntax checking has absolutely nothing to do w/ runtime bugs.
Regardless of the editor features, a syntax error will be caught during
the compile, and unless your compiler builds an executable w/ errors,
there is no runtime bug.

I'd have to think about all the checks it actually does. Maybe it's checked
exceptions that keep me out of trouble. They are checked at edit time, and
I typically add pretty good dump info. I know people don't like the
suggestion of adding that to C++, but It sure is handy. If managed well,
it doesn't have to be too ugly.

I can see your point about having to iterate several times to hit a bug.
There /are/ ways to deal with such situations by telling the debugger to
skip a break point several times, but I am not skilled in using them. They
may well be more work than they would save.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[Steven T. Hatton]

Julie wrote:

"Steven T. Hatton" wrote:

I have that option with some tools I use with that other language. In
general, I consider editing while debugging to be a form of insanity. ;-)
It may have it's place, but as a general rule, it just never made sense
to me. I find the problem, stop the debugger, and take a clean look at
it.

Part of my job is fixing bugs (in mostly legacy code).

It is invaluable to be able to finally locate a bug, fix it, re-step over
it
and verify the results in one pass. In some test cases, the setup to the
bug
is 10s of minutes and/or numerous steps and configurations. Edit and
continue is invaluable in this case.

There are other beneficial cases as well. I was just trying to point out
to the prior respondent that his statement was incorrect.

Let's not get into the mindset that just because someone don't use a
feature, that it has no value.

But with syntax checking in the editor, I really don't have that many
runtime bugs.

??? Syntax checking has absolutely nothing to do w/ runtime bugs.
Regardless of the editor features, a syntax error will be caught during
the compile, and unless your compiler builds an executable w/ errors,
there is no runtime bug.

I'd have to think about all the checks it actually does. Maybe it's checked
exceptions that keep me out of trouble. They are checked at edit time, and
I typically add pretty good dump info. I know people don't like the
suggestion of adding that to C++, but It sure is handy. If managed well,
it doesn't have to be too ugly.

I can see your point about having to iterate several times to hit a bug.
There /are/ ways to deal with such situations by telling the debugger to
skip a break point several times, but I am not skilled in using them. They
may well be more work than they would save.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[bartek]

ha********@yahoo.com (hanch) wrote in news:20308ed3.0404040859.73633fd2
@posting.google.com:

I'm looking for a comfortable IDE for c++ with c++ interpreter, so i'd
be able to execute c scripts and alter code during debug.

There actually exists a C++ interpreter. It's not fully standard-compliant,
but nonethless quite an interesting beast.

http://root.cern.ch/root/Cint.html

Quoting the author "CINT covers about 95% of ANSI C and 85% of C++. CINT,
written in ANSI C (about 80000 loc), is solid enough to interpret itself
and let the interpreted version execute a program".

Cheers.

[bartek]

ha********@yahoo.com (hanch) wrote in news:20308ed3.0404040859.73633fd2
@posting.google.com:

I'm looking for a comfortable IDE for c++ with c++ interpreter, so i'd
be able to execute c scripts and alter code during debug.

There actually exists a C++ interpreter. It's not fully standard-compliant,
but nonethless quite an interesting beast.

http://root.cern.ch/root/Cint.html

Quoting the author "CINT covers about 95% of ANSI C and 85% of C++. CINT,
written in ANSI C (about 80000 loc), is solid enough to interpret itself
and let the interpreted version execute a program".

Cheers.

[Phlip]

Julie wrote:

Phlip wrote:

Editing while debugging is a bad habit because you have less incentive to
decouple.

Wrong. Not decoupling when appropriate is a 'bad habit'. Editing while
debugging is a _feature_.

I didn't say it wasn't a feature. I said it was an incentive.
Part of my job is fixing bugs (in mostly legacy code).

It is invaluable to be able to finally
locate a bug, fix it, re-step over it
and verify the results in one pass.
In some test cases, the setup to the bug
is 10s of minutes and/or numerous steps
and configurations. Edit and continue
is invaluable in this case.
Given a choice of two legacy projects, would you prefer the one
written with many tests? or the one written in a language that
supported edit-and-continue?

To put this another way, would you prefer the slobs^W
winning-challenged engineers who wrote the legacy code to use tests,
or advanced debugging? If they had edit-and-continue, they had less
incentive to decouple.

As I said, "The ability to change code while debugging is now a fix
for a symptom, not a cure." You describe the need for more fix.

Naturally, one can't usually pick and choose legacy maintenance
projects. So, fix away!
There are other beneficial cases as well.
I was just trying to point out to
the prior respondent that his statement
was incorrect.
Wrong.
Let's not get into the mindset that just because
someone don't use a feature,
that it has no value.

Over the past 20 years, compiler vendors have spent millions of their
dollars improving their debuggers. If they had, instead, spent a
similar amount of effort on automated test suites, then all our
editors would have at least these features:

- Automatically Execute tests on Save
- Automatically Execute tests "all the time"
- Easy rollback to the last green-bar
- Color-code code based on test status
- Automatically create test rig with production code
- Quick-link between test code and corresponding
production code and back again
- Easy to browse tree of Test suites/cases/methods
- Color code stack traces to seperate test-rig from
production code
- Quick/more-automatic integration
- Integration runs tests.
- If post-integration test fail, rollback automatically.
- Identify what code lines are covered by what tests
- Cross Language Test Suites

That kind of ease-of-use would flatten the odds of long protracted bug
hunts - the kind edit-and-continue enables.

But with syntax checking in the editor, I really don't have that many
runtime bugs.

??? Syntax checking has absolutely nothing to do w/ runtime bugs. Regardless
of the editor features, a syntax error will be caught during the compile, and
unless your compiler builds an executable w/ errors, there is no runtime bug.

Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

[Phlip]

Julie wrote:

Phlip wrote:

Editing while debugging is a bad habit because you have less incentive to
decouple.

Wrong. Not decoupling when appropriate is a 'bad habit'. Editing while
debugging is a _feature_.

I didn't say it wasn't a feature. I said it was an incentive.
Part of my job is fixing bugs (in mostly legacy code).

It is invaluable to be able to finally
locate a bug, fix it, re-step over it
and verify the results in one pass.
In some test cases, the setup to the bug
is 10s of minutes and/or numerous steps
and configurations. Edit and continue
is invaluable in this case.
Given a choice of two legacy projects, would you prefer the one
written with many tests? or the one written in a language that
supported edit-and-continue?

To put this another way, would you prefer the slobs^W
winning-challenged engineers who wrote the legacy code to use tests,
or advanced debugging? If they had edit-and-continue, they had less
incentive to decouple.

As I said, "The ability to change code while debugging is now a fix
for a symptom, not a cure." You describe the need for more fix.

Naturally, one can't usually pick and choose legacy maintenance
projects. So, fix away!
There are other beneficial cases as well.
I was just trying to point out to
the prior respondent that his statement
was incorrect.
Wrong.
Let's not get into the mindset that just because
someone don't use a feature,
that it has no value.

Over the past 20 years, compiler vendors have spent millions of their
dollars improving their debuggers. If they had, instead, spent a
similar amount of effort on automated test suites, then all our
editors would have at least these features:

- Automatically Execute tests on Save
- Automatically Execute tests "all the time"
- Easy rollback to the last green-bar
- Color-code code based on test status
- Automatically create test rig with production code
- Quick-link between test code and corresponding
production code and back again
- Easy to browse tree of Test suites/cases/methods
- Color code stack traces to seperate test-rig from
production code
- Quick/more-automatic integration
- Integration runs tests.
- If post-integration test fail, rollback automatically.
- Identify what code lines are covered by what tests
- Cross Language Test Suites

That kind of ease-of-use would flatten the odds of long protracted bug
hunts - the kind edit-and-continue enables.

But with syntax checking in the editor, I really don't have that many
runtime bugs.

??? Syntax checking has absolutely nothing to do w/ runtime bugs. Regardless
of the editor features, a syntax error will be caught during the compile, and
unless your compiler builds an executable w/ errors, there is no runtime bug.

Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

[Julie]

Phlip wrote:
<big snip>

You didn't add anything of value to the conversation -- just rehashed what you
already think.

[Julie]

Phlip wrote:
<big snip>

You didn't add anything of value to the conversation -- just rehashed what you
already think.

[Buster]

Phlip wrote:

Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

What language has stronger static type checking than C++?

--
Regards,
Buster.

[Buster]

Phlip wrote:

Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

What language has stronger static type checking than C++?

--
Regards,
Buster.

[Buster]

Julie wrote:

Phlip wrote:
<big snip>

You didn't add anything of value to the conversation -- just rehashed what you
already think.

Suggested comeback: no _you_ shut up!

--
Regards,
Buster.

[Buster]

Julie wrote:

Phlip wrote:
<big snip>

You didn't add anything of value to the conversation -- just rehashed what you
already think.

Suggested comeback: no _you_ shut up!

--
Regards,
Buster.

[tom_usenet]

On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <x@x.x> wrote:

Besides, VC++2003 is a great IDE + compiler, anyway.

The compiler is fine, but the IDE is not. I've never found a good C++
ide - good ones for other languages (such as Java - IntelliJ and
Eclipse) are common.

C++'s TU-based rather than module-based approach (not to mention other
features of the preprocessor) makes it almost impossible to write what
I would consider a good IDE for C++.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[tom_usenet]

On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <x@x.x> wrote:

Besides, VC++2003 is a great IDE + compiler, anyway.

The compiler is fine, but the IDE is not. I've never found a good C++
ide - good ones for other languages (such as Java - IntelliJ and
Eclipse) are common.

C++'s TU-based rather than module-based approach (not to mention other
features of the preprocessor) makes it almost impossible to write what
I would consider a good IDE for C++.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[tom_usenet]

On Mon, 05 Apr 2004 13:57:14 +0100, Buster <no***@nowhere.com> wrote:

Phlip wrote:

Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

What language has stronger static type checking than C++?

Java for one. C++ allows some ridiculous implicit conversions (such as
double->char) in the interests of backwards compatibility with C.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[tom_usenet]

On Mon, 05 Apr 2004 13:57:14 +0100, Buster <no***@nowhere.com> wrote:

Phlip wrote:

Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

What language has stronger static type checking than C++?

Java for one. C++ allows some ridiculous implicit conversions (such as
double->char) in the interests of backwards compatibility with C.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Pete]

tom_usenet wrote:

On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <x@x.x> wrote:

Besides, VC++2003 is a great IDE + compiler, anyway.

The compiler is fine, but the IDE is not. I've never found a good C++
ide - good ones for other languages (such as Java - IntelliJ and
Eclipse) are common.

C++'s TU-based rather than module-based approach (not to mention other
features of the preprocessor) makes it almost impossible to write what
I would consider a good IDE for C++.

Tom

I've always thought it was a great IDE. What can the Java ones that you
mentioned do that C++ ones cannot?

- Pete

[Pete]

tom_usenet wrote:

On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <x@x.x> wrote:

Besides, VC++2003 is a great IDE + compiler, anyway.

The compiler is fine, but the IDE is not. I've never found a good C++
ide - good ones for other languages (such as Java - IntelliJ and
Eclipse) are common.

C++'s TU-based rather than module-based approach (not to mention other
features of the preprocessor) makes it almost impossible to write what
I would consider a good IDE for C++.

Tom

I've always thought it was a great IDE. What can the Java ones that you
mentioned do that C++ ones cannot?

- Pete

[Claudio Puviani]

"Buster" <no***@nowhere.com> wrote

Phlip wrote:

Wrong. Syntax checking makes errors like 10/*pointer
easier to spot. Less bugs. And modern syntax checking
performs static type analysis to display compilation errors
before you compile - see Eclipse. But C++ can't use this
feature, because our compilers _can_ build executables
with errors!

What language has stronger static type checking than C++?

Ada, Pascal, Modula 2 & 3, Oberon, Concurrent Euclid, Java, C#... just to
name a few off the top of my head. The fact that C++'s static type checking
is strong enough, but not overly constraining is one of its strengths. Any
stronger and it falls in the language-designer-is-holier-than-thou family of
languages.

Claudio Puviani

[Claudio Puviani]

"Buster" <no***@nowhere.com> wrote

Phlip wrote:

Wrong. Syntax checking makes errors like 10/*pointer
easier to spot. Less bugs. And modern syntax checking
performs static type analysis to display compilation errors
before you compile - see Eclipse. But C++ can't use this
feature, because our compilers _can_ build executables
with errors!

What language has stronger static type checking than C++?

Ada, Pascal, Modula 2 & 3, Oberon, Concurrent Euclid, Java, C#... just to
name a few off the top of my head. The fact that C++'s static type checking
is strong enough, but not overly constraining is one of its strengths. Any
stronger and it falls in the language-designer-is-holier-than-thou family of
languages.

Claudio Puviani

[Christoph Rabel]

Pete wrote:

tom_usenet wrote:

On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <x@x.x> wrote:

Besides, VC++2003 is a great IDE + compiler, anyway.

The compiler is fine, but the IDE is not. I've never found a good C++
ide - good ones for other languages (such as Java - IntelliJ and
Eclipse) are common.

C++'s TU-based rather than module-based approach (not to mention other
features of the preprocessor) makes it almost impossible to write what
I would consider a good IDE for C++.

I've always thought it was a great IDE. What can the Java ones that you
mentioned do that C++ ones cannot?

Now, for example refactoring, highlighting functions that are never
called (at least private ones), highlighting unnecessary imports, better
intellisense,...

But Java makes a lot of this stuff easier, in C++ things are often more
complicated.

Download this plugin for VS and you will hate to work without it:
Visual Assist from www.wholetomato.com
(No, I'm not in any way affiliated with that company, I just think the
tool is great!)

Christoph

[Christoph Rabel]

Pete wrote:

tom_usenet wrote:

On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <x@x.x> wrote:

Besides, VC++2003 is a great IDE + compiler, anyway.

The compiler is fine, but the IDE is not. I've never found a good C++
ide - good ones for other languages (such as Java - IntelliJ and
Eclipse) are common.

C++'s TU-based rather than module-based approach (not to mention other
features of the preprocessor) makes it almost impossible to write what
I would consider a good IDE for C++.

I've always thought it was a great IDE. What can the Java ones that you
mentioned do that C++ ones cannot?

Now, for example refactoring, highlighting functions that are never
called (at least private ones), highlighting unnecessary imports, better
intellisense,...

But Java makes a lot of this stuff easier, in C++ things are often more
complicated.

Download this plugin for VS and you will hate to work without it:
Visual Assist from www.wholetomato.com
(No, I'm not in any way affiliated with that company, I just think the
tool is great!)

Christoph

[Buster]

Buster wrote:

Phlip wrote:

Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

What language has stronger static type checking than C++?

[Re. other replies.] OK, you got me. But what I'm trying to get at is
that quote - "C++ can't use this feature" - what's that about? There are
syntax errors in C++.

--
Regards,
Buster.

[Buster]

Buster wrote:

Phlip wrote:

Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

What language has stronger static type checking than C++?

[Re. other replies.] OK, you got me. But what I'm trying to get at is
that quote - "C++ can't use this feature" - what's that about? There are
syntax errors in C++.

--
Regards,
Buster.

[Phlip]

Buster wrote:

Phlip wrote:

Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

What language has stronger static type checking than C++?

In Java, if you neglect to add a throws declaration, the compiler diagnoses
this.

In Eiffel, you can attach pre- and post-conditions, expressed in the
language as assertions, to types such that derived types inherit these
contracts from their base types.

In C++, if you neglect to make a base class destructor virtual, then destroy
thru a base class pointer, you get undefined behavior. If you write a throws
declaration that misses a type, when that type throws you abort the program.
Etc.

C++ is weakly typed.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Phlip]

Buster wrote:

Phlip wrote:

Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

What language has stronger static type checking than C++?

In Java, if you neglect to add a throws declaration, the compiler diagnoses
this.

In Eiffel, you can attach pre- and post-conditions, expressed in the
language as assertions, to types such that derived types inherit these
contracts from their base types.

In C++, if you neglect to make a base class destructor virtual, then destroy
thru a base class pointer, you get undefined behavior. If you write a throws
declaration that misses a type, when that type throws you abort the program.
Etc.

C++ is weakly typed.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[tom_usenet]

On Mon, 05 Apr 2004 13:35:30 GMT, "Pete" <x@x.x> wrote:

tom_usenet wrote:

On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <x@x.x> wrote:

Besides, VC++2003 is a great IDE + compiler, anyway.

The compiler is fine, but the IDE is not. I've never found a good C++
ide - good ones for other languages (such as Java - IntelliJ and
Eclipse) are common.

C++'s TU-based rather than module-based approach (not to mention other
features of the preprocessor) makes it almost impossible to write what
I would consider a good IDE for C++.

Tom

I've always thought it was a great IDE. What can the Java ones that you
mentioned do that C++ ones cannot?

Full code refactoring. Highlighting of *all* compiler errors as you
type. Full usage searching. Automatic code documentation (get full
documentation for a method in a popup just by hovering over a call).
Advanced context sensitive code completion and code templates. And a
whole lot more. I did find a plug-in for VC7.1 that did give much
better code completion and usage searches, but it still isn't anything
like as good as, say, IntelliJ IDEA.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[tom_usenet]

On Mon, 05 Apr 2004 13:35:30 GMT, "Pete" <x@x.x> wrote:

tom_usenet wrote:

On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <x@x.x> wrote:

Besides, VC++2003 is a great IDE + compiler, anyway.

The compiler is fine, but the IDE is not. I've never found a good C++
ide - good ones for other languages (such as Java - IntelliJ and
Eclipse) are common.

C++'s TU-based rather than module-based approach (not to mention other
features of the preprocessor) makes it almost impossible to write what
I would consider a good IDE for C++.

Tom

I've always thought it was a great IDE. What can the Java ones that you
mentioned do that C++ ones cannot?

Full code refactoring. Highlighting of *all* compiler errors as you
type. Full usage searching. Automatic code documentation (get full
documentation for a method in a popup just by hovering over a call).
Advanced context sensitive code completion and code templates. And a
whole lot more. I did find a plug-in for VC7.1 that did give much
better code completion and usage searches, but it still isn't anything
like as good as, say, IntelliJ IDEA.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[tom_usenet]

On Mon, 05 Apr 2004 15:59:52 +0200, Christoph Rabel
<od**@hal9000.vc-graz.ac.at> wrote:

Download this plugin for VS and you will hate to work without it:
Visual Assist from www.wholetomato.com
(No, I'm not in any way affiliated with that company, I just think the
tool is great!)

Ahh, that's the plugin I was talking about...

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[tom_usenet]

On Mon, 05 Apr 2004 15:59:52 +0200, Christoph Rabel
<od**@hal9000.vc-graz.ac.at> wrote:

Download this plugin for VS and you will hate to work without it:
Visual Assist from www.wholetomato.com
(No, I'm not in any way affiliated with that company, I just think the
tool is great!)

Ahh, that's the plugin I was talking about...

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Howard]

But with syntax checking in the editor, I really don't have that many
runtime bugs.
??? Syntax checking has absolutely nothing to do w/ runtime bugs. Regardless of the editor features, a syntax error will be caught during the compile, and unless your compiler builds an executable w/ errors, there is no runtime

bug.
Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

I think you're confusing two issues here. It sounds like you're describing
the advantages of on-the-fly syntax checking (i.e., while typing). What
Julie was discussing was the statement by Steven that the syntax checking
helped reduce "runtime bugs". Well, a program with syntax errors will not
compile (unless the compiler itself is broken). A run-time error is not a
syntax error. It may be caused by incorrect use of the language or a
misunderstanding of the correct syntax to accomplish a desired task, but
those are logic errors, not syntax errors. I do not understand your example
at all, either. How is that example related to a run-time bug? It's purely
a syntax error, and will not compile (unless you have code following the
comment that makes it correct, of course).

-Howard

[Howard]

But with syntax checking in the editor, I really don't have that many
runtime bugs.
??? Syntax checking has absolutely nothing to do w/ runtime bugs. Regardless of the editor features, a syntax error will be caught during the compile, and unless your compiler builds an executable w/ errors, there is no runtime

bug.
Wrong. Syntax checking makes errors like 10/*pointer easier to spot.
Less bugs. And modern syntax checking performs static type analysis to
display compilation errors before you compile - see Eclipse. But C++
can't use this feature, because our compilers _can_ build executables
with errors!

I think you're confusing two issues here. It sounds like you're describing
the advantages of on-the-fly syntax checking (i.e., while typing). What
Julie was discussing was the statement by Steven that the syntax checking
helped reduce "runtime bugs". Well, a program with syntax errors will not
compile (unless the compiler itself is broken). A run-time error is not a
syntax error. It may be caused by incorrect use of the language or a
misunderstanding of the correct syntax to accomplish a desired task, but
those are logic errors, not syntax errors. I do not understand your example
at all, either. How is that example related to a run-time bug? It's purely
a syntax error, and will not compile (unless you have code following the
comment that makes it correct, of course).

-Howard

[Phlip]

Buster wrote:

Julie wrote:

Phlip wrote:
<big snip>

You didn't add anything of value to the conversation -- just rehashed what you
already think.

Suggested comeback: no _you_ shut up!

Or else she could answer my question.

--
Phlip

[Phlip]

Buster wrote:

Julie wrote:

Phlip wrote:
<big snip>

You didn't add anything of value to the conversation -- just rehashed what you
already think.

Suggested comeback: no _you_ shut up!

Or else she could answer my question.

--
Phlip

[Phlip]

Buster wrote:

[Re. other replies.] OK, you got me. But what I'm trying to get at is
that quote - "C++ can't use this feature" - what's that about? There are
syntax errors in C++.

Consider object.method(), where method does not exist yet. The Java
perspective in the Eclipse editor can underline "method" in pink, the same
way a word processor indicates misspelled words.

A C++ perspective couldn't do that because a #define may have screwed with
object or method. Only a real compilation can find syntax errors. Compilers
tune to quickly compile a lot of code - not to instantly compile one file,
just to find its syntax errors. So C++ (presently) cannot use advanced
syntax highlighting to provide the earliest possible feedback.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Phlip]

Buster wrote:

[Re. other replies.] OK, you got me. But what I'm trying to get at is
that quote - "C++ can't use this feature" - what's that about? There are
syntax errors in C++.

Consider object.method(), where method does not exist yet. The Java
perspective in the Eclipse editor can underline "method" in pink, the same
way a word processor indicates misspelled words.

A C++ perspective couldn't do that because a #define may have screwed with
object or method. Only a real compilation can find syntax errors. Compilers
tune to quickly compile a lot of code - not to instantly compile one file,
just to find its syntax errors. So C++ (presently) cannot use advanced
syntax highlighting to provide the earliest possible feedback.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Buster]

Phlip wrote:

Buster wrote:

[Re. other replies.] OK, you got me. But what I'm trying to get at is
that quote - "C++ can't use this feature" - what's that about? There are
syntax errors in C++.
Consider object.method(), where method does not exist yet. The Java
perspective in the Eclipse editor can underline "method" in pink, the same
way a word processor indicates misspelled words.

Ugh. Does it underline the 'm' straight away, or does it wait until you
finish your word?
A C++ perspective couldn't do that because a #define may have screwed with
object or method.
Yes it could, if it understood the preprocessor.
Only a real compilation can find syntax errors.
That's not true, and doesn't make a lot of sense. (They say that only
Perl can parse Perl, but that's because the implementation defines the
language.)
Compilers
tune to quickly compile a lot of code - not to instantly compile one file,
just to find its syntax errors.
That's true, but we can write stand-alone parsers for C++ and tune them
how we wish, just as the Eclipse developers did for Java.
So C++ (presently) cannot use advanced
syntax highlighting to provide the earliest possible feedback.

That doesn't follow. C++ is not a compiler.

--
Regards,
Buster.