c++ interpreter

[tom_usenet]

I've always thought it was a great IDE. What can the Java ones that you
mentioned do that C++ ones cannot?

Full code refactoring. Highlighting of *all* compiler errors as you
type. Full usage searching. Automatic code documentation (get full
documentation for a method in a popup just by hovering over a call).
Advanced context sensitive code completion and code templates. And a
whole lot more. I did find a plug-in for VC7.1 that did give much
better code completion and usage searches, but it still isn't anything
like as good as, say, IntelliJ IDEA.

Tom

 

[tom_usenet]

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!)

Ahh, that's the plugin I was talking about...

Tom

 

[Howard]

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!

I think you're confusing two issues here. It sounds like you're describing
the advantages of on-the-fly syntax checking (i.e., while typing). What
Julie was discussing was the statement by Steven that the syntax checking
helped reduce "runtime bugs". Well, a program with syntax errors will not
compile (unless the compiler itself is broken). A run-time error is not a
syntax error. It may be caused by incorrect use of the language or a
misunderstanding of the correct syntax to accomplish a desired task, but
those are logic errors, not syntax errors. I do not understand your example
at all, either. How is that example related to a run-time bug? It's purely
a syntax error, and will not compile (unless you have code following the
comment that makes it correct, of course).

-Howard

 

[Phlip]

Suggested comeback: no _you_ shut up!

Or else she could answer my question.

 

[Phlip]

[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.

A C++ perspective couldn't do that because a #define may have screwed with
object or method. Only a real compilation can find syntax errors. Compilers
tune to quickly compile a lot of code - not to instantly compile one file,
just to find its syntax errors. So C++ (presently) cannot use advanced
syntax highlighting to provide the earliest possible feedback.

 

[Buster]

[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.

 

[Phlip]

Ugh. Does it underline the 'm' straight away, or does it wait until you
finish your word?

It waits for idle ticks.

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.

 

[Julie]

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]

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

 

[Bill Seurer]

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]

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.

 

[Buster]

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.

 

[Buster]

It waits for idle ticks.


Tip: read a whole post before replying.

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

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.

 

[tom_usenet]

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

 

[Buster]

That is very very hard.

Yes but [...]

 

[Peter Nolan]

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