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

[Buster]

Phlip wrote:

Buster wrote:

[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++.
Consider object.method(), where method does not exist yet. The Java
perspective in the Eclipse editor can underline "method" in pink, the same
way a word processor indicates misspelled words.

Ugh. Does it underline the 'm' straight away, or does it wait until you
finish your word?
A C++ perspective couldn't do that because a #define may have screwed with
object or method.
Yes it could, if it understood the preprocessor.
Only a real compilation can find syntax errors.
That's not true, and doesn't make a lot of sense. (They say that only
Perl can parse Perl, but that's because the implementation defines the
language.)
Compilers
tune to quickly compile a lot of code - not to instantly compile one file,
just to find its syntax errors.
That's true, but we can write stand-alone parsers for C++ and tune them
how we wish, just as the Eclipse developers did for Java.
So C++ (presently) cannot use advanced
syntax highlighting to provide the earliest possible feedback.

That doesn't follow. C++ is not a compiler.

--
Regards,
Buster.

[Phlip]

Buster wrote:

Phlip wrote:

Consider object.method(), where method does not exist yet. The Java
perspective in the Eclipse editor can underline "method" in pink, the same way a word processor indicates misspelled words.
Ugh. Does it underline the 'm' straight away, or does it wait until you
finish your word?

It waits for idle ticks.

A C++ perspective couldn't do that because a #define may have screwed with object or method.

Yes it could, if it understood the preprocessor.

Tip: read a whole post before replying.
That's true, but we can write stand-alone parsers for C++ and tune them
how we wish, just as the Eclipse developers did for Java.

Good luck. At each idle tick, you must collect all the /D command line
arguments, read all the header files, expand all the templates, etc. Of
course you can borrow the compiler's "program database" file, but that would
bond an editor to a specific compiler.

Many people want this - not for syntax highlighting, but for a refactoring
browser. Their overwhelming lack of progress might indicate "emulating a C++
compiler" is on the hard end of the scale.

Ultimately, the compiler emulation must match the destination compiler
exactly. Or it will burn engineers, and then they won't use it at all.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Phlip]

Buster wrote:

Phlip wrote:

Consider object.method(), where method does not exist yet. The Java
perspective in the Eclipse editor can underline "method" in pink, the same way a word processor indicates misspelled words.
Ugh. Does it underline the 'm' straight away, or does it wait until you
finish your word?

It waits for idle ticks.

A C++ perspective couldn't do that because a #define may have screwed with object or method.

Yes it could, if it understood the preprocessor.

Tip: read a whole post before replying.
That's true, but we can write stand-alone parsers for C++ and tune them
how we wish, just as the Eclipse developers did for Java.

Good luck. At each idle tick, you must collect all the /D command line
arguments, read all the header files, expand all the templates, etc. Of
course you can borrow the compiler's "program database" file, but that would
bond an editor to a specific compiler.

Many people want this - not for syntax highlighting, but for a refactoring
browser. Their overwhelming lack of progress might indicate "emulating a C++
compiler" is on the hard end of the scale.

Ultimately, the compiler emulation must match the destination compiler
exactly. Or it will burn engineers, and then they won't use it at all.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Julie]

Phlip wrote:

Buster wrote:

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!

Or else she could answer my question.

What question is that? You only asked one (rhetorical? -- see below), the rest
was rehashed of what you already said.
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?

Who is talking about choices? I'm not one that has the liberty to simply pick
and choose what I want to do from an endless supply of alternatives...

Honestly, this sub-topic is going absolutely no where. I can completely
understand that *you* have absolutely no need for E&C, I, on the other hand, do
have a legitimate use for it. Neither one of is right, or wrong, just
different needs.

We have absolutely *no* disagreement on decoupling.

[Julie]

Phlip wrote:

Buster wrote:

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!

Or else she could answer my question.

What question is that? You only asked one (rhetorical? -- see below), the rest
was rehashed of what you already said.
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?

Who is talking about choices? I'm not one that has the liberty to simply pick
and choose what I want to do from an endless supply of alternatives...

Honestly, this sub-topic is going absolutely no where. I can completely
understand that *you* have absolutely no need for E&C, I, on the other hand, do
have a legitimate use for it. Neither one of is right, or wrong, just
different needs.

We have absolutely *no* disagreement on decoupling.

[tom_usenet]

On Mon, 5 Apr 2004 18:02:27 -0700, "Phlip" <ph*******@yahoo.com>
wrote:

Good luck. At each idle tick, you must collect all the /D command line
arguments, read all the header files, expand all the templates, etc. Of
course you can borrow the compiler's "program database" file, but that would
bond an editor to a specific compiler.

Many people want this - not for syntax highlighting, but for a refactoring
browser. Their overwhelming lack of progress might indicate "emulating a C++
compiler" is on the hard end of the scale.

Ultimately, the compiler emulation must match the destination compiler
exactly. Or it will burn engineers, and then they won't use it at all.

There are various projects to write C++ parsers for use in, e.g., code
refactoring. But as you say, the problem is an order of magnitude or
two larger that for much simpler languages like Java.

Eclipse has a built in C++ parser, but I expect it will take a long
time before it is anything like as reliable as the Java one.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[tom_usenet]

On Mon, 5 Apr 2004 18:02:27 -0700, "Phlip" <ph*******@yahoo.com>
wrote:

Good luck. At each idle tick, you must collect all the /D command line
arguments, read all the header files, expand all the templates, etc. Of
course you can borrow the compiler's "program database" file, but that would
bond an editor to a specific compiler.

Many people want this - not for syntax highlighting, but for a refactoring
browser. Their overwhelming lack of progress might indicate "emulating a C++
compiler" is on the hard end of the scale.

Ultimately, the compiler emulation must match the destination compiler
exactly. Or it will burn engineers, and then they won't use it at all.

There are various projects to write C++ parsers for use in, e.g., code
refactoring. But as you say, the problem is an order of magnitude or
two larger that for much simpler languages like Java.

Eclipse has a built in C++ parser, but I expect it will take a long
time before it is anything like as reliable as the Java one.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Bill Seurer]

