RE: Batch code editing (was: [GD-General] C++ analyzers?)

[Tom F. <to...@mu...>]

> From: Brian Hook [mailto:bri...@py...]

[snip]

> Someone told me that the C++ spec still doesn't have a full 
> BNF grammar.
> Is that true?

It's just a few cases isn't it, and they're just coz of historical C
mannerisms?

> > But, I believe this new generation of compilers (GCC 3, and 
> VC.net or
> > whatever) is much better about exporting program metadata, so 
> > maybe it will be possible to build tools off that.
> 
> I think one of the fundamental problems is that we're still 
> stuck in an
> "editing text" mentality, and until we let go of that, it's tough to
> really improve things.
> 
> Emacs manages to work around this a lot, and there are some aspects of
> Emacs I wish MSVC had, like the ability to collapse 
> functions, comments,
> etc.  Little things like this can make a big difference when trying to
> manage code.
> 
> Sadly enough, I was impressed when I noticed that MSVC would put
> whatever comment you placed next to a variable in the little "Variable
> info" bubble.  I mean, it's just pathetic when something that 
> trivial is
> capable of impressing someone in this day and age.

Visual Assist is a whole load better with this - www.wholetomato.com. Things
like autocompletion and "spell checking" work so well. Sadly, it can't do
some of the really big things like function and clause collapsing, because
it is just a Visual Studio bolt-in, but it's better than nothing.

> I would LOVE to be able to run this mythical (apparently) tool that
> would generate output like:
> 
> *** WARNING: foo.cpp, line 3, "#include <stdio.h>", nothing reference
> from header file
> *** WARNING: bar.hpp, line 16, "class Foozle", class declared 
> but never
> used
> *** WARNING: bar.hpp, line 199, "Bar::m_iUnused", declared but never
> referenced
> 
> The few times that a compiler has tried to warn me about dumb stuff,
> it's usually bogus.  The most recent one was when GCC warned 
> that I had
> a class that could not be instantiated nor could it be 
> derived from (it
> was a pure static class, which it should have figured out).

A lot of times the linker figures this out and removes them (you can tell
because you can't put breakpoints on unreferenced functions in release
builds), but it would be nice for clean code sakes for it to tell you,
rather than just silently ditch it.

> Oh well, I can dream.  And yes, I do appreciate that C++ is 
> so amazingly
> complex that determining anything about anything is a bitch.  
> I'm still
> amazed that I get the occasional run-time error with "pure virtual
> function called" =)
> 
> Brian


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.