Re: c++ interpreter
From: Phlip (phlip_cpp_at_yahoo.com)
Date: 04/05/04
- Next message: bartek: "Re: [OT] Naming Conventions: Question of Style, or Library Compatibility?"
- Previous message: ikl: "Is a created before b?"
- In reply to: Julie: "Re: c++ interpreter"
- Next in thread: Julie: "Re: c++ interpreter"
- Reply: Julie: "Re: c++ interpreter"
- Reply: Buster: "Re: c++ interpreter"
- Reply: Howard: "Re: c++ interpreter"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 4 Apr 2004 20:21:54 -0700
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!
- Next message: bartek: "Re: [OT] Naming Conventions: Question of Style, or Library Compatibility?"
- Previous message: ikl: "Is a created before b?"
- In reply to: Julie: "Re: c++ interpreter"
- Next in thread: Julie: "Re: c++ interpreter"
- Reply: Julie: "Re: c++ interpreter"
- Reply: Buster: "Re: c++ interpreter"
- Reply: Howard: "Re: c++ interpreter"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