Buster wrote:

Phlip wrote:

A C++ perspective couldn't do that because a #define may have screwed
with
object or method.

Yes it could, if it understood the preprocessor.

And if it can read the user's mind re: the -D option (or equivalent)
that most compilers provide.

[Bill Seurer]

Buster wrote:

Phlip wrote:

A C++ perspective couldn't do that because a #define may have screwed
with
object or method.

Yes it could, if it understood the preprocessor.

And if it can read the user's mind re: the -D option (or equivalent)
that most compilers provide.

[Steven T. Hatton]

tom_usenet wrote:

On Mon, 5 Apr 2004 18:02:27 -0700, "Phlip" <ph*******@yahoo.com>
wrote:

Good luck. At each idle tick, you must collect all the /D command line
arguments, read all the header files, expand all the templates, etc. Of
course you can borrow the compiler's "program database" file, but that
would bond an editor to a specific compiler.

Many people want this - not for syntax highlighting, but for a refactoring
browser. Their overwhelming lack of progress might indicate "emulating a
C++ compiler" is on the hard end of the scale.

Ultimately, the compiler emulation must match the destination compiler
exactly. Or it will burn engineers, and then they won't use it at all.

There are various projects to write C++ parsers for use in, e.g., code
refactoring. But as you say, the problem is an order of magnitude or
two larger that for much simpler languages like Java.

Eclipse has a built in C++ parser, but I expect it will take a long
time before it is anything like as reliable as the Java one.

Tom

Now, suppose you had a way to represent a C++ program in XML. I know. The
very thought sounds hideous. I will suggest anybody who wants to reject
this idea out-of-hand, take a look at MathML. But even that suggests
something far more painful to look at than what I am suggesting.

Consider that XML is a descendant of SGML which was created to semantically
markup text for electronic processing. The Document Object Model (DOM) is
ostensibly just that, an object model to represent a document. It seems
reasonable in my mind to consider a source file and/or translation unit a
document.

