c++ interpreter

Discussion in 'C++' started by hanch, Apr 4, 2004.

  1. hanch

    hanch Guest

    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
    hanch, Apr 4, 2004
    #1
    1. Advertising

  2. hanch

    Pete Guest

    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, Apr 4, 2004
    #2
    1. Advertising

  3. hanch

    Phlip Guest

    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?TestFirstUserInterfaces
    Phlip, Apr 4, 2004
    #3
  4. hanch

    Pete Guest

    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, Apr 4, 2004
    #4
  5. hanch

    Julie Guest

    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, Apr 4, 2004
    #5
  6. 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, Apr 4, 2004
    #6
  7. hanch

    Julie Guest

    "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, Apr 4, 2004
    #7
  8. 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, Apr 4, 2004
    #8
  9. hanch

    bartek Guest

    (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, Apr 4, 2004
    #9
  10. hanch

    Phlip Guest

    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, Apr 5, 2004
    #10
  11. hanch

    Julie Guest

    Phlip wrote:
    <big snip>

    You didn't add anything of value to the conversation -- just rehashed what you
    already think.
    Julie, Apr 5, 2004
    #11
  12. hanch

    Buster Guest

    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, Apr 5, 2004
    #12
  13. hanch

    Buster Guest

    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, Apr 5, 2004
    #13
  14. hanch

    tom_usenet Guest

    On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <> 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, Apr 5, 2004
    #14
  15. hanch

    tom_usenet Guest

    On Mon, 05 Apr 2004 13:57:14 +0100, 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++?


    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, Apr 5, 2004
    #15
  16. hanch

    Pete Guest

    tom_usenet wrote:
    > On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <> 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, Apr 5, 2004
    #16
  17. "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++?


    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, Apr 5, 2004
    #17
  18. Pete wrote:
    > tom_usenet wrote:
    >
    >>On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <> 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, Apr 5, 2004
    #18
  19. hanch

    Phlip Guest

    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?TestFirstUserInterfaces
    Phlip, Apr 5, 2004
    #19
  20. hanch

    Buster Guest

    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, Apr 5, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Goblin
    Replies:
    1
    Views:
    8,428
  2. adam
    Replies:
    0
    Views:
    951
  3. MackS
    Replies:
    0
    Views:
    455
    MackS
    Mar 11, 2005
  4. Michael Pitoniak
    Replies:
    1
    Views:
    542
    Michael Pitoniak
    Dec 20, 2003
  5. Replies:
    3
    Views:
    746
    Ziga Seilnacht
    Jan 3, 2007
Loading...

Share This Page