gamedevlists-general — List for discussing general game development issues

Re: [GD-General] Pong ball mechanics

[Joe C. <dar...@ya...>]

I believe the speed of the ball is also a function
of the distance from the center of the paddle as
well. I think its supposed to speed up when the
angle increases... But I suppose you can make it
do anything you want. I don't think there is an
official "Pong Spec" out there :)

--- brian hook <bri...@py...> wrote:
> To answer your question, pong's paddle physics
> basically bounce the 
> ball back at an angle proportional to the distance
> from the center of 
> the paddle.  What you set as the max angle is up to
> you, of course, and 
> I'm not sure if there is an agreed upon standard,
> but you want to set 
> it steep enough that it's not going to take forever
> to bounce back 
> across the screen.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [GD-General] Pong ball mechanics

[brian h. <bri...@py...>]

> straight line? My reasoning is this: the bat is flat and perpendicular
> to the field of play so anything striking it perpendicularly should
> reflect perpendicularly ad infinitum. 

Holy crap, I never realized that pong was broken, but I think you're 
right.  Heh.  "Everything I learned about physics was taught to me 
indirectly by Nolan Bushnell".

To answer your question, pong's paddle physics basically bounce the 
ball back at an angle proportional to the distance from the center of 
the paddle.  What you set as the max angle is up to you, of course, and 
I'm not sure if there is an agreed upon standard, but you want to set 
it steep enough that it's not going to take forever to bounce back 
across the screen.

So basically:

int x = ball.x - paddle_center.x;

angle = f( x );

where f() is some function that maps a signed distance from the center 
of the paddle (presumably on the same plane/line as the paddle) to an 
angle.

-Hook

[GD-General] Pong ball mechanics

[Idahosa I. O. E. <ida...@sw...>]

I've never played a game of pong so I don't know, but I am writing up a
clone so I need to know. How does the ball travel in anything but a
straight line? My reasoning is this: the bat is flat and perpendicular
to the field of play so anything striking it perpendicularly should
reflect perpendicularly ad infinitum. This would be extremely boring and
I am obviously wrong since the ball can carom at odd angles. What are
the game mechanics to make the ball reflect at interesting angles?
 
Idahosa Edokpayi
O2Cool Games Software
 

Re: [GD-General] RE: Gamedevlists-general digest, Vol 1 #84 - 10 msgs

[J C L. <cl...@ka...>]

On Mon, 22 Jul 2002 08:52:35 +1000 
Jeff Laing <je...@SP...> wrote:

> Let the vi-emacs wars begin again!!

Blech.  Just do it thru etags and Bob's your uncle.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

[GD-General] RE: Gamedevlists-general digest, Vol 1 #84 - 10 msgs

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

> > introduced with search and replace that's done incorrectly or that
> > doesn't handle all cases:
> > 
> > int foo;
> > int bar;
> > int foobar;
> > int blahbar;
> > 
> > s&r foo -> blah
> > 
> > suddenly all your foo are blah, which is what you want, but now your
> > foobar are blahbar, which is NOT what you wanted.

Is this not a symptom of using a poor text editor?

I mean, surely, if I'm not careful enough to use the "exact word matching"
capability of my editor of choice, or worse I was foolish enough to accept
an editor without such a thing, then I have no-one to blame but myself.

:set noic
:s/\<foo\>/blah/

... will not touch foobar.

Let the vi-emacs wars begin again!!

:-)

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

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

> Message: 9
> From: "Dirk Ringe" <ri...@ph...>
> To: <gam...@li...>
> Subject: RE: [GD-General] C++ analyzers?
> Date: Fri, 19 Jul 2002 09:46:16 +0200
> 
> We just wrote an include file to pull the relevant level 4 
> warnings up to
> level 3. It is force included throughout the project:

Ye gods, why bother with level 4 at all?  Our projects use /W4 with this:

#if defined(_WIN32)
/*
 * warnings we turn off are:
 * 4054 type cast from function pointer to data pointer void *
 * 4055 type cast from data pointer void * to function pointer
 * 4097 typedef-name used as synonym for class-name
 * 4115 named type definition in parentheses (in MS header rpcasynch.h)
 * 4127 conditional expression is constant
 * 4204 non-constant aggregate initialiser 
 * 4511 copy constructor could not be generated (a few)
 * 4512 assignment operator could not be generated (a few)
 * 4514 unreferenced inline function has been removed (hundreds in C++
headers)
 * 4615 unknown user warning number (bogus warnings)
 */
#pragma warning( disable : 4054 4055 4097 4115 4127 4511 4512 4514 4615 4204
)

#endif

and we find that that traps any unsavoury practices that we need.

Allowing 4127 is perhaps a bit generous but we have an debug mechanism that
hits it a lot, and everyone likes to code 'while(1)...' instead of
'for(;;)...' for some reason.

There are a could of Windows header files which need you to disable extra
warnings, and there are one or two that actually turn warnings DOWN without
ever turning them back up, but thats pretty easy to locate and nail.

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: Batch code editing (was: [GD-General] C++ analyzers?)

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

