[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Graphics properties as objects
From: |
Shai Ayal |
Subject: |
Re: Graphics properties as objects |
Date: |
Sat, 5 Jan 2008 19:03:17 +0200 |
On Jan 5, 2008 6:40 PM, John W. Eaton <address@hidden> wrote:
> On 4-Jan-2008, Michael Goffioul wrote:
>
>
> | On 1/4/08, John W. Eaton <address@hidden> wrote:
> | > I would really prefer to have the properties be objects instead of
> | > pointers to objects.
> | >
> | > What do you really need the map for?
> |
> | I think it significantly simplify any code that access properties
> | by name, because it provides a unified access.
> |
> | > Even if they are not stored in a map, all property types can still be
> | > derived from a base class that stores things like the hidden flag.
> |
> | Indeed, that's what I have for the moment. Actually, I just thought
> | about something else. Keep the property field as typed classes
> | in the nested "properties" classes (as it is now); keep the interface
> | "property" class (as I proposed) as unified access and for reference
> | count; store all properties in a std::map<caseless_str,property>,
> | but for fixed properties, artificially increment the internal count by
> | one to take into account the field use for direct access. That is
> | something like this:
> |
> | string_property string;
> |
> | const string_property& get_string (void) const { return string; }
> |
> | void set_string (const octave_value& v) { string = v; }
> |
> | and to store the property in the global map, do something like
> | (conceptually):
> |
> | property p (&string);
> | p.increment_count_by_one ();
> | xproperties.add (p);
> |
> | Would this be better?
>
> Is it even necessary to have the base class do reference counting
> here?
>
> Since the properties are tied to the graphics objects that contain
> them, shouldn't we only expect them to exist as long as the graphics
> object exists?
>
> If individual properties do need to exist longer than the graphics
> objects that contain them, then wouldn't it be sufficient to simply
> have a copy of the property? Aren't most (all) of the property
> classes composed of objects that are already reference counted? So
> copying them should be relatively cheap and since they are passed
> around by value, they should not be deleted unnecessarily?
>
> Why should get_string return a reference instead of a value?
Also, there is probably a typo there since I would expect it to return
an octave_value
Shai
Re: Graphics properties as objects, John W. Eaton, 2008/01/02
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/03
- Re: Graphics properties as objects, Shai Ayal, 2008/01/03
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/04
- Re: Graphics properties as objects, John W. Eaton, 2008/01/04
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/04
- Re: Graphics properties as objects, John W. Eaton, 2008/01/05
- Re: Graphics properties as objects,
Shai Ayal <=
- Re: Graphics properties as objects, John W. Eaton, 2008/01/05
- Re: Graphics properties as objects, Shai Ayal, 2008/01/05
Re: Graphics properties as objects, Michael Goffioul, 2008/01/05
Re: Graphics properties as objects, John Swensen, 2008/01/05
Re: Graphics properties as objects, John W. Eaton, 2008/01/05
Re: Graphics properties as objects, John W. Eaton, 2008/01/05
Re: Graphics properties as objects, Michael Goffioul, 2008/01/06
Re: Graphics properties as objects, John W. Eaton, 2008/01/06
Re: Graphics properties as objects, Michael Goffioul, 2008/01/06
Re: Graphics properties as objects, Michael Goffioul, 2008/01/08