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]

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]

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.

 

[Pete]

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]

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]

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.

 

[Julie]

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]

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.


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

 

[bartek]

(e-mail address removed) (hanch) wrote in @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]

Phlip wrote:

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.

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

 

[Buster]

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++?

 

[Buster]

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!

 

[tom_usenet]

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

 

[tom_usenet]

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

 

[Pete]

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]

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]

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

 

[Phlip]

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.

 

[Buster]

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