[Development] changing Q_GADGET

Al-Khanji Louai louai.al-khanji at theqtcompany.com
Fri Nov 28 13:36:56 CET 2014


Out of the box, C++ makes class member declarations private. I quite strongly feel that changing that behavior in a macro is not what the user expects. So for me at least the "better API" box is not being checked here - I quite regularly declare private variables under Q_OBJECT and have done so with Q_GADGET as well.

-- Louai
 
> Hi,
> 
> Monsieur Goffart did awesome work in the dev branch on allowing
> structures with
> Q_GADGET to have properties and invokable methods. This brings the macro
> to a
> much wider audience and I'd like to use this opportunity to propose a slight
> change to it that may be controversial:
> 
> The macros Q_OBJECT and Q_GADGET both - towards the end of their
> definition -
> change the member access permission level to "private". It's always been
> that
> way.
> 
> I'd like to propose changing Q_GADGET to not change the access permission
> level, so that you can write
> 
> struct MyStructure
> {
>     Q_PROPERTY(int x MEMBER x)
>     Q_GADGET
> 
>     int x;
> }
> 
> 
> I feel that Q_GADGET has its primary use with structures and the default
> access level for those is public. I find it awkward that you currently have to
> write:
> 
> structure MyStructure
> {
>     Q_PROPERTY(int x MEMBER X)
>     Q_GADGET
> public:
>     int x;
> }
> 
> 
> The proposed change would have two effects:
> 
> 1) It makes any existing code that _relies_ on Q_GADGET turning to private
> suddenly expose members in structures.
> 
> 2) On paper it breaks binary compatibility with MSVC, in the unlikely event
> that somebody
>     a) produces a DLL and cares about binary compatibility
>     b) exposes bare structures
>     c) relies on Q_GADGET turning access permission levels to private
> 
> 
> I feel that the effects are negligible compared to the benefit of a better API.
> 
> What do you think?
> 
> 
> Simon
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list