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

[Jordi Gutiérrez Hermoso]

2011/10/10 Michael Goffioul <address@hidden>:
> 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.

People compile Octave on a lot more than just 32 and 64 bit Intel
architectures. At least on Debian, we compile it on 11 architectures
and counting (probably like 14 for the next Debian release).

>> 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).

Okay, I'll write this class within the next couple of days. Sorry
about the recompilation. I also fear Octave recompilations.

Unless jwe really objects and wants the other more general class
instead, but I don't really get all the details in my head about how
such a class should be made.

The whole point of such a class is to store pointers in graphics
objects, right? Do you see other long-term  benefits?

- Jordi G. H.