octave-maintainers
[Top][All Lists]
Advanced

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

Re: Question about sharing data structure in octave


From: Jaroslav Hajek
Subject: Re: Question about sharing data structure in octave
Date: Fri, 27 Jun 2008 21:14:43 +0200

On Fri, Jun 27, 2008 at 5:43 PM, Michael Goffioul
<address@hidden> wrote:
> Hi,
>
> I would like to request some comments about the best way to
> implement shared data structure in octave. What I'm thinking
> about is to have a C++ object that I want to make accessible
> from the interpreter, through some octave_base_value inherited
> class. At the interpreter level, I want this data structure to act
> as a reference/pointer, not as a value: assigning to another
> variable would share the same data structure without copying
> it. This means in fine to use some reference counting. Now the
> question is where to implement this mechanism:
>
> 1) octave_value uses sharing mechanism with its internal
> octave_base_value representation; so I could inherit from
> octave_base_value and implement my C++ data structure
> in it, using implicitly the octave_value reference counting.
> However, what I don't know is the situation where octave_value
> decides to clone/copy itself: it must do so, because by
> default octave deals with values and not references
>
An octave_base_value is cloned if one of assign methods is invoked on one of
multiple octave_value objects that reference it.


> 2) define 2 classes: one pure C++ to hold my data structure
> and is reference-counted, and one class inheriting from
> octave_base_value that contains the pure C++ object and
> handle the reference counting. This decouples completely
> the sharing mechanism with the one from octave_value,
> but increases the complexity and number of classes/objects
>

This is how may of the current octave_base_value descendants work. For instance,
octave_matrix inherits the reference counting mechanism from octave_base_value,
but also holds a matrix that is itself reference-counted. So I'd say go ahead.



> So, any comment about this?
> Thanks.
>
> Michael.
>



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

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