Fr/SimGear: Difference between revisions

Bien entendu, nous faisons référence à OSG à de nombreuses rep^rises. Mais si je construis une application sur SimGear, j'espère y trouver des classes SimGear. SGProperties sont des classes SimGear, et si vous utilisez le système de propriétés, vous ne voudrez peut-être pas dépendre d'OSG.

... Egalement, d'expérience, en passant à un autre concepteur de scène, je préférerais ne voir aucune référence OSG:: .. Du tout dans l'équipement de vol - à l'exception de quelques trucs liés au spectateur. Mais la partie simulation de FlightGear ne devrait pas avoir besoin de savoir que la visionneuse fonctionne sur OSG/OpenGL. Donc, regarder SimGear comme une bibliothèque d'utilitaires pour les applications de simulation, cela a du sens de mon point de vue ...

That was done during the switch to osg and plenty of that work was almost only for that reason we have all the sg types directly spread around.  

So please avoid having osg::whatever spread around in the whole application.

More in detail for the reference counting. I do not like the referenced implementation of osg. That is already very heavyweight. Has some members we

do not need in any way in something simulation dependent. The observed_ptr stuff is not thread safe, also that observer implementation does not scale well if you have many observers. Referenced already has a vtable. Just to name a few ...

What we have is a very weak thing that could be used in the same basic way but is way more flexible even for smaller objects. I would prefer to keep that own implementation. The same goes for the osg vectors. They are neat, but inconsistent over the member types. Also the collision system is missing

there.

The rule of thumb when to use what is simple:

*If you are in the scene graph most probably osg::... might be a good thing to use.

not scene graph dependent, use simgears own classes.

Those places where this rule is broken is something I do not like either. As already told, I believe that it is not a good idea to tie a simulation to a

 

So I would not tell that a hard design goal. But If we can make that I believe  that we will get a benefit in doing so in the mid/long term.

When using std::tr1:shared_ptr you will need two allocations for a new object that is used with the the std::shared_ptr implementation - one for the object and one for the reference count. I like to use that SGReferenced stuff for many small lightweight objects that should not take to much time to create and should not take too much space. That kind of the solution is the most lightweight one I can think of.  

Also you can no longer work with raw pointers passed around and use the reference count included in the object since the shared_ptr implementation has

a separate count object. If you do so you will end up with two reference counts for the same object. The current implementation avoids that and make

raw pointer based apis if required.

So alltogether we have with the SG* version something that works equally well than the shared_ptr/weak_ptr pair and provides some extra features I would

like to have.

The SGAtomic counter could make use of the std::atomic at some point - if we add an additional case int the current implementation selection when we have

that available.

This could be done without loosing any of the features we have available in our current SharedPtr/WeakPtr implementation.

The only thing in tr1 is the shared_ptr/weak_ptr. I am Not sure what tr2 includes.

What I am missing in the intrusive pointer is a thread safe implementation of the weak_ptr. Note that we already have that in simgear ...

Not yet thought about that, but is there any chance to implement the weak_ptr semantics together with the intrusive_ptr?

{{note|If you do not require GUI functionality, the flag <code>-DSIMGEAR_HEADLESS</code> can be set to avoid having to pull [[OpenSceneGraph]] in as a dependency}}

Compilation of SimGear follows the fairly stupid standard procedure for building CMake projects.

==External Links==

==See also==

*[[TerraGear]]