[Opengc-devel] Re: [Flightgear-devel] Help on C++ Classes

[John W. <ca...@mm...>]

----- Original Message -----
From: "Damion Shelton" <dam...@ho...>
To: <fli...@fl...>; <ope...@li...>
Sent: Tuesday, October 23, 2001 4:43 PM
Subject: Re: [Flightgear-devel] Help on C++ Classes


> Hi...
>
> Maybe I can clarify a bit about the design of the ogcDataSource class.
> First, _all_ of the data members of ogcDataSource are public. This is
> intentionally "poor" design, but it makes life a lot easier since we won't
> need Get and Set functions for each of the potentially several hundred
> variables in the class.
>
> The OnIdle() function is called by the ogcApplication class once per
> rendering cycle, and "polls" the data source for fresh data, prior to
> ogcApplication entering the list of gauges and executing virtual render
> functions. So, your OnIdle() code should grab all relevant variables from
> FlightGear and store them locally (sounds like this is what you're trying
to
> do anyways).
>
> In the other data source, ogcFSUIPCDataSource, OnIdle() calls a FSUIPC
> library function which transfers a memory block from FS200x into an
internal
> array, and then extracts variables out of this array into the
ogcDataSource
> state variables. Again, it sounds like this is what you're trying to do
with
> FlightGear.
>
> > > On paper the idea looks like this.
> > > i.e // Opengc data_side = FlightGear data_side
> > >     ogcData.altitude ( or ogcData->altitude) =
> cur_fdm_state->get_Altitude;
> > >     ogcData.pitch = cur_fdm_state->get_Theta_deg()
> > >
> > > and so forth......
> >
> > This looks perfectly fine, actually.  You need parenthesis after
> > get_Altitude, but I'm sure that's just a typo.
>
> This looks fine to me also.
>
> > Not to be too glib, but 99% of the time, when someone complains about
> > getting "weird error messages", the answer can be found right there in
> > the text of the error message.  Compilers are obtuse sometimes, but
> > they don't lie.  Usually they mean what the say.  How about an example
> > of an error?  Are you sure the ogcData fields are accessible?  If
> > you're in a subclass, you still can't touch private data.
>
> This would be a concern, but all derived classes from ogcDataSource should
> use public derivation, and therefore have access to public members of the
> base class. My other two data sources worked without any problems (as far
as
> inheritance goes).
>
> > A better way would be for the OGC stuff to provide setBLAH() methods
> > (or an equivalent API) for your glue code to use.  Sticking FlightGear
> > internals right into the core of the OGC code strikes me as awfully
> > incestuous.
>
> As mentioned earlier, I've avoided get's and set's because of the
potential
> for bloated code. I assume gauge programmers are intelligent enough not go
> mucking around with datasource members when displaying gauges.
>
> I also don't see any problem with having the FGInterface object be a
member
> of ogcFGDataSource. In fact, I'd recommend it. Then, as you suggested,
each
> OnIdle() update would contain something like:
>
> pitch = FGInterface->GetPitch();
> roll = FGInterface->GetRoll();
> ...etc
>
> Keep in mind that since you're accessing public members from within the
> class itself, you don't need to preface the variable with the
> ogcFGDataSource class name (as in ogcFGDataSource.pitch). I don't know if
> this is how you were coding it or was just for the example. Feel free to
> directly email me the code if you want me to look over it.
>
> Anyways, glad to hear that you're making progress, even if it's
frustrating
> at times.
>
> -Damion-
>
> _______________________________________________
> Flightgear-devel mailing list
> Fli...@fl...
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>