octave-maintainers
[Top][All Lists]
Advanced

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

Re: general c++ question


From: John W. Eaton
Subject: Re: general c++ question
Date: Mon, 27 Aug 2007 15:50:04 -0400

On  3-Jul-2007, Shai Ayal wrote:

| On 7/2/07, John W. Eaton <address@hidden> wrote:
| > On  2-Jul-2007, Shai Ayal wrote:
| >
| > | OK, so it seems this isn't possible (google also seems to say this).
| > | Unless there is some big objection, I will remove the nesting, i.e.
| > | class XXX_properties will not be nested in class XXX.
| >
| > Before you do that, can you please explain why do you need to declare
| > the function that returns properties before the property class has
| > been fully declared?
| 
| I thought of adding functions to access the individual XXX_properties
| classes, so the a back-end written in c++ could gain access to these.
| It seemed to me that the gh_manager class was a good place for these
| functions since it would allow gaining access to properties using only
| the handle. I though of using something similar to the ocave_value way
| -- add const XXX::XXX_properties& XXX_properties_value() functions
| However, all XXX_properties depend on base_property which in turn
| depends on gh_manager which means I have to forward-declare the
| XXX_properties before gh_manger. Since this is impossible to do with a
| nested class my solution was to un-nest XXX_properties from XXX

How about the following change instead?  This makes it possible to
move the declaration of gh_manager after all the graphics object types
have been declared.  If this change makes it possible for you to do
what you need with nested classes, then I propose that we also rename
the properties classes so that they are just figure::properties
instead of figure::figure_properties (for example).

jwe


reply via email to

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