Re: Graphics properties as objects

[John W. Eaton]

On  6-Jan-2008, Michael Goffioul wrote:

| On 1/6/08, John W. Eaton <address@hidden> wrote:
| > Maybe I'm missing something fundamental, but I don't understand why
| > there would be a memory leak if the map contains values.  Can you give
| > a simple example that shows why that would happen?
| 
| It would not leak the "property" object, but the underlying "rep" field,
| which is a pointer. For fixed properties, that's not a problem, because
| the rep points to some field of graphics_object, so it will be destroyed
| with the containing object. However, for dynamic properties, this won't
| be the case. In my understanding, adding a dynamic property would
| be equivalent to something like:
| 
|     all_props["my_property"] = property (new string_property (...));
| 
| But you need someone responsible for deleting the string_property
| object. That's why I thought about reference counting, as used elsewhere
| in octave.

OK, I think my understanding of the problem is better now.

Can we hide some of the details so that we can write

  all_props.insert ("my_property", string_property (...));

?  I don't mind that the property class might need a series of
constructors like

  property (const color_property& p) : rep (new color_property (p)) { ... }
  property (const radio_property& p) : rep (new radio_property (p)) { ... }
  property (const string_property& p) : rep (new string_property (p)) { ... }
  ...

Also, I'd like to hide the following details in some way:

  property p (&string);
  p.increment_count_by_one ();
  xproperties.add (p);

So maybe we could write

  axes::properties::properties (const graphics_handle& mh,
                                const graphics_handle& p)
    : base_properties (go_name, mh, p),
      position (Matrix ()),
      ...
  {
    ...

    all_props.insert_static_property ("position", position);
    ...
  }

and have all the reference counting and address-of details hidden?

jwe