Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: "Wayne K. Werner" <wkwerner@con2.com>
Newsgroups: scea.yaroze.programming.codewarrior
Subject: Re: Some concerns and ideas re CW
Date: 11 Jul 1997 04:07:57 GMT
Organization: SCEA Net Yaroze News
Lines: 83
Message-ID: <01bc8db0$08bb89c0$66bf43ce@wkwerner>
References: <01bc8513$4e939960$9fbf43ce@wkwerner> <33b95c29.25784289@news.scea.sony.com> <01bc869b$d2a65420$6fbf43ce@wkwerner> <33c5903d.29746230@news.scea.sony.com>
NNTP-Posting-Host: port02.con2.com
X-Newsreader: Microsoft Internet News 4.70.1155

> 	Aw, man, but that's the half the fun!  You mean I can't have
> an array of base class pointers "cSprite", where their update function
> (like cSprite.Update() ) is polymorphic depending on the derived
> class!  Like cEnemy<-->cSprite, cPlayer<-->cSprite,
> cMissle<-->cSprite, cTree<-->cSprite (where <--> means derived from),
> and then just do very general functions like cSprite->Init() and
> cSprite->Update() and cSprite->Destroy() all with just one array?
> Plus no multiple inheritance?  :^(
> 
If your thinking multiple inheritence, I'll bet your confusing some "has a"
situations for "is a" situations.  Multiple inheritence is accompanied by
many pitfalls and sticky situations.  Fortunately there are very few times
that it is clearly needed.

Of course, you can use base class pointers for sprites, but you're going to
pay for them in terms of virtual tables and indirect function calls.  If
you've got the spare cycles and memory, then go ahead.  If you don't , you
don't.

Besides, there are many concrete classes of finite number of instances that
can be usefully encapsulated without the use of virtual functions.  For
instance, a memory card class with two objects (slots 1 and 2).  Input
ports one and two (how about a type for each type of controller?)   The CD
rom.  The sound generator.  Lots of great stuff to encapsulate, and all can
be done without the need to use virtual functions.

> 	Hmmm...does this make things harder at all?  Do we tend to do
> a lot of dynamic allocation in C++?

Take a look at almost any implementation of a string class, and you'll see
what I mean.  It's very difficult to avoid dynamic allocation in classes,
they most effectively use memory.  Again, it's the eternal struggle, memory
or speed.  You must choose as the situation dictates.  And, of course,
consider the roll your own solutions, which are usually a compromise
between the two.
 
> 	Right.  But passing by pointer (there is no "call by
> reference" in C) is usually done in C as well, since it just doesn't
> make sense to consistently be copying large structures.  This also
> follows for return values.
> 
True enough.  Good ideas in C often percolate in C++.  As a note however,
Consider this.  Even a small object, that might easily be passed if only
it's size is considered will also call the copy constructor and the
destructor on the passed value.

> 	I've only seen or used inline when the code is very compact.
> Otherwise, it sort of defeats the purpose of a "function".  Maybe it
> will save you a couple of copy and paste operations on your editor!  
> 
Don't forget, the philosophy of C++ is object, method.  Data should be
accessed through access functions almost always.  This isolates the calling
code from the implementation details.  Inline functions are mandatory for
making these often small, often called functions useful.

An often overlooked use of inlining is when a function has been designed in
a top down fashion.  For instance, let's say I extract the heart of some
loop out into a function call to make the overall logic of the looping code
clearer, eliminating quite a bit of the lower complexity.

Even if the function is large, if it is only used here I will inline it. 
This gives me some advantages.  The code will be smaller and faster than a
function call.  The optimizer will be able to work more deeply with the
code (unroll the loop, perhaps).

> >When you create an object file, the entire file is linked into your
program
> 
> 	Yea, I guess this highly depends on the generality of your
> object libraries, too.  I haven't got far enough to worry about making
> my libraries over-generalized, though.  :^)
> 
Don't forget, your building a tool box for yourself.  Plan now for the
future.  Extra efforts to do it right now equal a lot of saved time down
the road.  It's the do it once, do it right school of thought.  If your
digging into the memory card to do something, might as well dig in all the
way and encapsulate that memory card, even if you don't need all of that
functionality now.  You won't be digging into the memory card again in the
future, even when you do need more functionality.  Keeps you from going
over the same old ground again.

Wayne