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

[Jamie F. <ja...@qu...>]

what you should be able to do, though, and i've never seen, is rename a
class member in a single place, and have that change propagated to all
places it's used (obviously warning you if there's a name clash :)

and what's this file based compiling nonsense anyway? :)

jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Sharon
Sent: 18 July 2002 20:28
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