The DOM is intended to support validity checking against some kind of
document definition, be that a DTD, XMLSchema, or other form of document
specification. I believe any properly formed C++ translation unit will be
representable as a tree graph, and thus conform to a DOM representation.

I've spent a good deal of time with the DOM specifications
http://www.w3.org/DOM/ and firmly believe this is, in principle a
reasonable approach to constructing an IDE buffer. There are many powerful
features built into the DOM which would probably be very useful in editing
and manipulating a program.

Why am I saying this here in this newsgroup? Because I think it is
potentially valuable to C++, and i would like to see someone pick it up and
run with it.

The piece I think needs to be created first is the schema representation of
C++ to validate a document against.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[Steven T. Hatton]

tom_usenet wrote:

On Mon, 5 Apr 2004 18:02:27 -0700, "Phlip" <ph*******@yahoo.com>
wrote:

Good luck. At each idle tick, you must collect all the /D command line
arguments, read all the header files, expand all the templates, etc. Of
course you can borrow the compiler's "program database" file, but that
would bond an editor to a specific compiler.

Many people want this - not for syntax highlighting, but for a refactoring
browser. Their overwhelming lack of progress might indicate "emulating a
C++ compiler" is on the hard end of the scale.

Ultimately, the compiler emulation must match the destination compiler
exactly. Or it will burn engineers, and then they won't use it at all.

There are various projects to write C++ parsers for use in, e.g., code
refactoring. But as you say, the problem is an order of magnitude or
two larger that for much simpler languages like Java.

Eclipse has a built in C++ parser, but I expect it will take a long
time before it is anything like as reliable as the Java one.

Tom

Now, suppose you had a way to represent a C++ program in XML. I know. The
very thought sounds hideous. I will suggest anybody who wants to reject
this idea out-of-hand, take a look at MathML. But even that suggests
something far more painful to look at than what I am suggesting.

Consider that XML is a descendant of SGML which was created to semantically
markup text for electronic processing. The Document Object Model (DOM) is
ostensibly just that, an object model to represent a document. It seems
reasonable in my mind to consider a source file and/or translation unit a
document.

The DOM is intended to support validity checking against some kind of
document definition, be that a DTD, XMLSchema, or other form of document
specification. I believe any properly formed C++ translation unit will be
representable as a tree graph, and thus conform to a DOM representation.

I've spent a good deal of time with the DOM specifications
http://www.w3.org/DOM/ and firmly believe this is, in principle a
reasonable approach to constructing an IDE buffer. There are many powerful
features built into the DOM which would probably be very useful in editing
and manipulating a program.

Why am I saying this here in this newsgroup? Because I think it is
potentially valuable to C++, and i would like to see someone pick it up and
run with it.

The piece I think needs to be created first is the schema representation of
C++ to validate a document against.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[Buster]

Bill Seurer wrote:

Buster wrote:

Phlip wrote:

A C++ perspective couldn't do that because a #define may have screwed
with
object or method.

Yes it could, if it understood the preprocessor.

And if it can read the user's mind re: the -D option (or equivalent)
that most compilers provide.

That's silly. The IDE invokes the compiler, so it knows what options
it's going to pass on. These depend on the configuration the user has
selected within the IDE, and on information about the compiler which
will be provided separately (e.g. the 'specs' read by gcc).

BTW, I use emacs and bash as my IDE, just the way God intended, and
when I need to use a word processor (which is rarely), the first thing
I do is disable automatic spell-checking.

--
Regards,
Buster.

[Buster]

Bill Seurer wrote:

Buster wrote:

Phlip wrote:

A C++ perspective couldn't do that because a #define may have screwed
with
object or method.

Yes it could, if it understood the preprocessor.

And if it can read the user's mind re: the -D option (or equivalent)
that most compilers provide.

That's silly. The IDE invokes the compiler, so it knows what options
it's going to pass on. These depend on the configuration the user has
selected within the IDE, and on information about the compiler which
will be provided separately (e.g. the 'specs' read by gcc).

BTW, I use emacs and bash as my IDE, just the way God intended, and
when I need to use a word processor (which is rarely), the first thing
I do is disable automatic spell-checking.

