Re: Passed by reference for an octave_value type storing an

[c.]

Hi Olaf,

On 11 Nov 2012, at 19:00, address@hidden wrote:

> Message: 2
> Date: Sun, 11 Nov 2012 14:58:05 +0100
> From: Olaf Till <address@hidden>
> To: Octave Maintainers <address@hidden>
> Subject: Passed by reference for an octave_value type storing an
>       external        resource?
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi,
> 
> by this post
> 
> https://mailman.cae.wisc.edu/pipermail/help-octave/2012-November/054991.html
> 
> I learned that there are Octave Forge packages storing external
> resources (e.g. descriptors for open serial, parallel, or i2c devices)
> in classes derived from octave_base_value hooked into
> octave_value.rep, which are then passed to user space as Octave
> variables of a newly created type. These Octave variables are then
> used as arguments providing the descriptor to various user-called
> functions of the package. Example:
> 
> octave-forge/main/i2c/serial/serial_class.h, /serial_class.cc,
> /serial.c, /srl_close.cc.

I cannot find the path you mention above, I guess you refer to files in the 
directory
octave-forge/main/instrument-control/src/serial/
right?

> To keep track whether the resource is open or closed, the returned
> value of .get_rep() of the passed octave_value is casted to non-const
> with a C-style cast and then a change is made within .rep (e.g. in
> srl_close.cc).
> JWE, when I suggested the latter for a previous attempt of yours to
> treat Comedi-related resources conceptually similar to the above
> package, you discouraged casting away const this way.
> 
> (thread: 
> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2008-November/013305.html)

Recently I gave a short presentation about Octave in a seminar in my department 
at Politecnico di Milano [1,2]
Partly inspired by recent discussion in the thread mentioned above and partly 
because of questions about this 
topic by some colleagues, one of the examples in the slides (myobject.{cc,h}) 
is about bypassing Octave's pass-by-value
semantics.

There I'm using statements like 

const myobject mo  (static_cast<const myobject&> (args(0).get_rep ()));

which does not cast away const. 


> But what is the actual danger in it, as long as
> 
> - users can't change values of this type except using functions
>  provided by the package,
> 
> - functions provided by the package never make copies, but make each
>  change within the existing .rep?
> 
> (I'm trying to achieve an agreement on a strategical suggestion for
> such problems.)
> 
> Olaf

c.


[1] PDF:  http://jordi.platinum.linux.pl/octave/what-is-octave.pdf
[2] LaTeX sources:  http://inversethought.com/hg/what-is-octave/