Tying a C++ pointer to an octave object

As part of my GSoC project, I am working on adding a classdef “Tiff” to octave that uses libtiff internally.

The constructor of the class needs to open a handle to the Tiff file being operated on so that the methods of the class can later operate on that handle. The issue I am facing is how to keep this pointer around and tie it to the octave object.

What I am doing now is I am converting the pointer to uint64_t and returning it as an octave_value to be stored as a property of the class.
Tiff.m (250 Bytes)
__open_tiff__.cc (484 Bytes)

I understand that this way may have some complications as the pointer isn’t always 64-bit across systems, and it is not a good idea to pass around memory addresses anyways.

I checked out __ftp__.cc and fileio.cc under libinterp/corefcn and both of them seem to use a mechanism defined by the interpreter for keeping the handles around that is not compatible with my use case and seems like an overkill for what I want.

So is there a simpler mechanism being used somewhere that I can follow. Or if I were to implement one myself, can it be done without modifying the interpreter?

I while back I tried to implement a class to read and write XML wrapped inside an Octave class:
bug #59245, Implementation of an XML interface without Java dependency

I didn’t end up liking it very much (mainly because of the .m file wrapper calling many .oct functions). But maybe some parts of it could still work as an example…
E.g., the octave_xml_node class stores a pointer to a rapidxml::xml_node<char>. That might be similar to what you are looking for.
It’s been some time since I was working on this. But I believe the idea was to have “initializer” DEFUNs that return objects of that new class (or of derived classes). IIRC, I wanted to keep these objects “alive” as a private property of the classdef that provides the user interface.

Most of this might not be necessary if you can avoid implementing an .m file “wrapper” classdef…

Maybe something similar could work for your implementation?

1 Like

I came across the same issue when trying to implement memmapfile where I did what you suggest:

retval(0) = octave_value ((uint64_t)addr);

I would be interested to hear if there was a better way.

I like this approach a lot. Although it is more work that I intended to do, it is very scalable as I can store any data about the Tiff files that don’t concern the Octave side without having to keep packing/unpacking them in octave values each function call. They can simply be members of this derived class and I only need to pass around an instance of that class.

However, I wonder if there are any design constraints to this approach. For example, can this be done as a dynamically loaded function not a core function as my classdef ideally should be an optional feature not a required one.

Beside mmuetzel’s approach, I found this old thread while searching around.

It suggests a way to return the pointer as an integer which accounts for the pointer size. And also suggests a way to return an integer handle using a global map. I am not entirely sure what considerations need to be taken in implementing the latter (for example to handle multithreading or to handle fragmentation/clashes when the number of instances increase).

I don’t think that approach is limited to liboctinterp. I’d guess it could be used in any library or .oct file.