--
Regards,
Buster.

[Buster]

Phlip wrote:

Buster wrote:

Phlip wrote:

Consider object.method(), where method does not exist yet. The Java
perspective in the Eclipse editor can underline "method" in pink, the
same way a word processor indicates misspelled words.
Ugh. Does it underline the 'm' straight away, or does it wait until
you finish your word?

It waits for idle ticks.

A C++ perspective couldn't do that because a #define may have screwed
with object or method.

Yes it could, if it understood the preprocessor.

Tip: read a whole post before replying.

It would have been difficult to respond to every sentence had I done
otherwise.

That's true, but we can write stand-alone parsers for C++ and tune
them how we wish, just as the Eclipse developers did for Java.

Good luck. At each idle tick, you must collect all the /D command line
arguments, read all the header files, expand all the templates, etc.
Of course you can borrow the compiler's "program database" file, but
that would bond an editor to a specific compiler.

No. The browser's parser can build its own database. Header files and
templates make this more difficult for C++ than for Java, but the basic
problem is not changed. Does Eclipse invoke javac "at each idle tick"?
Many people want this - not for syntax highlighting, but for a
refactoring browser. Their overwhelming lack of progress might
indicate "emulating a C++ compiler" is on the hard end of the scale.
Yes, but obviously not impossible, since it can be no harder than
writing a C++ compiler.
Ultimately, the compiler emulation must match the destination compiler
exactly. Or it will burn engineers, and then they won't use it at all.

You're probably right. The simple solution is to bundle the IDE and
compiler together.

I seem to be drawing myself in deeper than I wanted. I'm not offering
to write a refactoring browser for C++ and I can see that it would be
difficult to do so. Phlip wrote, "But C++ can't use this feature,
because our compilers _can_ build executables with errors!". The
inference may be valid but its premise is false for a large class of
syntax errors. That was the only point I tried to make with my first two
posts on this thread.

--
Regards,
Buster.

[Buster]

Phlip wrote:

Buster wrote:

Phlip wrote:

Consider object.method(), where method does not exist yet. The Java
perspective in the Eclipse editor can underline "method" in pink, the
same way a word processor indicates misspelled words.
Ugh. Does it underline the 'm' straight away, or does it wait until
you finish your word?

It waits for idle ticks.

A C++ perspective couldn't do that because a #define may have screwed
with object or method.

Yes it could, if it understood the preprocessor.

Tip: read a whole post before replying.

It would have been difficult to respond to every sentence had I done
otherwise.

That's true, but we can write stand-alone parsers for C++ and tune
them how we wish, just as the Eclipse developers did for Java.

Good luck. At each idle tick, you must collect all the /D command line
arguments, read all the header files, expand all the templates, etc.
Of course you can borrow the compiler's "program database" file, but
that would bond an editor to a specific compiler.

No. The browser's parser can build its own database. Header files and
templates make this more difficult for C++ than for Java, but the basic
problem is not changed. Does Eclipse invoke javac "at each idle tick"?
Many people want this - not for syntax highlighting, but for a
refactoring browser. Their overwhelming lack of progress might
indicate "emulating a C++ compiler" is on the hard end of the scale.
Yes, but obviously not impossible, since it can be no harder than
writing a C++ compiler.
Ultimately, the compiler emulation must match the destination compiler
exactly. Or it will burn engineers, and then they won't use it at all.

You're probably right. The simple solution is to bundle the IDE and
compiler together.

I seem to be drawing myself in deeper than I wanted. I'm not offering
to write a refactoring browser for C++ and I can see that it would be
difficult to do so. Phlip wrote, "But C++ can't use this feature,
because our compilers _can_ build executables with errors!". The
inference may be valid but its premise is false for a large class of
syntax errors. That was the only point I tried to make with my first two
posts on this thread.

--
Regards,
Buster.

[tom_usenet]

On Tue, 06 Apr 2004 17:40:26 +0100, Buster <no***@nowhere.com> wrote:

