Re[2]: [GD-General] C++ analyzers?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hello Peter,

Thursday, July 18, 2002, 10:19:42 PM, you wrote:

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

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

It's not precisely what you're asking for but using unit tests and
integrating your code often helps with this kind of problems alot.

(In case someone missed it read excellent Martin Fowler's "Continuous
Integration" where he explays why and when it is good for a man to
check-in often: 
http://www.martinfowler.com/articles/continuousIntegration.html )

Best regards,
 Kerim                            mailto:wa...@st...

PL> Peter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PL> -Hook

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