list so users of the phone book can call list methods on it
that's generally considered a bad thing to do

and my C will be the object that will connect all other classes, such as thread, timer, acceptor..

definitely don't use inheritance then
just make a public method getT() or getWhatever()

jcc, i read, using composite is often slower than inheritance in java (http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=3)
this doesn't apply to c++?

are you profiling your application and have found that this relationship is a performance hit?
if you aren't, then you are optimizing prematurely

this is not true
it's a design problem
not premature optimizations

well, i haven't profiled .. just design phase..
well it's not actually my design, my supervisor's design, and i'm trying to verify if his choice is correct or not

the article on the page is mentioning legitimate reasons to use composition
Apple is-a Fruit

well yes

if you could be more specific about what these interfaces represent I could be more specific
it is generally teh case that representing has-a with composition is bad
but it is not true in all cases
the object you're speaking about is the primary, top-level controller of your game, right?

yes

so I'm guessing it has a ton of sub-objects like…
getParticleSystem(), getPhysicsSystem(), getNetworkSystem(), etc.
a bunch of things like that

http://gcc.gnu.org/ml/gcc/2005-06/msg00199.html
not sure how to go about that, any tips?

if that's the case, you _definitely_ don't want to implement those relationships with composition. definitely keep them behind "get this interface" methods
krunk-|work, you mean the ISO standard document?

don't use composition in that case?

(ANSI just adopted the ISO document for C++ 98)

sorry i don't understand 'definitely keep them.. ' part

then, yep, the ISO. Let me search for that

pcompassi, what I mean is that if your game object exposes many things like NetworkSystem, PhysicsSystem, etc., then definitely DO NOT derive from each of those objects
definitely provide those objects to users of the game object via get-methods
there are many many reasons not to derive
for example
let's say NetworkSystem is just an interface
it has some abstract methods for sending data to other computers
then, there might be _more than one implementation_ of NetworkInterface
there might be a TCPNetworkSystem, or a UDPNetworkSystem, or something for LANs

ok

if NetworkSystem is an interface, and there are multiple possible implementations, then which one does your GameObject derive from?
there is no clear choice
obviously, the game object just HAS-A network system, the particular implementation to be decided at compile time
if GameObject has a mehtod getNetworkSystem(), then the GameObject has the ability to work with different NetworkSystems at runtime

currently, we have both system inherited

perhaps if the player says "Join an Internet game" then GameObject.getNetworkSystem() returns a TCPNetworkSystem
or if he says "Join LAN game" then it returns (thereafter) LANNetworkSystem
the point is that, any time you have a general interface with multiple possible implementations, and your Primary Object has a HAS-A relationship with this interface, composition is totally inapprorpiate

you mean inheritance is
?
inappropriate part

at least in the language of the article you pointed me to

!give walkover std