Re: [Flightgear-devel] static variables
David Megginson wrote: > information available at a single glance. The alternative is to use > the multi-process model rather than a multi-thread model, and to swap > entire property trees in and out like memory pages; we'll certainly > avoid a lot of bugs that way (because the wrong properties simply > won't be available). > > What does everyone else think? In projects like these I like to think multi-process could simplify things quite a bit. But I'v seen that perfomance wise it is sometimes better to use some kind of threading (pthread/state-thread). E.g. look at Apache (fortunately FlightGear is nowhere near the socket demands of Apache :-) ). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] static variables
Jim Wilson writes: > That's what I meant. Thanks for the example. BTW what would be > the application of property tree swapping, as opposed to say the > method that the view manager uses? Curt and I have discussed this before (either online or offline). We could certainly have per-vehicle subtrees, i.e. ... ... ... ... and so on, and that would let us share some common, sim-wide information at the top level, and would make all program-wide information available at a single glance. The alternative is to use the multi-process model rather than a multi-thread model, and to swap entire property trees in and out like memory pages; we'll certainly avoid a lot of bugs that way (because the wrong properties simply won't be available). What does everyone else think? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] static variables
That's what I meant. Thanks for the example. BTW what would be the
application of property tree swapping, as opposed to say the method that the
view manager uses? It sounds like we could have to put a lot more data into
the tree only for the sake of swapability, and that there could be further
debugging issues as well. Just thinking we should see a real dramatic benifit
here, before doing something so elegant :-)
Best,
Jim
David Megginson <[EMAIL PROTECTED]> said:
> Curtis L. Olson writes:
>
> > The original intent of writing the code this way was to do the
> > expensive fgGetNode() call which does string compares, hash table
> > lookup, etc. just once, then cache the resulting pointer to the actual
> > node so that subsequent references to this property element can bypass
> > the expensive lookup and just do a quick pointer dereference. As I
> > recall, you were the one that suggested this approach.
>
> My suggestion was to store it as an instance variable, i.e.
>
> class Foo
> {
> public:
> Foo ();
> // ...
> private:
> SGPropertyNode * _lon_node;
> };
>
> then
>
> Foo::Foo ()
> : _lon(fgGetNode("/position/longitude-deg", true))
> {
> }
>
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
