gamedevlists-general

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

[Brian H. <bri...@py...>]

I've used Doxygen and like it quite a bit, although getting it
configured takes a bit of work (and a friend pointed out to me that
apparently it doesn't work with ANSI C).

However, AFAIK it only documents, it doesn't actually generate many
useful warnings unless it finds slightly mismatched prototypes.  You
have to go through and examine the class graph to see discrepancies, but
unfortunately there are a lot of root nodes since all base classes are
siblings (so if you have a lot of structs, it gets cluttered, quickly).
It also doesn't differentiate between locally defined (file scope) data
structures.

I'll check out PC-Lint though.

Thanks,

Brian

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

[Tom F. <to...@mu...>]

PC-Lint is slightly eccentric (setup, manual, etc), but it's heart is in the
right place, and it does work. As it's motto says "noisy at first, quietens
down after a while". Very very simple to tell it to ignore stuff you don't
care about. Don't worry too much about it filling a few gig of disk space
with warnings the first time you run it :-)


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 17 July 2002 20:00
> To: gam...@li...
> Subject: RE: [GD-General] C++ analyzers?
> 
> 
> I've used Doxygen and like it quite a bit, although getting it
> configured takes a bit of work (and a friend pointed out to me that
> apparently it doesn't work with ANSI C).
> 
> However, AFAIK it only documents, it doesn't actually generate many
> useful warnings unless it finds slightly mismatched prototypes.  You
> have to go through and examine the class graph to see 
> discrepancies, but
> unfortunately there are a lot of root nodes since all base classes are
> siblings (so if you have a lot of structs, it gets cluttered, 
> quickly).
> It also doesn't differentiate between locally defined (file 
> scope) data
> structures.
> 
> I'll check out PC-Lint though.
> 
> Thanks,
> 
> Brian
> 
> 
> 
> -------------------------------------------------------
> 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
> 

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

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

[Brian H. <bri...@py...>]

Quite true, and this illustrates my earlier comments of how bad most
software development tools.  Something as conceptually simple as
renaming a variable can be incredibly difficult to manage.  Even using a
standard automated tool like perl or sed/awk you run into the problem
that there's no context.

We have tools to automatically generate code and do all other kinds of
fluff crap, but if you actually want something that can go through and
rename all instances of "m_foo" for all instances of class "CBar", it
doesn't seem possible.  If we don't even have tools that can tell you
something as trivial as what variables are unused, then the above
doesn't seem likely to happen any time soon =)

MSVC doesn't warm that:

int i = 0;

is an unused variable even if you don't use it anywhere.  And any class
with a constructor also won't trigger the warning, even if the
constructor doesn't do anything.  So I find myself with lots of
temporaries, etc. that are laying around that I didn't realize that are
there or are no longer using.  A common example is when you create a
temporary solely to make debugging easier:

foo f;

f = blah();

callSomefunction( f );

But then later you fix the bug, restructure the code, etc. and do:

callSomefunction( blah() );

But you forget that "foo f" is still there.  And it's gonna stay there
forever now =)  One of the nicer aspects of ANSI C is that since there
aren't hidden operations like constructors, destructors, etc. then it
can be a lot more stringent about finding things like that.

That ebrowser thing might be nice.

Brian

> -----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.

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

[Thatcher U. <tu...@tu...>]

On Jul 18, 2002 at 12:41 -0700, Brian Hook wrote:
> Quite true, and this illustrates my earlier comments of how bad most
> software development tools.  Something as conceptually simple as
> renaming a variable can be incredibly difficult to manage.  Even using a
> standard automated tool like perl or sed/awk you run into the problem
> that there's no context.
> 
> We have tools to automatically generate code and do all other kinds of
> fluff crap, but if you actually want something that can go through and
> rename all instances of "m_foo" for all instances of class "CBar", it
> doesn't seem possible.

Well, the compiler can sure help:

1. rename "m_foo" to "m_foobar" in the header

2. compile

