Hi im trying to come up with an object system for a game engine and i was looking at David Eberly's Game Engine Architecture book for ideas. In it he reinvents the wheel for his system and creates his own object class and an RTTI class for static class info, he also creats his own smart Pointer class which automatically increments and decrements a reference counter inside each object pointed too. My question is is reinventing the wheel like this a common practice for game engines and even development in general as i would like to use off the shelf libs such as boosts smart pointer and inbuild RTTI system in c++. Is it recommended to use c++ inbuilt RTTI system as i havent any experience with it and most of my experience is with Java. ive so many questions ;)

thats another thing from the book actually he defines his own container classes so he can use his more specific ones when only a small set is required for example. he outlines an example of a triangle mesh where he was storing adjacentcy info using STL containers and when he replaced those STL's with a custom drop in replacement he saved about 50% memory wise and a small speed up aswell.

Does this have to be done or can the STL containers be restricted to usage in a small set situation where you know you wont have more that say 8 elements??

Quote:Original post by Preacher
he outlines an example of a triangle mesh where he was storing adjacentcy info using STL containers and when he replaced those STL's with a custom drop in replacement he saved about 50% memory wise and a small speed up aswell.

Don't quote me on this but i've read about this in the forums before and somebody said it was std::set being compared against a dynamic array for efficiency of implementation, which is a pretty useless comparisons besides. In anycase all the standard library containers are parameterized by allocator type so you can provide custom memory models/schemes with it.

There are so many misconceptions & false myths about the C++ standard library & RTTI system provided by the language itself, this is due to a number of reasons:

• lack advance C++ knowledge (i'm serious)


• Old popular C++ compilers (such as VC++ 6.0 being the main culprit) that have very poor standard compliance and poorly implementated standard library. This gives the completely wrong impression.


• Do not know how to use a standard library component effectively & efficently


• Use & compare the wrong container/algorithm for the job


• Only profile one poor implementation and assume every implemenatation of the C++ standard is the same

The list goes on and on.

Once i took the doom 3 SDK out of curiosity to profile some of there custom container against VC++ 7.1/8.0 imp of standard library containers. i tell you one thing even before i started i instantly saw floors in the there code compared to how the standard libraries are typically implementated on most modern C++ compilers (yes i'm sad i study standard library implementations all the time but i have learned alot from it). Guess what out of the containers where there was an anagloue of in the standard library in release mode VC++ 7.1/8.0's imp typically pwned Doom 3 sdk custom containers in efficency, i must admit it was a very brief profile but none the less. I'll assume the reason why Doom 3 wrote there own because:

1. They probably did profiling on VC++ 6.0/7.0 only.


2. They completely replaced the memory manager with they own custom solution which sort of makes up for efficiency but the standard library containers are parameterized by allocator type anyways.


3. Other reasons not related to preformance as everyone may think.

So i advice you to use the standard library & RTTI provided by the language itself, only write something custom when you've actually profiled a need for it don't make silly assumptions if you do you are most definitely going to reinvent mediocre wheels that are squared shaped. On modern C++ compilers, you'll be hard-pressed to out-do compiler vendors with many years of experience, own a copy of the C++ standard, know advance tricks & idioms that i can safely say you don't know about. So please enough with the one off squared shaped wheels already [grin].

Quote:Original post by Preacher
Does this have to be done or can the STL containers be restricted to usage in a small set situation where you know you wont have more that say 8 elements??

As i said before all standard library containers are parametized by allocator type its very simple to write/use your own, by the way boost libraries has 2 STL compliant custom allocator types both of which are pooled allocators.

[Edited by - snk_kid on August 8, 2005 12:28:24 PM]

In Game Programming Gems2 there is a chapter on creating a DTI (dynamic type information ) class for doing RTTI.
One of its features is that you can store a pointer to the parent type. Can this be done with the standard RTTI? It also mentions that the DTI class can be enhanced to support mulitple inheritance. Is this also something that the standard RTTI supports?
I was just wondering since I have also been pondering the question of reinventing the wheel vs. using standard features at least as far as RTTI is concerned.

Quote:Original post by gtdelarosa
One of its features is that you can store a pointer to the parent type. Can this be done with the standard RTTI?

dynamic_cast can answer most of your dynamic/inheritance type queries. You can think of dynamic_cast as your little directed acyclic graph (DAG) type travserer.

std::type_info is your type identifiers for every-time type not just a few select user-defined types. Its a non-intrusive solution where a constant reference is obtained via operator typeid an amortized constant time operation, works a compile & run-time and in most cases without the need of RTTI enabled.

Not only is the language support for RTTI non-intrusive its extendable and that doesn't just mean extending std::type_info (which you can do of course).

Quote:Original post by gtdelarosa
It also mentions that the DTI class can be enhanced to support mulitple inheritance. Is this also something that the standard RTTI supports?

RTTI Language support handles multiple, virtual, and even mixed inheritance hierarchies.

Quote:Original post by gtdelarosa
I was just wondering since I have also been pondering the question of reinventing the wheel vs. using standard features at least as far as RTTI is concerned.

I'd say instead of wasting time extend the one provided by the language, write a custom solution when you've profiled a need for it.

The only downside of std::type_info::name returns an implementation-defined string; the string value is not standardized so its not portable between different compilers, its not so much of big deal really.

Quote:Original post by snk_kid
Don't quote me on this but i've read about this in the forums before and somebody said it was std::set being compared against a dynamic array for efficiency of implementation, which is a pretty useless comparisons besides.

You're quite right. Using Amazon.com's look inside feature, you can find the offending code on page 32.

Are there any specific sources you could recommend on custom allocators? I've found a few that seem to provide a good overview of the topic, but without any experience in the area it is hard to know how good they are.

CM

Quote:Original post by Conner McCloud
You're quite right. Using Amazon.com's look inside feature, you can find the offending code on page 32.

heh.

Quote:Original post by Conner McCloud
Are there any specific sources you could recommend on custom allocators? I've found a few that seem to provide a good overview of the topic, but without any experience in the area it is hard to know how good they are.

The one on GDC and the article in game programing gems 3 seems to be okay, you've probably seen them already.

Another options is to take a peek at your compilers implementation, on GCC they have something like 4-6 custom allocator types [grin].

[EDIT] link to different allocator types available in GCC

Nice one thanks snk_kid its nice to get straight answers as i said im just moving from a beginner level knowledge of c++ so ive a long way to go, its ceratinly a more involved language than Java thats for sure ;)

Yea your right about the example it was using sets and i defo feel that eberly is rewritting code a little to quickly and he gave no reason for not using c++ native RTTI system actually he didn't even mention the option existed but otherwise im learning a lot from the book.

Im using visual studio 2005 beta for development i presume that MS has sorted out most of its STL issues by now and i hear its the most compatable implementation of c++, but then again thats just hear say.

So im just going to continue on as you suggested and use off the shelf components such as boost and native c++ RTTI i'd be much more confident doing that anyway!

Thanks for all the advice ;)

Quote:Original post by Preacher
Im using visual studio 2005 beta for development i presume that MS has sorted out most of its STL issues by now and i hear its the most compatable implementation of c++, but then again thats just hear say.

VC++ 7.1 & 8.0 are both 98% standard C++ compliant and both have fine implementations of the standard library though it appears that 8.0 is abit better than 7.1 as they have improved it further, for e.g. std::vector::clear in 8.0 has been improved.