Path: chuka.playstation.co.uk!news1.scei.co.jp!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: 2 Jul 1997 03:55:19 GMT
Organization: SCEA Net Yaroze News
Lines: 104
Message-ID: <01bc869b$d2a65420$6fbf43ce@wkwerner>
References: <01bc8513$4e939960$9fbf43ce@wkwerner> <33b95c29.25784289@news.scea.sony.com>
NNTP-Posting-Host: port11.con2.com
X-Newsreader: Microsoft Internet News 4.70.1155


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

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.

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.

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

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.

I am sure I could think of more, but this is enough to chew on for now.  As
for using the playstation library in C++, you need to use linkage
specifiers to make sure that your calls to the C functions are not mangled
(look into any C++ primer to learn about mangled function names and type
safe linkage.)  Edit the playstation header file to contain the following
lines at the top and bottom:

	#ifdef __cplusplus
	extern "C" {
	#endif

		// the rest of the header goes here

	#ifdef __cplusplus
	}
	#endif

One more problem exists.  The library contains a function called delete. 
delete is a C++ keyword.  If you do not need to use delete, simply comment
it out.  If you do need to use it, things get a little more hairy.  delete
is used to delete files.  It has the following prototype in the header:

	int delete(char *name);

Replace this line with:

	int file_delete(char *name);

You now need to create a C source code file that looks like this:

	#include "libps.h"
	
	int delete(char *name);

	int file_delete(char *name){

		return delete(name);
	}

Either link the resultant object file from this with your project or add
this to the playstation library.  When calling delete from now on, use
file_delete instead.
Everything should now be smooth as... well who am I kidding, it never goes
smooth!

Enough for tonight, I've got to be at work by 7!

Wayne