[Kde-bindings] Qyoto: new features

[Dimitar Dobrev]

As far as I can see QFlags is used only on enums that support bitwise operation, i.e. that are defined as 1, 2, 4, 8, etc. So it is impossible to produce an invalid enum value using bitwise operations. As I said, QFlags exists only because C++ accepts an integer where an enum value is required thus violating type safety - a drawback C# does not have with its enums, that is, calling MyMethod(MyEnum myEnum) with an integer (or a short, long, etc.) fails to compile. So, if C++ enums were type-safe as C# enums, there would be no QFlags because it'd serve no purpose. And then the one difference between a working and a non-working flags enum would be that the first one is correctly (1, 2, 4...) defined.
Thank you for your opinion on the matter, I appreciate it. I also appreciate your sample implementations but I want the generated API to be, besides correct, as simple as possible.



________________________________
 From: Richard Dale <richard.dale at telefonica.net>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Monday, April 9, 2012 11:35 PM
Subject: Re: [Kde-bindings] Qyoto: new features
 

On Monday, April 09, 2012 01:27:35 PM Dimitar Dobrev wrote:

It works because while QFlags are not technically enums, they do nothing but provide type safety for C++ enums, that is, practically they are enums. On the C# side, enums are natively type-safe so it is completely correct to replace QFlags with Enum. 


Well no I don't think that's right. If you pass 'EnumA & EnumB' as a argument that value isn't an enum, it is an unsigned int. The QFlags stuff is about constructing unsigned ints from enums that are AND'd and OR'd together in a type safe manner.
 
-- Richard
_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20120410/09c53f6c/attachment.html>