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

[Peter L. <pe...@to...>]

coincidentally enough, today I was searching for (and not finding..) a file
differencing program that understood C++. Most differencing programs can be
configured to ignore whitespace; it would be nice to ignore comments, too.
Even more powerful would be one that compared the parse-tree, ignoring
symbol name changes. This may sound frivolous, but it's not. Typically, when
I'm merging some code into an existing project, I'll add a ton of comments,
rename things to match a common set of naming conventions, maybe add or
remove a few parentheses or curly braces, and maybe move a few variable
declarations or definitions.
  If the code breaks after that, I've totally lost the ability to (in an
automated way) compare it to the original source. But none of the above
operations -should- have changed the way the parsed code should look. (OK,
maybe moving variable definitions could..)

  I've hunted around the net a bit, and haven't found a code repository of
helpful little utilities like that. I suspect it's out there somewhere,
though.

Peter

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: Wednesday, July 17, 2002 11:35 AM
To: gam...@li...
Subject: [GD-General] C++ analyzers?


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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557