Re: Visual C++ 6 support issue

From: Daniel James (wastebasket_at_nospam.aaisp.org)
Date: 05/20/04 

Date: Thu, 20 May 2004 12:26:22 +0100

In article news:<8i8oa0trnlu5mim304dqqc4qug05c49of1@4ax.com>, Joseph
M. Newcomer wrote:
> [I wrote]
> >Eclipse does seem very nice to use, I'm appreciating more and more
> > of its features as I get to know it better. Of course, Eclipse
> > has the great advantage that it is working with Java, which has
> > a MUCH simpler syntax than C++ and is much easier to parse and
> > analyse.
> *****
> Yes, but the C/C++ version is in beta; I know at least two people
> who are trying it

Yes, I know there's a C++ version. I intend to take a good long look
at that when I have a moment.

[ Spy++ ]
> (Actually, this is one of the compelling arguments of the
> open-source movement. I would have put this in myself a decade
> ago if I had source)

Agreed. Of course, the source for the old Spy (not Spy++) tool is an
MSDN sample. I wonder why Spy++ isn't.

> Actually, an IDE doesn't have to parse anything. Simple lexical
> analysis works well enough to do syntax highlighting. As far as
> I know, the VC IDEs do not do anything vaguely resembling parsing
> of the source, so I don't buy any of the parsing argument.

There are things you can't do without parsing. One of those is source
browsing - which VC (6) achieves by requiring the project to be
compiled before it can be browsed. The parse is done by the compiler
and made available to the browser in the form of .sbr files. Other
things that might require parsing are, for example, a class wizard.
The problems one sometimes encounters in VC6 with ClassWiz getting
out of step with the source and the .clw and .aps files having to be
rebuilt could more easily be avoided if the Wiz used a full parse
tree to keep track of the shape of the project, and we might not need
to sprinkle the code with //{{AFX_POINT_OUT_THE_OBVIOUS comments.

Eclipse provides some nice refactoring tools for Java, you can rename
classes (Eclipse automatically updates all references to the class --
and renames the source file to match), you can rename methods, you
can extract interfaces, you can automatically move members from one
level to another in a class hiearchy ... all these things require
more understanding of the program stucture than can be gained by
lexical analysis alone.

> Besides, Java is getting templates.

The comment I heard on that was along the lines of "they managed to
make the syntax only slightly more complex than it needed to be, so
Java will still be easier to parse than C++, but unfortunately they
only really support typesafe collections so Java's templates only
give a tiny part of the power of C++'s".

> And the compiler and the IDE are completely orthogonal. The IDE
> is free to invoke any compiler it wants, including any version of
> Microsoft's C/C++ compiler.

I agree absolutely ... that's *why* any independent IDE will have to
provide its own source parsing if it wants to support browsing and
refactoring and other such goodies -- it can't rely on a cooperative
compiler giving .sbr files to play with.

I'm not saying this is impossible -- just pointing out that it's
inherently hard; which is why C++ lags behind Java in tool support
and is why IDE's that can rely on compiler support are better placed
to provide good tools soon. I hope VC8/wibbley/whatever delivers.

> >The best way to achieve good parsing for sourcecode tools like
> >browsers and refactoring tools is to get a compiler to do it.
[snip]
> *****
> And that's what the Microsoft compiler does.

In VC6 (and, I guess, 7) yes. It's interesting, though, that in the
next release one won't have to compile a project in order to be able
to browse it. I gather they're still using the first pass of the
compiler to generate the parse tree, but that compiler pass is
invoked directly by the IDE as it loads the project for the first
time (this was demonstrated using the Open Source Quake code (which,
admittedly, is C not C++, so not rocket science to parse) and --
unless it was all smoke and mirrors -- seemed to work well).

> It wouldn't surprise me if similar information could be derived
> from the gnu tools; a properly modularized IDE would simply
> have a well-defined interface to browse, and suitable plugins
> could be written.

It would be nice to see all compilers offer some sort of tool-helper
interface to the parse tree, yes. The MS compiler is the only one
that I know does this today.

> ... the person I know who is using the Eclipse beta has pointed out
> that it apparently interfaces well with SlickEdit (his hope being
> to get an IDE with a respectable editor, instead of the crap
> Microsoft has tried to pass off as an editor) ...

Eclipse's design allows a lot of different tools to be interfaced
through plugins, yes. Pluggable editors are certainly possible (in
fact, anything other than a plain text editor has to be a plugin,
including the Java code editor).

I don't mind the VC editor, myself. Yes, it's, er, "light on
functionality" ... but it does work, it doesn't crash, it supports
99% of the things I want to do when I'm editing code ... I miss the
1%, of course, and if there's a specific editing task I know will be
easier in another editor I know I have that option, but most of the
time it's easier just to use what's there.

Back in 16-bit VC days I used to use a product called "Fusion" from
the CodeWright people, which gave most of the power of the CodeWright
editor within VC (by subclassing the edit windows of the IDE). It was
much more powerful and did 99.9% of the things I wanted ... but it
used to crash or lose work (i.e. CodeWright's idea of the edit
windows' contents got out of sync with VC's) about once every couple
of days so I gave up on it in the end. If the environment had
actually supported pluggable editors by the front door it would have
been a different matter.

> "Fishbait"? I have a beta, ... and I've seen some impressive demos
> but I can't talk about them because of NDA, [snip]. There are some
> SERIOUSLY interesting things I saw at the demo, but they still
> don't know how to write an editor.

<smile>.

They said they hoped it would go to public beta in a couple of
months, so I guess I can wait and see for myself.

Cheers,
 Daniel.
 

Relevant Pages

  • Re: Visual C++ 6 support issue
    ... Of course, Eclipse has the ... simpler syntax than C++ and is much easier to parse and analyse. ... A C++ compiler is quite a tricky beast to write (which is ... preprocessor symbols and language symbols (and of language symbols ...
    (microsoft.public.vc.mfc)
  • Re: Visual C++ wont autcomplete?
    ... slow down the compiler). ... All you're really saying is that many existing Windows applications don't use ... Eclipse is much more than just an editor ... ...
    (microsoft.public.vc.mfc)
  • Re: Command line compiler
    ... I'm vastly more productive with the Microsoft tools than with the ... EMACS is the Only Real Editor. ... I'm very serious about the usability of the Unix tools; when I had to go back and use ... The compiler, at least as of five years ago, according ...
    (microsoft.public.vc.mfc)
  • Re: AfxGetApp() returns NULL
    ... the compiler gives us the opportunity to do it our way ... ... someone else who wants 4 spaces per tab can set their own value as well. ... A decent editor handles the continuation-of-parameters so easily that it doesn't even ... The same holds true with Vista vs. XP. ...
    (microsoft.public.vc.mfc)
  • Re: Visual C++ 6 support issue
    ... Of course, Eclipse has the ... Apparently there is a discussion group going on in Microsoft which is discussing the tool ... >the same parsing job that the first couple of passes of the compiler ... And the compiler and the IDE are completely orthogonal. ...
    (microsoft.public.vc.mfc)