[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Passed by reference for an octave_value type storing an external resourc
From: |
Olaf Till |
Subject: |
Passed by reference for an octave_value type storing an external resource? |
Date: |
Sun, 11 Nov 2012 14:58:05 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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.
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)
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
--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net
signature.asc
Description: Digital signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Passed by reference for an octave_value type storing an external resource?,
Olaf Till <=