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

[Damion S. <dam...@ho...>]

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-