Re: [Flightgear-devel] static variables

2002-06-18 Thread Jim Wilson 

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

Re: [Flightgear-devel] static variables

2002-06-18 Thread David Megginson 

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.

  vehicle n=0
   position
...
   /position
   orientation
...
   /orientation
   controls
...
   /controls
   ...
  /vehicle

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

2002-06-18 Thread Erik Hofman 

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