Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: jamin1@psu.edu (Jamin Frederick)
Newsgroups: scea.yaroze.programming.codewarrior
Subject: Re: Some concerns and ideas re CW
Date: Fri, 11 Jul 1997 02:05:10 GMT
Organization: SCEA Net Yaroze News
Lines: 99
Message-ID: <33c5903d.29746230@news.scea.sony.com>
References: <01bc8513$4e939960$9fbf43ce@wkwerner> <33b95c29.25784289@news.scea.sony.com> <01bc869b$d2a65420$6fbf43ce@wkwerner>
NNTP-Posting-Host: nbppp42.cac.psu.edu
X-Newsreader: Forte Free Agent 1.11/32.235

On 2 Jul 1997 03:55:19 GMT, "Wayne K. Werner" <wkwerner@con2.com>
wrote:

>
>> 	Hooray!  Another advocate for C++!  I'd be interested what you
>> have to say about "getting" C++ to work for Net Yaroze (since it
>> doesn't seem to be so straightforward to do at this point), and while
>> I have experience coding in C++ and OO paradigm, I've never had to
>> worry about performance issues.  It'd be great to nail down those
>> aspects of C++ that supposedly make it "less efficient" and use OO
>> methods to create my game worlds.
>> 
>> Jamin
>
>There are several valid reasons that C++ is perceived as less efficient. 
>One is caused by pointers to base classes.  These require the use of
>virtual functions to make sure that the correct member function is called. 
>Virtual functions are stored in virtual call tables included as part of the
>object.  Result is larger code and slower calls done in a "behind the
>programmer's back" kind of way.  The solution? Avoid pointers to base
>classes and virtual functions.
>

	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?  :^(

>Another is caused by the heavy use of dynamic data in C++.  C++, in making
>dynamic memory easier to use has also made its use more prevelent.  Try to
>avoid the use of dynamic data in your designs where possible and
>investigate rolling your own new and delete operators where appropiate. 
>You know your data better than the compiler does, and you can often do a
>better job of allocation than your compiler can.

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

>
>Yet another sore spot is in the creation of temporary variables.  By this I
>do not mean the automatic variables that are placed on the stack when you
>enter a function or block, but the unnamed variables that are created by
>the compiler, again, in a behind your back sort of way.  To avoid these
>problems pass references to functions, not actual objects (which would
>create a temp to pass by value).  Be careful to avoid automatic type
>conversions on your objects when assigning them or passing them to
>functions.  Beware of returning objects from functions.  Remember, temps
>are not just allocated in memory, but have constructors and destructors
>called on them too.

	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.

>
>Inline functions of both the global and member types can quickly cause code
>bloat.  Make sure that the benefits of inlining outweigh the costs before
>using it.  (Inlined functions are also much harder to debug than called
>functions.  I keep everything called and inline only towards the end of
>development, carefuly, in an effort to optimize.)

	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!  

>
>When you create an object file, the entire file is linked into your program
>if you access just a single data or function symbol in that object file. 
>If you use just one function out of a hundred, the full hundred still show
>up in your executable.  Since the whole idea of objects is to create
>reusable code, often objects have much more functionality than is used in a
>particular application.  But you usually get the whole bag anyway.  One
>solution is to create static link librarys when you create general use
>objects, and break up the source code into modules containing individual
>member functions.  The library makes a convenient way to keep the whole
>object together in one place while the fracturing of the code will prevent
>you from linking in more than you asked for.

	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.  :^)

>One more problem exists.  

	Has anyone got a C++ program made my CW yet?  I'm afraid I
might wait for the next version of CW...
 

>Everything should now be smooth as... well who am I kidding, it never goes
>smooth!

	:^)  Yup.

Jamin