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]

Re: c++ interpreter

hanch wrote:[color=blue]
> 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[/color]

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]

Re: c++ interpreter

hanch wrote:[color=blue]
> 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[/color]

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]

Re: c++ interpreter

Pete wrote:
[color=blue]
> hanch wrote:
>[color=green]
> > 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.[/color]
>
> It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard is a
> great IDE, plus it lets you edit while debugging.[/color]

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

[Phlip]

Re: c++ interpreter

Pete wrote:
[color=blue]
> hanch wrote:
>[color=green]
> > 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.[/color]
>
> It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard is a
> great IDE, plus it lets you edit while debugging.[/color]

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

[Pete]

Re: c++ interpreter

Phlip wrote:[color=blue]
> Pete wrote:
>[color=green]
>> hanch wrote:
>>[color=darkred]
>>> 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.[/color]
>>
>> It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard
>> is a great IDE, plus it lets you edit while debugging.[/color]
>
> 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.[/color]

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]

Re: c++ interpreter

Phlip wrote:[color=blue]
> Pete wrote:
>[color=green]
>> hanch wrote:
>>[color=darkred]
>>> 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.[/color]
>>
>> It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard
>> is a great IDE, plus it lets you edit while debugging.[/color]
>
> 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.[/color]

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]

Re: c++ interpreter

Phlip wrote:[color=blue]
>
> Pete wrote:
>[color=green]
> > hanch wrote:
> >[color=darkred]
> > > 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.[/color]
> >
> > It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard is a
> > great IDE, plus it lets you edit while debugging.[/color]
>
> Editing while debugging is a bad habit because you have less incentive to
> decouple.[/color]

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

[Julie]

Re: c++ interpreter

Phlip wrote:[color=blue]
>
> Pete wrote:
>[color=green]
> > hanch wrote:
> >[color=darkred]
> > > 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.[/color]
> >
> > It's not an interpreter, but Microsoft Visual C++ .NET 2003 Standard is a
> > great IDE, plus it lets you edit while debugging.[/color]
>
> Editing while debugging is a bad habit because you have less incentive to
> decouple.[/color]

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

[Steven T. Hatton]

Re: c++ interpreter

Julie wrote:
[color=blue]
> Wrong. Not decoupling when appropriate is a 'bad habit'.
> Editing while debugging is a _feature_.[/color]

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]

Re: c++ interpreter

Julie wrote:
[color=blue]
> Wrong. Not decoupling when appropriate is a 'bad habit'.
> Editing while debugging is a _feature_.[/color]

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]

Re: c++ interpreter

"Steven T. Hatton" wrote:[color=blue]
>
> Julie wrote:
>[color=green]
> > Wrong. Not decoupling when appropriate is a 'bad habit'.
> > Editing while debugging is a _feature_.[/color]
>
> 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.[/color]

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.
[color=blue]
> But with syntax checking in the editor, I really don't have that many
> runtime bugs.[/color]

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

Re: c++ interpreter

"Steven T. Hatton" wrote:[color=blue]
>
> Julie wrote:
>[color=green]
> > Wrong. Not decoupling when appropriate is a 'bad habit'.
> > Editing while debugging is a _feature_.[/color]
>
> 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.[/color]

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.
[color=blue]
> But with syntax checking in the editor, I really don't have that many
> runtime bugs.[/color]

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

Re: c++ interpreter

Julie wrote:
[color=blue]
> "Steven T. Hatton" wrote:[color=green]
>>
>> 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.[/color]
>
> 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.
>[color=green]
>> But with syntax checking in the editor, I really don't have that many
>> runtime bugs.[/color]
>
> ??? 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.[/color]

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]

Re: c++ interpreter

Julie wrote:
[color=blue]
> "Steven T. Hatton" wrote:[color=green]
>>
>> 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.[/color]
>
> 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.
>[color=green]
>> But with syntax checking in the editor, I really don't have that many
>> runtime bugs.[/color]
>
> ??? 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.[/color]

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