3. visit each compile error and fix by hand (or with an editor macro
   if it's a big job)

I've found that manual brute force takes much longer in theory than in
practice.  Once I had to rename a 3D vector class from "vector" to
"vec3" throughout a working game; I was dreading it, but it took all
of about 30 minutes.  That's by far the worst case I've ever
encountered.  Sure it would be nice if it took 10 seconds, but it's
not something most people have to do every week.

-- 
Thatcher Ulrich
http://tulrich.com

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

[Mickael P. <mpo...@ed...>]

> > We have tools to automatically generate code and do all other kinds of
> > fluff crap, but if you actually want something that can go through and
> > rename all instances of "m_foo" for all instances of class "CBar", it
> > doesn't seem possible.
>
> Well, the compiler can sure help:
>
> 1. rename "m_foo" to "m_foobar" in the header
>
> 2. compile
>
> 3. visit each compile error and fix by hand (or with an editor macro
>    if it's a big job)
>
> I've found that manual brute force takes much longer in theory than in
> practice.  Once I had to rename a 3D vector class from "vector" to
> "vec3" throughout a working game; I was dreading it, but it took all
> of about 30 minutes.  That's by far the worst case I've ever
> encountered.  Sure it would be nice if it took 10 seconds, but it's
> not something most people have to do every week.

Work only on a clean project.

At hope, I decided to modernize the 6502 cross assembler I was using, a nice
small tool visibly developped on a long time period, with a mix of old C
parameter definition, new style parameters, all globals and locals were in
lowercase without any syntactic convention, half comments in german, half in
english, and most of variables were one or two letter long.

So I tried what you said, and renamed a local called "s" in the main loop of
the parser, and rebuilded.... ZERO error :)))

The reason ? In the code "s" was also a global variable in one of the
modules...

Never underevaluate the code !

    Mickael Pointier

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

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

one thing that can help quite a lot is to push your code through more than
one compiler, so it'll be tested in different ways. GCC is generally much
tighter than MSVC, i find.

jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: 18 July 2002 20:41
To: gam...@li...
Subject: RE: [GD-General] C++ analyzers?


Quite true, and this illustrates my earlier comments of how bad most
software development tools.  Something as conceptually simple as
renaming a variable can be incredibly difficult to manage.  Even using a
standard automated tool like perl or sed/awk you run into the problem
that there's no context.

We have tools to automatically generate code and do all other kinds of
fluff crap, but if you actually want something that can go through and
rename all instances of "m_foo" for all instances of class "CBar", it
doesn't seem possible.  If we don't even have tools that can tell you
something as trivial as what variables are unused, then the above
doesn't seem likely to happen any time soon =)

MSVC doesn't warm that:

int i = 0;

is an unused variable even if you don't use it anywhere.  And any class
with a constructor also won't trigger the warning, even if the
constructor doesn't do anything.  So I find myself with lots of
temporaries, etc. that are laying around that I didn't realize that are
there or are no longer using.  A common example is when you create a
temporary solely to make debugging easier:

foo f;

f = blah();

callSomefunction( f );

But then later you fix the bug, restructure the code, etc. and do:

callSomefunction( blah() );

But you forget that "foo f" is still there.  And it's gonna stay there
forever now =)  One of the nicer aspects of ANSI C is that since there
aren't hidden operations like constructors, destructors, etc. then it
can be a lot more stringent about finding things like that.

That ebrowser thing might be nice.

Brian

> -----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.



-------------------------------------------------------
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

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

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

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

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

> -----Original Message-----
> From: Thatcher Ulrich [mailto:tu...@tu...]=20
> Sent: Thursday, July 18, 2002 1:21 PM
> To: gam...@li...
> Subject: Re: [GD-General] C++ analyzers?
>=20
> > We have tools to automatically generate code and do all=20
> other kinds of
> > fluff crap, but if you actually want something that can go=20
> through and
> > rename all instances of "m_foo" for all instances of class=20
> "CBar", it
> > doesn't seem possible.
>=20
> Well, the compiler can sure help:
>=20
> 1. rename "m_foo" to "m_foobar" in the header
>=20
> 2. compile
>=20
> 3. visit each compile error and fix by hand (or with an editor macro
>    if it's a big job)

I do this too but it makes me wary and there's always room for me to
mess it up.  Sure the code compiles, but is it right?  Maybe I mistyped
"m_fobar" for one of those substitution and my base class just so
happened to have one of those.

Now, an uber-script that makes the name substitution project-wide,
rebuilds the project, and checks to see that the output binaries are
bitwise identical...that would be cool.  I would trust that a lot more
than my highly fallible self.

--brian

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

[Thatcher U. <tu...@tu...>]

On Jul 18, 2002 at 02:13 -0700, Brian Sharon wrote:
> > 
> > Well, the compiler can sure help:
> > 
> > 1. rename "m_foo" to "m_foobar" in the header
> > 
> > 2. compile
> > 
> > 3. visit each compile error and fix by hand (or with an editor macro
> >    if it's a big job)
> 
> I do this too but it makes me wary and there's always room for me to
> mess it up.  Sure the code compiles, but is it right?  Maybe I mistyped
> "m_fobar" for one of those substitution and my base class just so
> happened to have one of those.

1. Side note, MHO: "protected:" is the work of the Devil.

2. I agree you should be wary.

> Now, an uber-script that makes the name substitution project-wide,
> rebuilds the project, and checks to see that the output binaries are
> bitwise identical...that would be cool.  I would trust that a lot more
> than my highly fallible self.

3. This scares me as much as manual edits... I think the XP people
   have a good point here with automated unit tests -- sleep easier
   always, whether you made changes manually or via a tool.

-- 
Thatcher Ulrich
http://tulrich.com

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

[Brian H. <bri...@py...>]

> Now, an uber-script that makes the name substitution 
> project-wide, rebuilds the project, and checks to see that 
> the output binaries are bitwise identical...that would be 
> cool.  I would trust that a lot more than my highly fallible self.

Other than the bitwise part, this is exactly what I'm talking about, but
as I've been ranting for several e-mails now =), a script that doesn't
know the language simply can't do it all. You can't do a bitwise compare
if you have assertions or anything else that might insert or create a
string based on a variable name, and who knows what other minor stuff
might be shifted around inside a symbol table because the symbol hashed
differently, etc. 

Java IDEs provide a lot of the stuff I'm talking about, and I'm curious
why this doesn't exist in C++ except in the crudest form (i.e. "Class
Wizards" that generate code but then, if you edit the code, you're
usually hosed if you want to use the wizard again, unless that
'technology' has gotten much better).

With a typical Java IDE you can trivially rename a method, class, member
function, etc.  and it just runs through your code and updates it as
necessary.  In fact, IBM's IDE used to prevent you from editing files
directly (!).  I don't think we're at that point yet, but I think that
the notion is completely sound.

Hell, didn't SmallTalk do a lot of this?  Kent, you reading this?

Objective-C/Cocoa/ProjectBuilder/InterfaceBuilder kind of approach the
problem tangentially, at least for GUI construction, by just hiding much
of the mundania from you, but it's not a total solution (although making
GUIs with Cocoa is laughably easy with the existing tools).