Many people want this - not for syntax highlighting, but for a
refactoring browser. Their overwhelming lack of progress might
indicate "emulating a C++ compiler" is on the hard end of the scale.

Yes, but obviously not impossible, since it can be no harder than
writing a C++ compiler.

That is very very hard. Even a parser is hard to write (e.g. the new
hand-written parser in GCC 3.4). The arcane translation unit rules of
C++ (affecting name lookup, templates, overloading, etc.) make it
rather hard to parse quickly, and even harder to analyse correctly.

EDG wrote a Java front end (full parser and semantic analysis) and
compiler in less time than it took them to implement 1 C++ feature
(export). It is possible to parse C++ in realtime, but the
difficulties of doing this efficiently should not be underestimated.

Diagnosing link time type errors in realtime with squiggly underlines
would be nearly impossible.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[tom_usenet]

On Tue, 06 Apr 2004 17:40:26 +0100, Buster <no***@nowhere.com> wrote:

Many people want this - not for syntax highlighting, but for a
refactoring browser. Their overwhelming lack of progress might
indicate "emulating a C++ compiler" is on the hard end of the scale.

Yes, but obviously not impossible, since it can be no harder than
writing a C++ compiler.

That is very very hard. Even a parser is hard to write (e.g. the new
hand-written parser in GCC 3.4). The arcane translation unit rules of
C++ (affecting name lookup, templates, overloading, etc.) make it
rather hard to parse quickly, and even harder to analyse correctly.

EDG wrote a Java front end (full parser and semantic analysis) and
compiler in less time than it took them to implement 1 C++ feature
(export). It is possible to parse C++ in realtime, but the
difficulties of doing this efficiently should not be underestimated.

Diagnosing link time type errors in realtime with squiggly underlines
would be nearly impossible.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Buster]

tom_usenet wrote:

On Tue, 06 Apr 2004 17:40:26 +0100, Buster <no***@nowhere.com> wrote:

Yes, but obviously not impossible, since it can be no harder than
writing a C++ compiler.

That is very very hard.

Yes but [...]

--
Regards,
Buster.

[Buster]

tom_usenet wrote:

On Tue, 06 Apr 2004 17:40:26 +0100, Buster <no***@nowhere.com> wrote:

Yes, but obviously not impossible, since it can be no harder than
writing a C++ compiler.

That is very very hard.

Yes but [...]

--
Regards,
Buster.

[Peter Nolan]

"Pete" <x@x.x> wrote in message news:<Cg******************@newsread2.news.pas.eart hlink.net>...

tom_usenet wrote:

On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <x@x.x> 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

Tom,
I've been using Visual Studio for about 18 months now...can't imagine
a better IDE....it does everything I want....if I am careful I can
make sure that all the code I write runs on variuos flavours of unix
as well....

The VS.net IDE (my opinion) makes the desirability of an interpreter
almost go away.....there is very little need to set up some sample
code in an interpreter to trace it before compile execute because the
VS IDE is good enough to do much of what you want.....about the only
thing missing is the self declaring variables that the IBM rexx
interpreter used to have....but I have always thought declaring
variables before you use them was the better way to go.....self
declaring variables sometimes giev you the wrong data type....

Peter Nolan

[Peter Nolan]

"Pete" <x@x.x> wrote in message news:<Cg******************@newsread2.news.pas.eart hlink.net>...

tom_usenet wrote:

On Sun, 04 Apr 2004 17:28:03 GMT, "Pete" <x@x.x> 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

Tom,
I've been using Visual Studio for about 18 months now...can't imagine
a better IDE....it does everything I want....if I am careful I can
make sure that all the code I write runs on variuos flavours of unix
as well....

The VS.net IDE (my opinion) makes the desirability of an interpreter
almost go away.....there is very little need to set up some sample
code in an interpreter to trace it before compile execute because the
VS IDE is good enough to do much of what you want.....about the only
thing missing is the self declaring variables that the IBM rexx
interpreter used to have....but I have always thought declaring
variables before you use them was the better way to go.....self
declaring variables sometimes giev you the wrong data type....

Peter Nolan