> From: Brian Hook [mailto:bri...@py...]

[snip]

> Someone told me that the C++ spec still doesn't have a full 
> BNF grammar.
> Is that true?

It's just a few cases isn't it, and they're just coz of historical C
mannerisms?

> > But, I believe this new generation of compilers (GCC 3, and 
> VC.net or
> > whatever) is much better about exporting program metadata, so 
> > maybe it will be possible to build tools off that.
> 
> I think one of the fundamental problems is that we're still 
> stuck in an
> "editing text" mentality, and until we let go of that, it's tough to
> really improve things.
> 
> Emacs manages to work around this a lot, and there are some aspects of
> Emacs I wish MSVC had, like the ability to collapse 
> functions, comments,
> etc.  Little things like this can make a big difference when trying to
> manage code.
> 
> Sadly enough, I was impressed when I noticed that MSVC would put
> whatever comment you placed next to a variable in the little "Variable
> info" bubble.  I mean, it's just pathetic when something that 
> trivial is
> capable of impressing someone in this day and age.

Visual Assist is a whole load better with this - www.wholetomato.com. Things
like autocompletion and "spell checking" work so well. Sadly, it can't do
some of the really big things like function and clause collapsing, because
it is just a Visual Studio bolt-in, but it's better than nothing.

> I would LOVE to be able to run this mythical (apparently) tool that
> would generate output like:
> 
> *** WARNING: foo.cpp, line 3, "#include <stdio.h>", nothing reference
> from header file
> *** WARNING: bar.hpp, line 16, "class Foozle", class declared 
> but never
> used
> *** WARNING: bar.hpp, line 199, "Bar::m_iUnused", declared but never
> referenced
> 
> The few times that a compiler has tried to warn me about dumb stuff,
> it's usually bogus.  The most recent one was when GCC warned 
> that I had
> a class that could not be instantiated nor could it be 
> derived from (it
> was a pure static class, which it should have figured out).

A lot of times the linker figures this out and removes them (you can tell
because you can't put breakpoints on unreferenced functions in release
builds), but it would be nice for clean code sakes for it to tell you,
rather than just silently ditch it.

> Oh well, I can dream.  And yes, I do appreciate that C++ is 
> so amazingly
> complex that determining anything about anything is a bitch.  
> I'm still
> amazed that I get the occasional run-time error with "pure virtual
> function called" =)
> 
> Brian


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.

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?