-Hook

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

[Kent Q. <ken...@co...>]

Thursday, July 18, 2002, 5:30:28 PM, you wrote:

> Other than the bitwise part, this is exactly what I'm talking about, but
> as I've been ranting for several e-mails now =), a script that doesn't
> know the language simply can't do it all. You can't do a bitwise compare
> if you have assertions or anything else that might insert or create a
> string based on a variable name, and who knows what other minor stuff
> might be shifted around inside a symbol table because the symbol hashed
> differently, etc. 

> Java IDEs provide a lot of the stuff I'm talking about, and I'm curious
> why this doesn't exist in C++ except in the crudest form (i.e. "Class
> Wizards" that generate code but then, if you edit the code, you're
> usually hosed if you want to use the wizard again, unless that
> 'technology' has gotten much better).

> With a typical Java IDE you can trivially rename a method, class, member
> function, etc.  and it just runs through your code and updates it as
> necessary.  In fact, IBM's IDE used to prevent you from editing files
> directly (!).  I don't think we're at that point yet, but I think that
> the notion is completely sound.

> Hell, didn't SmallTalk do a lot of this?  Kent, you reading this?

There were some very cool tools in Smalltalk. It's been 8 years now
since I was a Smalltalk weenie. The cool thing about Smalltalk was
that the tools were part of the environment. If you needed something,
you could write it just that easily, and there was a lot of stuff
already written.

But the bad thing was that you usually had to ship your environment
because it was nearly impossible to disentangle the tools from the
code that made up the application.

You're really dancing around the thing that I think is the worst thing
today about C++, and that is its continued insistence to depend on
1970s linker technology. C++ assumes that the linker is stupid, so
that all the work has to be done by the compiler, and there's no
standard linker format.

Java uses a standard class (object) file format, and it's easy to
write tools that look at that format. It also supports reflection, so
you can write code that loads and analyzes compiled objects. As a
result, you can use the built-in tooling to manage the codebase. With
C++, you have to rely on parse-level tools, which, given the
complexity of the C++ language, means that you basically have to write
a GOOD compiler to even parse a source file.

That's why nobody writes good tools for it.

Your emails got me thinking that there really is a crying need for
this, and maybe there's a business in it. But the cost of development
of the tools is quite high, making the business much more difficult to
get funding for.

The more I code in C++, the more I like Java...for everything but
delivering the final app to millions of users.

       Kent
       


-- 
Kent Quirk, CTO, CogniToy
ken...@co...
http://www.cognitoy.com

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

[Jeff L. <je...@SP...>]

> MSVC doesn't warm that:
> 
> int i = 0;
> 
> is an unused variable even if you don't use it anywhere.  And 

Um, yes it does.  Maybe wou don't have your warnings set high enough.  That
particular construct will generate a "variable initialised but never used"
warning.

