gamedevlists-general

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

[Brian H. <bri...@py...>]

> Forgot to mention another handy technique: search & replace 
> with an intermediate name, like 
> "m_foobar_TEMPORARY_CRAZY_UNIQUE_IDENTIFIER",
> fix the errors, then do a global perl script on the unique 
> identifier. It'll be hard to turn foobar into blahbar that way.

Yeah, that's what I do.  It just really, really bites.

> already.  The fundamental problem is that C++ is incredibly 
> hard to parse; in fact it's still an unsolved problem :)

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

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

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

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

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

[<phi...@pl...>]

Brian Hook <bri...@py...>:
> I'm still amazed that I get the occasional run-time error with "pure
virtual function called" =)

That used to throw me, until I realised it's a symptom of re-using a
destroyed object.

As the chain of destructors is called, the vtbl is overwritten with the
vtbl for the layer currently being destroyed, so that the correct virtual
functions are called. So if your root class is abstract, you end up with an
object that has a vtbl pointing to functions that don't exist. Or in the
case of VC++, stub functions that bring up the error box with that warning.
If you then try and issue a call to a virtual member of this dead object
that was defined, but not implemented in the abstract class, bingo, one
really confusing error.

Mind you, calling virtual functions in a destructor, is one of those things
I just wouldn't do on principle.

Cheers,
Phil

PS Hmm, that's probably clear as mud.

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.