[Kde-bindings] Moving the Qyoto C# bindings from playground to kdebindings

[Phil Thompson]

On Thursday 12 April 2007 10:49 am, Richard Dale wrote:
> On Thursday 12 April 2007, Phil Thompson wrote:
> > On Wednesday 11 April 2007 11:27 pm, Arno Rehn wrote:
> > > Am Mittwoch, 11. April 2007 schrieb Richard Dale:
> > > > On Wednesday 11 April 2007, Richard Dale wrote:
> > > > > On Wednesday 11 April 2007, Arno Rehn wrote:
> > > > > > I found out about a little bug in the GetHashCode() stuff of the
> > > > > > Qyoto classes. When you call the method of certain classes, e.g.
> > > > > > QTextBlock, the whole app segfaults with no further output. I
> > > > > > would just return the real pointer to the underlying C++ object,
> > > > > > this would always be unique and would work, wouldn't it?
> > > > >
> > > > > Yes, that's exactly what I was intending it to do. But I was
> > > > > wondering about 64 bit pointers though, if the hash is an int.
> > > >
> > > > Just been looking in the Qt libs, and there's a qHash() function in
> > > > the QHash class that takes a ulong and returns a uint:
> > > >
> > > > inline uint qHash(ulong key)
> > > > {
> > > >     if (sizeof(ulong) > sizeof(uint)) {
> > > >         return uint((key >> (8 * sizeof(uint) - 1)) ^ key);
> > > >     } else {
> > > >         return uint(key);
> > > >     }
> > > > }
> > > >
> > > > So maybe calling that on the C++ pointer would be good enough.
> > >
> > > Yes, that looks good.
> >
> > Note that this isn't reliable - you can have any number of different
> > (nested) data structures at the same address. I think I've only ever seen
> > it happen once in Qt (Qt v2.x I think) but it was a nasty bug to track
> > down.
>
> That sounds nasty. I'm not actually sure what the C# runtime does with the
> hash values though. They need to be reimplemented for classes that
> have 'operator==' methods in them, but in the Qyoto binding the Qt method
> will be called to do the comparison, and the result won't have anything to
> do with the hash value. We use the C++ pointer as a key into a map of
> corresponding C# instances, and so the problem with Qt 2.x would affect
> that too.

PyQt does the same thing. It goes one extra step in looking at the type of the 
object in the map and compares it with the type it is expecting to find. 
Again, not perfect (it can still be fooled) but it just makes it that less 
likely to happen in a real situation.

Phil