Review Request 118016: Fix wrong constructor resolution

[Thomas Lübking]

> On May 6, 2014, 1:30 p.m., Kevin Ottens wrote:
> > AFAICT it is BIC but no SIC, no brainer.
> 
> Martin Gräßlin wrote:
>     it's a SIC change as one could have used the variant specifying just NET::Properties and screen. This would now have to be changed to use NET::Properties2 before screen argument.
> 
> Thomas Lübking wrote:
>     It's SIC.
>     "NETRootInfo(connection, properties, 1);" would now cause an error, but since it's been buggy anyway (enums are indeed not polymorphic, but for int,... though gcc could have known better) that should hardly matter.
>     
>     @Marco
>     got that with gcc or clang? And which version and what specific call?
>     The constructor is (theoretically) correctly resolvable and if it's an ambiguous call, i'd expect a compiler error as well...
> 
> Kevin Ottens wrote:
>     Ah I see. Hm, is it very much used outside of the workspace?
> 
> Martin Gräßlin wrote:
>     > is it very much used outside of the workspace?
>     
>     probably not and ftr the ctors are SIC anyway compared to 4.x as it's now based on xcb
> 
> Kevin Ottens wrote:
>     I stand by my "ship it!" then.
> 
> Marco Martin wrote:
>     @Thomas: gcc 4.7.2 on opensuse
>     the error happens for instance in the virtual desktop KCM
>     NETRootInfo info(QX11Info::connection(), NET::NumberOfDesktops | NET::DesktopNames, NET::WM2DesktopLayout);
>     
>     NET::WM2DesktopLayout gets passed as screen
> 
> Thomas Lübking wrote:
>     Ahh...
>     
>           "You're holding it wrongly"™ ;-)
>     
>     typeof(NET::NumberOfDesktops | NET::DesktopNames) == typeof(int)
>     
>     NET::Property has no Q_DECLARE_OPERATORS_FOR_FLAGS (at least i don't see them) and thus "|" is the integer operator and the result is - integer.
>     
>     calling
>     NETRootInfo info(QX11Info::connection(), static_cast<NET::Property>(NET::NumberOfDesktops | NET::DesktopNames), NET::WM2DesktopLayout);
>     
>     should get you the correct result (but scratching the duplicated code is oc. fine anyway =)
> 
> Marco Martin wrote:
>     yes, it does have Q_DECLARE_OPERATORS_FOR_FLAGS in the end of netwm_def.h
>     both Properties and Properties2
>     
>     anyways, the problem is the last parameter, NET::WM2DesktopLayout that even if not or-ed, it gets casted as int anyways
> 
> Thomas Lübking wrote:
>     It's actually seems a bug in Q_DECLARE_FLAGS / QFlags, for this does *not* happen w/
>     
>     -------------------
>     
>     #include <stdio.h>
>     
>     enum Foo { Foo1, Foo2 };
>     enum Bar { Bar1, Bar2 };
>     
>     void fooBar(Foo foo, Bar bar, int i = 5)
>     {
>         printf("foo bar int\n");
>     }
>     
>     void fooBar(Foo foo, int i = 5)
>     {
>         printf("foo int\n");
>     }
>     
>     int main(int, char **)
>     {
>         fooBar(Foo1, Bar1);
>         fooBar(Foo1, Bar1|Bar2);
>     }
>     
>     ---------------------------
>     
>     which prints (as can be expected)
>     
>      foo bar int
>      foo int
>     
>     
>     but it *does* happen w/
>     
>     -------------------------
>     
>     #include <stdio.h>
>     #include <QFlags>
>     
>     enum Foo { Foo1, Foo2 };
>     enum Bar { Bar1, Bar2 };
>     
>     Q_DECLARE_FLAGS(Foos, Foo)
>     Q_DECLARE_OPERATORS_FOR_FLAGS(Foos)
>     Q_DECLARE_FLAGS(Bars, Bar)
>     Q_DECLARE_OPERATORS_FOR_FLAGS(Bars)
>     
>     void fooBar(Foos foo, Bars bar, int i = 5)
>     {
>         printf("foo bar int\n");
>     }
>     
>     void fooBar(Foos foo, int i = 5)
>     {
>         printf("foo int\n");
>     }
>     
>     int main(int, char **)
>     {
>         fooBar(Foo1, Bar1);
>         fooBar(Foo1, Bar1|Bar2);
>     }
>     
>     --------------------
>     
>     which prints
>     
>      foo int
>      foo bar int
>     
>     
>     IOW, QFlags maintains type safety for operated enums/flags, but *not* for singleton ones.
> 
> Thomas Lübking wrote:
>     https://bugreports.qt-project.org/browse/QTBUG-38810
> 
> Marco Martin wrote:
>     So it seems is a known problem and there is nothing that can be done.
>     for now is pushed, if there are problems with it, can be changed/reverted for an handful of days still

- i'm fine w/ the patch anyway (Qt fix or not, it was broken, so SIC doesn't matter - plus it removes a bunch of LOC)
- "nothing can be done" does not exist in my language ;-)
- could frameworks already use c++11 strongly typed enums?


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118016/#review57407
-----------------------------------------------------------


On May 6, 2014, 8:08 p.m., Marco Martin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118016/
> -----------------------------------------------------------
> 
> (Updated May 6, 2014, 8:08 p.m.)
> 
> 
> Review request for KDE Frameworks and kwin.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> -------
> 
> when the constructor
> NETRootInfo(xcb_connection_t *connection, NET::Properties properties, NET::Properties2 properties2,
>                 int screen = -1, bool doActivate = true);
> 
> gets called, NET::Properties2 gets casted as int and the other constructor
> 
> NETRootInfo(xcb_connection_t *connection, NET::Properties properties, int screen = -1, bool doActivate = true)
> 
> is called instead.
> 
> This patch merges the two constructors, fixing all the users of the first one
> 
> 
> Diffs
> -----
> 
>   autotests/netrootinfotestwm.cpp da7dcea 
>   src/netwm.h 7cbf2ab 
>   src/netwm.cpp a0e9105 
> 
> Diff: https://git.reviewboard.kde.org/r/118016/diff/
> 
> 
> Testing
> -------
> 
> screen and doActivate parameter weren't used by any, so all the currently ported software still builds and works correctly
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140506/6d33bae9/attachment.html>