Board index FlightGear Development

Changing behavior of SGPropertyNodes without tying

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Changing behavior of SGPropertyNodes without tying

Postby Philosopher » Mon Apr 08, 2013 3:51 pm

I've read about SGPropertyObjects and have seen examples of them being used. They look really nifty and I agree with the statement that tied properties should not be used (though I haven't read too much about the arguments). However, I've been considering the controls.cxx class; it uses them to limit property deflections. Besides the solution of introducing a "normalized" property type (which would not do much for us), what other solutions are there to limiting a property's value? There is, of course, the hack of listeners, but that is very reactionary and is bad in many ways. A better solution would be to create another class that handles behavior other than the standard method for setting and getting. I've been exploring this (if only in my mind) and I think I have a way to do this.

Let us first change the old SGPropertyNode class to better meet our ideas. Each of the raw setters/getters (the ones like get_bool that deal with the type of the node) should get an underscore and be made to be "private": these are now the raw variants. The new versions of those (named without the underscore) will be wrappers for them and will be declared "virtual", so that they can be overwritten by derived classes. For the SGPropertyNode class, these will be simple wrappers -- essentially the functions themselves. For derived classes, they will wrap them and also have special behavior "on top" of it: limiting, blocking, randomizing: anything! (all without tied nodes and preserving almost everything about the node.) The advantage is that these things become bi-liners (check-and-set) or tri-liners (check-change-and-set), etc., and they deal with the type of the node, versus the input type, so that if a node is only going to be a double, only that has to be overloaded. Additionally, a macro could be defined to overload all numeric types, so that something simple like limiting to +-1 could affect all get_type's with one line (though it might not make sense for non-doubles/non-floats).

Also, would it be possible to limit a derived class to only have one type? And unable to be tied? Maybe define an attribute for "do not change type" and set the type in the class:
Code: Select all
    int _attr=simgear::node::Type::DOUBLE


If we add support for these things, then we in theory just have to figure out how to initialize them, as all of the existing API including SGPropertyObjects should work. Maybe make an equivalent to Nasal's initNode() and give it a template to specify what SGPropertyNode-derived class to use?

Addendum: This is a re-post, I originally deleted it thinking that SGRawValue would do this, which it can, but that is actually a tied value and my solution is more elegant. I now realize that SGRawValue's are not what I want, so I am reposting this. One advantage is that these could easily be exposed to Nasal, so that it can define simple behavior changes for itself, besides the fact that there would obviously be ready-made limiting and wrapping classes with _min and _max.

P.S. One random thought: couldn't we compress the local stored value and tied/aliased pointers into one union, saving space? We don't necessarily have to change names, either, as an enum can be unnamed:
Code: Select all
  union {
    // The right kind of pointer...
    union {
      SGPropertyNode * alias;
      SGRaw* val;
    } _value;

    union {
      bool bool_val;
      int int_val;
      long long_val;
      float float_val;
      double double_val;
      char * string_val;
    } _local_val;
  };
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Changing behavior of SGPropertyNodes without tying

Postby Hooray » Fri Apr 12, 2013 11:15 am

An interesting mental challenge would be coming up with a proof-of-concept that completely depreciates tying in favor of PropertyObjects<>, while retaining full backwards compatibility (important for handling jsbsim), without having any significant performance impact: http://www.mail-archive.com/flightgear- ... 29521.html
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Changing behavior of SGPropertyNodes without tying

Postby Philosopher » Wed Apr 17, 2013 12:44 am

I think I could do that... Make a Coccinelle patch? ;)

Anyways, I'm going to revise my idea: I'll use pointers to getters/setters instead of a separate class. As I have proved I am a novice in C++ many times before, how do I pass the current node and/or make it available? Will I have to pass SGPropertyNode* this? Or is there some other way? Because if I were to pass it, I don't think I can declare a non-method function to be a "friend", so that would require making get_double et al public members, which is an ugly design hack unsuitable for the level of civilization present in modern FG source code ;). The only other idea that I have is to pass the current value by reference, i.e. as a T&, which should work but might not be good coding practice? Are there any other ideas that I am missing?

P.S. would an extra function call count as a performance impact? Also, if we can completely deprecate tying, then we actually wouldn't need the get_double et al, we could just use raw access, which I think would be a pro but could be a con given the number of member accessors that I see in FG (I'm saying that FG/C++ trends towards get/set methods unlike Nasal, where it works just fine to use raw access).
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm


Return to Development

Who is online

Users browsing this forum: No registered users and 8 guests