Graphics properties as objects

Michael Goffioul michael.goffioul at gmail.com
Tue Jan 8 09:08:42 CST 2008


On 1/8/08, Shai Ayal <shaiay at gmail.com> wrote:
> There are also other cases where access to the property is important
> -- e.g. in color_property, you should have access to the
> is_rgb/is_radio members and also it's nice to have access to the rgb
> member for easy conversion to the OpenGL 3dv type functions.

I know this. What I implicitely meant is that the genprops.awk would
generate *all* useful accessors. The color_property is probably the
most tricky one, but you could imagine to generate:

    bool color_is (const std::string& name) const
      { return color.is (name); }

    const double* get_color (void) const
      { return (color.is_rgb () ? color.rgb () : 0); }

> Together
> with making genprops more complicated, I think this is reason enough
> to provide direct access to the properties.

The main reason I tried this was to avoid calling copy ctor unnecessarily.
If the get_xxx methods return property objects by value, you'll call copy ctor
on each property access. If you access properties a lot while you're mainly
interested in their values, like in the backend, I considered it a waste of
CPU (I mean, if it can be avoided, why not?): copying a property includes
the value, the name, the parent, the hidden state, the list of listeners...
I saw 3 ways to avoid to much copying:
1) use more direct (but relevant) accessors, as I proposed
2) make get_xxx methods return const reference
3) each time you need a property a lot, store it in a local variable

Personally, I'm not pushing hard for the way I proposed, it's just a
proposal. I'm fine with the other possibilities.

Michael.


More information about the Octave-maintainers mailing list