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

[Brian S. <bs...@mi...>]

I hope I'm not guilty of stating the blatantly obvious, but renaming
variables and checking in has to be one of the classic "I couldn't have
broken the build, I didn't change anything" moves.  I wouldn't think
renamed symbols are a good thing to ignore, if you're trying figure out
why things that used to work no longer do.

--brian

> -----Original Message-----
> From: Peter Lipson [mailto:pe...@to...]=20
> Sent: Thursday, July 18, 2002 11:20 AM
> To: gam...@li...
> Subject: RE: [GD-General] C++ analyzers?
>=20
>=20
> coincidentally enough, today I was searching for (and not=20
> finding..) a file
> differencing program that understood C++. Most differencing=20
> programs can be
> configured to ignore whitespace; it would be nice to ignore=20
> 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.=20
> Typically, when
> I'm merging some code into an existing project, I'll add a=20
> ton of comments,
> rename things to match a common set of naming conventions,=20
> maybe add or
> remove a few parentheses or curly braces, and maybe move a=20
> few variable
> declarations or definitions.
>   If the code breaks after that, I've totally lost the=20
> ability to (in an
> automated way) compare it to the original source. But none of=20
> the above
> operations -should- have changed the way the parsed code=20
> should look. (OK,
> maybe moving variable definitions could..)
>=20
>   I've hunted around the net a bit, and haven't found a code=20
> repository of
> helpful little utilities like that. I suspect it's out there=20
> somewhere,
> though.
>=20
> Peter
>=20
> -----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?
>=20
>=20
> One of my bitches about software development are that the tools suck.
> Many things that can and should be automated simply aren't. =20
> Tools like
> Emacs and make provide a lot of helpers when you have to do=20
> this manual
> stuff, but they don't actually solve problems that are=20
> language specific
> (since those tools aren't language specific).
>=20
> When working on a large codebase, invariably it acquires=20
> several layers
> of cruft and detritus.  Several Java IDEs provide high level=20
> tools to do
> things like refactor, automatically name types and objects, etc.  This
> can be immensely useful.
>=20
> 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.
>=20
> Of course, that query ends up being "grep", which completely=20
> and utterly
> sucks when you have lots of name collisions.  There are=20
> certain variable
> and function names that are so ubiquitous that grepping for=20
> them returns
> a thousand hits.  init/create/alloc and shutdown/destroy/free; flags,
> type, name, next, prev, id; etc.
>=20
> One way I've gotten around this is defensive coding, whereby I prefix
> members with their parent type name:
>=20
> struct HSprite
> {
>    int iSpriteWidth; //instead of iWidth
> };
>=20
> Anyone that has used an old K&R style compiler that didn't=20
> consider the
> type and global namespaces differently will probably have=20
> done something
> similar out of necessity.
>=20
> 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=20
> or generate
> warnings.
>=20
> 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:
>=20
> - 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.
>=20
> - warn when forward declarations aren't used or aren't relevant, e.g.
> you do "class Foo" which you've later renamed to "class=20
> FooBar", but you
> still have forward declarations to a non-existent class (which don't
> cause problems)
>=20
> - 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=20
> B::privateThing, but it's
> still a friend of the class.
>=20
> - 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=20
> cruft.  This
> has a lot of problems if all you're doing is building a=20
> 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.
>=20
> And, I'm sure, there are a million other things it could=20
> check for that
> currently require manual intervention.  Anyone know if such a tool
> exists?
>=20
> -Hook