Menu
▾
▴
Re: [simspark-devel] APL Design
|
From: Ing. M. B. <mar...@gm...> - 2009-11-13 17:36:48
|
Hi Andreas.
I'm not guru in Simspark like you or Hedayat :) . But if you have a problem
with multiple inheritance, try this >>>
class Top {};
class Fork : public Top {};
class LeftBranch : virtual public Fork {}; //word virtual
class RightBranch : virtual public Fork {}; //word virtual
class Bottom : public LeftBranch, public RightBranch {};
Now, if you create instance of class Bottom >>>
Top* instance = new Bottom;
compiler get no error.
Best Regards
Marian
-----Original Message-----
From: ah...@un... [mailto:ah...@un...]
Sent: Friday, November 13, 2009 4:20 AM
To: sim...@li...
Subject: Re: [simspark-devel] APL Design
Hi,
> Sorry, would you please present an example of required diamond
> inheritance?
class Top {};
class Fork : public Top {};
class LeftBranch : public Fork {};
class RightBranch : public Fork {};
class Bottom : public LeftBranch, public RightBranch {};
In this case, Bottom is derived from Fork twice, once via LeftBranch and
once via RightBranch. This works in C++. However, when you write:
Top* instance = new Bottom();
You get a compiler error because Top is an ambigious base class of Bottom.
Simspark wants to do something like
zeitgeist::Object* = new Body();
and you get the same error at this point. You should be able to reproduce
it by deriving BoxCollider from both Collider and ODEObject in the current
version. It's nonsense, but it leads to ODEObject and everything above it
being ambigious base classes of BoxCollider.
> I wonder why abstract physics classes should be derived
> from BaseNode.
In order to add an instance of a class to the scenegraph, it has to be
derived from BaseNode. That's written in the documentation at some point.
This doesn't mean that the abstract classes have to be derived from there,
though. I tried an approach that derives the non-abstract classes from
BaseNode in a seperate tree and keeps the abstract classes as interfaces
and pointer-providers that aren't derived from anything. This, however,
gets very ugly because patterns like
boost::shared_ptr<Body> body = [...];
[...] body->GetSelf() [...]
can be found in many places outside of oxygen. GetSelf is specified in
zeitgeist, so if the inheritance from Body to BaseNode is cut, GetSelf
isn't known to Body anymore. Figuring out a design that derives Body from
BaseNode is by far the easiest solution to that problem.
I hope this answers your questions.
----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Simspark Generic Physical MAS Simulator
simspark-devel mailing list
sim...@li...
https://lists.sourceforge.net/lists/listinfo/simspark-devel
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4593 (20091110) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4593 (20091110) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
|
