octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Graphics properties as objects


From: Michael Goffioul
Subject: Re: Graphics properties as objects
Date: Tue, 8 Jan 2008 16:08:42 +0100

On 1/8/08, Shai Ayal <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]