From: daniel@me.invalid
In article , Martin B. wrote:
>> This is pretty-much where I came in ... we need better tools for
>> C++ *because* the current tools don't do semantic analysis of the
>> sourcecode and we need tools that do.
>
> Do we? Certainly we *want* those tool, but apparently it isn't in
> high enogh economic demand to get properly implemented.
I could have put that better ...
"Need" has meanings at several levels. While we C++ programmers can do
our jobs without advanced refactoring tools -- so we do not "need" such
tools in the strictest sense -- we do feel the lack of those tools, and
would work more efficiently if we had them.
It seems grossly unfair that the tool vendors who claim to "support"
multiple languages (e.g. MS with Visual Studio) offer more support for
those languages for which it is easy to do so (e.g. C#) but balk at
providing the same level of support for those for which it is difficult
(C++).
> Speaking of implemented, what refactoring tools *are* there actually
> for C++?
In addition to those you list, there is some refactoring support in
Eclipse CDT (though not as much as for Java), and I believe there is
some in SlickEdit (though I haven't tried that).
> The problem as I see it is that, no matter how portable your code
> is, you always target specific compilers. That means that unless the
> refactoring tool -- which needs to "compile" the code -- is based
> on the same compiler, there will be imperfections, to say the least.
There shouldn't be "imperfections" ... as long as the IDE and the
compiler both parse the language correctly. C++ is an ISO standard
language, so there's no ambiguity ...
That does mean, though, that IDEs that are written by compiler vendors
should have an easier job of it ... they can use the parser information
from the compiler to assist the IDE.
[The compiler's parse is often seen as a slightly different parse from
the one that refactoring tools would need, because the compiler is able
to perform the preprocessor phase as a separate pass and discard any
knowledge of the preprocessor symbol names before starting the parse
proper ... but it doesn't have to be that way, and I would think that
the benefits that could be offered in terms of better tools for the
developer would steer the compiler writers toward integrating the
preprocessor with the rest of the compile.]
> And also, thinking about it, I'd say that correct refactoring is even
> harder that static analysis, because for static analysis to be useful
> you can get away with interpreting only one compilation unit at a
> time, but with refactoring you always need to interpret the whole
> source base.
I'd agree ... but don't forget that there are already tools that do a
fairly good job of refactoring for Java and C# (for example),
refactoring C++ isn't hard because refactoring is hard ... it's hard
because parsing C++ is hard.
I have hopes that Microsoft's apparent renewed interest in native code,
brought on by their work towards Windows 8's "Metro" interface, will
nudge them towards giving as much support to C++ in the IDE as they
currently do for C# ... if only on their own platform.
> > For some wholly inadequate definition of "stuff" ...
>
> Inadequate academically or practically speaking?
Practically. I want better C++ tools in order to use them, not to see
how elegant they are.
--
Regards,
Daniel.
[Lest there be any confusion I am NOT the Boost maintainer of the same
name]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
