help-octave
[Top][All Lists]
Advanced

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

Re: stroring pointers from oct-files


From: c.
Subject: Re: stroring pointers from oct-files
Date: Mon, 5 Nov 2012 07:48:45 +0100

On 4 Nov 2012, at 20:56, Olaf Till wrote:

> On Sun, Nov 04, 2012 at 08:20:20PM +0100, pantxo diribarne wrote:
>> 2012/11/4 Olaf Till <address@hidden>
>> 
>>> On Sun, Nov 04, 2012 at 06:55:47PM +0100, pantxo diribarne wrote:
>>>> Hello,
>>>> 
>>>> I use octave to comunicate with laboratory hardwares using modbus
>>> protocol
>>>> through tcp-ip. The modbus library I use (libmodbus:
>>> http://libmodbus.org/)
>>>> returns a pointer the modbus "context" variable and then uses this
>>> pointer
>>>> to access the server.
>>>> 
>>>> In octave I cast the adress of the pointer to an "int" type, so that I
>>> can
>>>> reuse that pointer for subsequent calls to one of modbus read/write
>>>> functions. I then have to free this pointer before exiting octave. Is it
>>>> the righ way to store pointers or is there a proper way to do that?
>>>> 
>>>> Pantxo
>>> 
>>> This could be related to a problem I have written some as yet private
>>> code for, but I'm not sure that I understand you right. Do you pass
>>> the casted pointer to user space (into a variable of the Octave
>>> interpreter)?
>> 
>> 
>> Right, and there are many functions (oct-files) that rely on that pointer.
>> The typical way I use those functions is :
>> octave:1> ctx = modbus_new_tcp ("127.0.0.1", 1502); #here ctx is an int
>> containing the adress of the pointer
>> octave:2> status = modbus_connect (ctx); #connect to the server
>> octave:3> #read/write data from/to the modbus server
>> octave:4> modbus_close(ctx); #disconnect
>> octave:5> modbus_free(ctx); #free the pointer
> 
> Simply passing the (casted) pointer to user space is certainly not the
> proper way, since users should not be able to crash Octave. Since the
> octfiles have no way to check the validity of the pointer, they would
> crash if the user passes a wrong pointer.
> 
>> To avoid passing the pointer to the interpreter I would have to do that
>> process (create/open/close/free) in each of the read/write functions
>> (oct-files).
> 
> If you have only one pointer per Octave session:
> 
> You could code all your functions within one oct-file and store the
> pointer in a static variable within that oct-file. Since Octave loads
> oct-files without setting the RTLD_GLOBAL flag, you can't easily do
> this with multiple oct-files; you would have to dlopen(...,
> ...|RTLD_GLOBAL) the file with the static variable explicitely.
> 
> If you could have a variable number of pointers per Octave session:
> 
> Octave AFAIK does not provide a way to store pointers. So you could,
> additionally to coding all your functions within one oct-file, provide
> a static std::map within this oct-file for storing
> pointers. Alternatively, you could use a package of mine which I could
> commit to Octave Forge if there is need. It explicitly loads (with
> dlopen(..., ...|RTLD_GLOBAL)) a global unique map and implements basic
> functions to store and retrieve pointers (casted to (void*)) for use
> by other packages or oct-files. Pointers are stored with a unique
> label for each pointer type, so if the wrong pointer type is used it
> is the oct-file-programmers fault, not the users.
> 
> I have not yet suggested to commit the package since my application
> for it is not ready to commit. I think ideally such functionality
> should be provided by Octave itself, but this does not seem to be
> important enough currently.
> 
> Olaf
> 
>> Pantxo

Alternatively you could define a new class derived from octave_value and store 
your pointer there.
examples are available in many octave-forge packages, for example:

main/instrument-control/src/i2c/i2c_class.h
main/instrument-control/src/parallel/parallel_class.h
main/instrument-control/src/serial/serial_class.h

or 

main/openmpi_ext/src/simple.h

HTH,
c.

reply via email to

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