Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > c++ interpreter

Reply
Thread Tools

c++ interpreter

 
 
hanch
Guest
Posts: n/a
 
      04-04-2004
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
 
Reply With Quote
 
 
 
 
Pete
Guest
Posts: n/a
 
      04-04-2004
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


 
Reply With Quote
 
 
 
 
Phlip
Guest
Posts: n/a
 
      04-04-2004
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


 
Reply With Quote
 
Pete
Guest
Posts: n/a
 
      04-04-2004
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


 
Reply With Quote
 
Julie
Guest
Posts: n/a
 
      04-04-2004
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_.
 
Reply With Quote
 
Steven T. Hatton
Guest
Posts: n/a
 
      04-04-2004
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
 
Reply With Quote
 
Julie
Guest
Posts: n/a
 
      04-04-2004
"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.
 
Reply With Quote
 
Steven T. Hatton
Guest
Posts: n/a
 
      04-04-2004
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
 
Reply With Quote
 
bartek
Guest
Posts: n/a
 
      04-04-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (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.
 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      04-05-2004
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!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
bash: ./firefox-installer: /bin/sh: bad interpreter: Permission denied damon Firefox 7 08-29-2007 08:50 PM
Python embedded interpreter: how to initialize the interpreter ? ycollet@freesurf.fr Python 3 01-03-2007 01:00 AM
defining subroutines when using interpreter interactively? MackS Perl 0 03-11-2005 01:26 AM
Need a good book help me do interpreter adam Perl 0 09-01-2003 03:38 PM
bash: /root/remstats.pl: /usr/bin/perl: bad interpreter: Permission denied Goblin Perl 1 08-14-2003 11:11 AM



Advertisments