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>:
>> 2011/10/10 Michael Goffioul <address@hidden>:
>>> 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).
>
> I was not specifically targeting Intel. Out of curiosity, how many of these
> architectures at not 32 or 64 bits?

See for yourself:

    http://www.debian.org/ports/

The 32bit or 64bit distinction isn't enough to determine the size of a
pointer, I don't think. Maybe it is. I do know that the sizes of longs
and ints can vary a lot more than just the 32 vs 64 bit distinction.

>>> 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.
[snip]
> Though if it's only to be used for the graphics system, maybe I
> should just use an internal handle/object mapping as is done in the
> FLTK backend. It's a performance penalty, but is much more portable.

Well, it looks like there's already two places where it could be used?
So let's abstract this into its own class. I'll have it ready within a
couple of days.

- Jordi G. H.