> But you forget that "foo f" is still there.  And it's gonna stay there
> forever now =)  One of the nicer aspects of ANSI C is that since there
> aren't hidden operations like constructors, destructors, etc. then it
> can be a lot more stringent about finding things like that.

Re-read your compiler switches manual, especially the warning stuff.

Our programmers all get really annoyed when they run a big compile, only to
have it bitch at the last minute that "this variable was not used" - because
we have warnings treated as errors, so it stops the whole shebang, rather
than being an ignored warning.

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

[Brian H. <bri...@py...>]

> > int i = 0;
> > 
> > is an unused variable even if you don't use it anywhere.  And
> 
> Um, yes it does.  Maybe wou don't have your warnings set high 
> enough.  That particular construct will generate a "variable 
> initialised but never used" warning.

Doh, I stand corrected.  I had warning levels 3, and it's per project,
not per workspace, so it wasn't being carried over to all the other
projects.  My bad.  /me grins sheepishly.

Brian

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

[Brian H. <bri...@py...>]

Bloody hell, I enabled it for ONE file and got 1500 warnings, of which
1500 were bloody irrelevant =(

Some of them I can hack around, but others I'm not aware of a way to do.
For example, unreferenced inline functions; copy constructor could not
be generated (?); and unreferenced formal parameter.

Brian

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

[Dirk R. <ri...@ph...>]

We just wrote an include file to pull the relevant level 4 warnings up to
level 3. It is force included throughout the project:

#ifndef __APPWARNINGS_HPP
#define __APPWARNINGS_HPP

#pragma warning(3: 4001)
#pragma warning(4: 4018)
#pragma warning(3: 4019)
#pragma warning(3: 4032)
#pragma warning(3: 4057)
#pragma warning(3: 4061)
#pragma warning(3: 4092)

// #pragma warning(3: 4100)
#pragma warning(4: 4103)  // 'filename' : used #pragma pack to change
alignment. Grund: STLPort verwendet diese Technik
#pragma warning(3: 4121)
#pragma warning(3: 4125)
// #pragma warning(3: 4127)
#pragma warning(3: 4128)
#pragma warning(3: 4130)
#pragma warning(3: 4131)
#pragma warning(3: 4132)
#pragma warning(3: 4134)
#pragma warning(3: 4152)
#pragma warning(3: 4189)

#pragma warning(3: 4200)
#pragma warning(3: 4201)
#pragma warning(3: 4202)
#pragma warning(3: 4206)
#pragma warning(3: 4207)
#pragma warning(3: 4208)
#pragma warning(3: 4209)
#pragma warning(3: 4210)
// #pragma warning(3: 4211)
#pragma warning(3: 4212)
#pragma warning(3: 4213)
#pragma warning(3: 4214)
#pragma warning(3: 4220)
#pragma warning(3: 4221)
#pragma warning(3: 4222)
#pragma warning(3: 4223)
#pragma warning(3: 4232)
#pragma warning(3: 4233)
#pragma warning(3: 4234)
#pragma warning(3: 4235)
#pragma warning(3: 4236)
#pragma warning(3: 4238)
#pragma warning(3: 4239)
#pragma warning(4: 4244)
#pragma warning(3: 4245)
#pragma warning(3: 4268)
#pragma warning(4: 4290)
#pragma warning(3: 4355)
#pragma warning(3: 4504)
#pragma warning(3: 4505)
#pragma warning(3: 4507)
#pragma warning(4: 4514)
#pragma warning(3: 4515)
#pragma warning(3: 4516)
#pragma warning(3: 4517)

#pragma warning(3: 4611)

#pragma warning(3: 4663)
#pragma warning(3: 4665)
#pragma warning(3: 4670)
#pragma warning(3: 4671)
#pragma warning(3: 4672)
#pragma warning(3: 4673)
#pragma warning(3: 4674)
#pragma warning(3: 4699)
#pragma warning(3: 4701)
#pragma warning(3: 4705)
#pragma warning(3: 4706)
#pragma warning(3: 4709)
// #pragma warning(3: 4710)
#pragma warning(3: 4727)
#  pragma warning  ( disable : 4786)

#endif

(And no, there are no comments beside each warning to tell me whats that one
for *g*)

Dirk

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: Friday, July 19, 2002 3:32 AM
To: gam...@li...
Subject: RE: [GD-General] C++ analyzers?


Bloody hell, I enabled it for ONE file and got 1500 warnings, of which
1500 were bloody irrelevant =(

Some of them I can hack around, but others I'm not aware of a way to do.
For example, unreferenced inline functions; copy constructor could not
be generated (?); and unreferenced formal parameter.

Brian



-------------------------------------------------------
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