Thread: [GD-General] C++ analyzers?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

One of my bitches about software development are that the tools suck.
Many things that can and should be automated simply aren't.  Tools like
Emacs and make provide a lot of helpers when you have to do this manual
stuff, but they don't actually solve problems that are language specific
(since those tools aren't language specific).

When working on a large codebase, invariably it acquires several layers
of cruft and detritus.  Several Java IDEs provide high level tools to do
things like refactor, automatically name types and objects, etc.  This
can be immensely useful.

Now that I'm parked on about 120K of source code that I've written,
there are times when I want to issue a "query" about some type or
variable.

Of course, that query ends up being "grep", which completely and utterly
sucks when you have lots of name collisions.  There are certain variable
and function names that are so ubiquitous that grepping for them returns
a thousand hits.  init/create/alloc and shutdown/destroy/free; flags,
type, name, next, prev, id; etc.

One way I've gotten around this is defensive coding, whereby I prefix
members with their parent type name:

struct HSprite
{
   int iSpriteWidth; //instead of iWidth
};

Anyone that has used an old K&R style compiler that didn't consider the
type and global namespaces differently will probably have done something
similar out of necessity.

It should be entirely possible for a code analyzer to go through and
build a dependency and call graph, with knowledge of the framework's
inheritance, friendship and polymorphism, and answer queries or generate
warnings.

When doing spring cleaning on my code base, some of the examples of
things that I know the compiler/linker could do but simply don't (and
which requires lots of searching for me) are:

- warn when including header files that aren't needed.  A typical
example is when you're doing some debugging and you need sprintf() or
FILE so you #include <stdio.h>, but forget to remove it when you're
done.

- warn when forward declarations aren't used or aren't relevant, e.g.
you do "class Foo" which you've later renamed to "class FooBar", but you
still have forward declarations to a non-existent class (which don't
cause problems)

- warn when friendships aren't necessary.  This happens when you
establish a friendship from A to B because you don't want
B::privateThing accessible by the world, just by A.  But then later on
you change some stuff, and now A doesn't need B::privateThing, but it's
still a friend of the class.

- warn about types, classes, variables, and functions that are never
referenced.  This is pretty open ended, and can mean everything from
abstract base classes that are never derived from to concrete classes
that are never instantiated, but it helps to find vestigial cruft.  This
has a lot of problems if all you're doing is building a library because
you can't tell what the client program is calling, but if you're
building test programs, it's a good way of making sure you have
reasonable coverage analysis without actually running a coverage
analysis program.

And, I'm sure, there are a million other things it could check for that
currently require manual intervention.  Anyone know if such a tool
exists?

-Hook

Thread: [GD-General] C++ analyzers?

gamedevlists-general