Re: QtHandles: Qt-based toolkit with uicontrol/uipanel support

[Michael Goffioul]

2011/10/10 Jordi Gutiérrez Hermoso <address@hidden>:
> I was talking about jwe in #octave about this whole business, and
> frankly, I think these OCTAVE_PTR_TYPE macros are a very ugly
> solution. Casting pointers to integers and back is highly nonportable
> and error-prone.

I admit this is not very elegant, but this was the most straightforward
solution. Storing/retrieving pointers is localised in a single file and not
exposed outside of it. There was code to support 32bits and 64bits
platform, which probably consists of all relevant platforms for octave.
So indeed, it's doesn't look very nice, but without that required macros
for C++, it would have worked fine for everyone. And as recompiling
octave on my platform takes ages, I tend to reduce changes to octave
as much as possible.

That being said, any other/better solution is fine for me. The point here
is that I wanted to avoid yet another object lookup (e.g. I could have chosen
a handle/ObjectProcy mapping instead). There are already a lot of them
and they tend to increase exponentially.

> If this is going to be part of Octave, why not patch
> Octave instead? Would you be happy with an octave_ptr<T> class derived
> from octave_value? It would give you T* pointers. jwe was thinking of
> a more general class, octave_mem or something like that, which simply
> holds a chunk of memory.

octave_ptr<T> would fine. octave_mem can be viewed as octave_ptr<void>.
Besides the graphics system, such object might be useful when implementing
wrappers for external libraries in octave (where you often need to
hold a pointer
to a foreign object).

> I think it's a better solution than trying to second-guess
> architectures with CPP.

Agreed.

Michael.