[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

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?

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

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

[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: Batch code editing (was: [GD-General] C++ analyzers?)

[<phi...@pl...>]

Brian Hook <bri...@py...>:
> I'm still amazed that I get the occasional run-time error with "pure
virtual function called" =)

That used to throw me, until I realised it's a symptom of re-using a
destroyed object.

As the chain of destructors is called, the vtbl is overwritten with the
vtbl for the layer currently being destroyed, so that the correct virtual
functions are called. So if your root class is abstract, you end up with an
object that has a vtbl pointing to functions that don't exist. Or in the
case of VC++, stub functions that bring up the error box with that warning.
If you then try and issue a call to a virtual member of this dead object
that was defined, but not implemented in the abstract class, bingo, one
really confusing error.

Mind you, calling virtual functions in a destructor, is one of those things
I just wouldn't do on principle.

Cheers,
Phil

PS Hmm, that's probably clear as mud.

RE: Batch code editing (was: [GD-General] C++ analyzers?)

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

> Forgot to mention another handy technique: search & replace 
> with an intermediate name, like 
> "m_foobar_TEMPORARY_CRAZY_UNIQUE_IDENTIFIER",
> fix the errors, then do a global perl script on the unique 
> identifier. It'll be hard to turn foobar into blahbar that way.

Yeah, that's what I do.  It just really, really bites.

> already.  The fundamental problem is that C++ is incredibly 
> hard to parse; in fact it's still an unsolved problem :)

Someone told me that the C++ spec still doesn't have a full BNF grammar.
Is that true?

> But, I believe this new generation of compilers (GCC 3, and VC.net or
> whatever) is much better about exporting program metadata, so 
> maybe it will be possible to build tools off that.

I think one of the fundamental problems is that we're still stuck in an
"editing text" mentality, and until we let go of that, it's tough to
really improve things.

Emacs manages to work around this a lot, and there are some aspects of
Emacs I wish MSVC had, like the ability to collapse functions, comments,
etc.  Little things like this can make a big difference when trying to
manage code.

Sadly enough, I was impressed when I noticed that MSVC would put
whatever comment you placed next to a variable in the little "Variable
info" bubble.  I mean, it's just pathetic when something that trivial is
capable of impressing someone in this day and age.

I would LOVE to be able to run this mythical (apparently) tool that
would generate output like:

*** WARNING: foo.cpp, line 3, "#include <stdio.h>", nothing reference
from header file
*** WARNING: bar.hpp, line 16, "class Foozle", class declared but never
used
*** WARNING: bar.hpp, line 199, "Bar::m_iUnused", declared but never
referenced

The few times that a compiler has tried to warn me about dumb stuff,
it's usually bogus.  The most recent one was when GCC warned that I had
a class that could not be instantiated nor could it be derived from (it
was a pure static class, which it should have figured out).

Oh well, I can dream.  And yes, I do appreciate that C++ is so amazingly
complex that determining anything about anything is a bitch.  I'm still
amazed that I get the occasional run-time error with "pure virtual
function called" =)

Brian

Re: Batch code editing (was: [GD-General] C++ analyzers?)

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

On Jul 18, 2002 at 02:09 -0700, Brian Hook wrote:
> But does it do context and type sensitive changes?  Will it only change
> m_uFlags to m_uEntityFlags in only those instances where's it referenced
> as an entity?  Most search and replace tools, no matter how elaborate,
> aren't designed to actually understand the actual code itself.
> 
> That's my beef with doing things manually.  If you change the name of a
> variable you can easily find the problems by compiling and fixing
> errors, but that's tedious and error prone.  Also, silent errors can get
> introduced with search and replace that's done incorrectly or that
> doesn't handle all cases:
> 
> int foo;
> int bar;
> int foobar;
> int blahbar;
> 
> s&r foo -> blah
> 
> suddenly all your foo are blah, which is what you want, but now your
> foobar are blahbar, which is NOT what you wanted.

Forgot to mention another handy technique: search & replace with an
intermediate name, like "m_foobar_TEMPORARY_CRAZY_UNIQUE_IDENTIFIER",
fix the errors, then do a global perl script on the unique identifier.
It'll be hard to turn foobar into blahbar that way.

> Maybe I'm being na?ve, but this seems like the kind of thing that would
> be trivially easy to implement (compared to writing a compiler + IDE),
> yet all we keep getting are the basic things like automatic expansion of
> member variables when you type "foo->".  Hell, and that doesn't work 95%
> of the time anymore in MSVC =|

Well, yeah, I agree you have a point, I'm just throwing out random
practical advice that I'm sure everybody knows already.  The
fundamental problem is that C++ is incredibly hard to parse; in fact
it's still an unsolved problem :)

But, I believe this new generation of compilers (GCC 3, and VC.net or
whatever) is much better about exporting program metadata, so maybe it
will be possible to build tools off that.

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

[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 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: Batch code editing (was: [GD-General] C++ analyzers?)

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

But does it do context and type sensitive changes?  Will it only change
m_uFlags to m_uEntityFlags in only those instances where's it referenced
as an entity?  Most search and replace tools, no matter how elaborate,
aren't designed to actually understand the actual code itself.

That's my beef with doing things manually.  If you change the name of a
variable you can easily find the problems by compiling and fixing
errors, but that's tedious and error prone.  Also, silent errors can get
introduced with search and replace that's done incorrectly or that
doesn't handle all cases:

int foo;
int bar;
int foobar;
int blahbar;

s&r foo -> blah

suddenly all your foo are blah, which is what you want, but now your
foobar are blahbar, which is NOT what you wanted.

It's this kind of tedium and risk that often prevents programmers from
willingly making sweeping changes that need to be done.  When there's a
global variable called "gameState" and it can/should be put into an
appropriate object, but it would require changing a zillion instances of
code and possibly conflicting with member variables called "gameState"
so that automatic tools don't do the right thing, then often programmers
just say "leave well enough alone".  And you have bad code just sitting
there.

But, more specifically, it's something that a computer should be able to
do.  In fact, it's something that computers were DESIGNED to do --
automate tedious and repetitive tasks.  It baffles me why I can't say
"Rename CFoo::update() to CFoo::fooUpdate()", which avoids the whole s&r
problem with collisions between identically or similarly named
identifiers.

The above is an active operation, however, and I would just be joyous
with passive operations that, as I mentioned in my original e-mail, show
me obvious dumb things that should be fixed, like classes defined and
never used; members defined but never used; etc.  You'd get lots of
warnings, but they'd be easy enough to fix or ignore (e.g. padding
members in structures "short dummy" or "char pad[4]", etc.)

Maybe I'm being na=EFve, but this seems like the kind of thing that =
would
be trivially easy to implement (compared to writing a compiler + IDE),
yet all we keep getting are the basic things like automatic expansion of
member variables when you type "foo->".  Hell, and that doesn't work 95%
of the time anymore in MSVC =3D|

And yes, maybe PC-Lint is the way to fix it, but damn, it sure does
look...crusty.

Brian

Batch code editing (was: [GD-General] C++ analyzers?)

[Grills, J. <jg...@so...>]

I frequently use perl to do these sorts of things.  I have a small template
perl script that I customize a bit every time I need to do this.  It's
pretty smart too -- it's do the replacement in the file, and check for
changes, and only if it changed will it check the file out of source control
(perforce, of course) and then update its contents.

j

-----Original Message-----
From: Thatcher Ulrich [mailto:tu...@tu...]
Sent: Thursday, July 18, 2002 3:21 PM
To: gam...@li...
Subject: Re: [GD-General] C++ analyzers?


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


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

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

[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