Constructor in SpiderLEM.cpp
Code:
SpiderLEM::SpiderLEM (OBJHANDLE hVessel, int flightmodel)
: VESSEL3 (hVessel, flightmodel)
[COLOR="Red"]: autopilot ()[/COLOR]
{
// Set starting values...
This is syntax error. You need to put colon only at the beginig of initialization list(notice there's already one there) and split the instructions with commas
Code:
SpiderLEM::SpiderLEM (OBJHANDLE hVessel, int flightmodel)
: VESSEL3 (hVessel, flightmodel), autopilot ()
{
// Set starting values...
for the constructor in LEM_AP.cpp all I have is...
Code:
LEM_AP::LEM_AP ()
{
LEM_AP::SyncVariables();
}
First when you're inside the class scope and the function or a member variable is not static then there's no need to use scope operator(LEM_AP:: ), but that's
just cosmetics.
Secondly, if SyncVariables() does what I think it does(synchronize some autopilot variables with their's SpiderLEM's counterparts), then there's gonna be a problem here, because SpiderLEM's ones won't be existing at this point(AFAIK) and you will have to move that function call after the point in code where SpiderLEM is being created.
So I was looking at various code samples and the way you've described is how Martins did it in the DG but for the ShuttleA he did something different.
He forward declares the "AttitudeReference" class in his ShuttleA.h and then in the ShuttleA.cpp he calls.
Code:
ShuttleA::ShuttleA (OBJHANDLE hObj, int fmodel)
: VESSEL3 (hObj, fmodel)
{
int i;
attref = new AttitudeReference (this);
...
That's the second option you can choose(the one with the pointer to object)
It seems a lot simpler than tacking extra ":" items onto the constructor.
Well, it isn't
, and also you have to trade the colon(which I already told you don't heve to put before every instruction in initiaizaton list) for the "new" operator
.
Is there a particular advantage or disadvantage to doing it this way?
As I've said, you choose one particular option(object or pointer to object) for the particular task/goal you want to acheave and in your case both options
are equally good. The difference will be after compilation process as the first way of doing it(using object as a class member) will result in embeding the
object code and data into dll and the second way(pointer to object) will result in allocating the object dynamically on the heap. Or simply speaking if you
create object in code explicitly
Code:
...
Class_of_objects object_instance;
..
then you get only this one and nothing more
and with pointer to object
Code:
...
Class_of_objects *pointer_to_object;
..
you have the ability to create objects in realtime when you need them and as many as you want if there's enough memory of course.
