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

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

If it wasn't clear... the need for this arises when I'm incorporating new
files (from the net, from other, unrelated projects, or the like..) into
our current project, and I'd like to modify the new files so they conform to
our own naming conventions and coding styles. Functional changes come next,
once the project as a whole compiles again.

Peter

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Sharon
Sent: Thursday, July 18, 2002 12:28 PM
To: gam...@li...
Subject: RE: [GD-General] C++ analyzers?


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...]
> Sent: Thursday, July 18, 2002 11:20 AM
> To: gam...@li...
> Subject: RE: [GD-General] C++ analyzers?
>
>
> 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_idU7