Hi Lars, > * Is there a work-around for the developers with the current state, e.g. by > adding some casts?
There are two situations here: * those that control the creation of the QWaylandBufferRef objects can just choose to not make the LHS const, swapping RHS and LHS if need be (as all existing code must currently do, because it wouldn't compile otherwise) * those that don't control the creation of these objects (STL algorithms come to mind) would have to const_cast const away, and it's likely those which do won't understand that this may introduce UB > * Could you add the missing operators inline, so they don’t add new symbols? No. As explained in the initial email, as well as the BR and the Gerrit change, the problem is that we'd need at least the op==(const, const) overload out of line, because we can map all other operator overloads to that (by adding const). But we cannot remove const to call the existing member operator, that would be UB if the object was originally declared const. In addition, we'd first have to un-export the class, so that new inline members wouldn't be automatically exported (Windows only, don't know whether QtWaylandCompositor targets Windows at all). Did I mention we shouldn't export non-polymorphic classes wholesale, ever? I'm not sure. Consider it mentioned now 🙂 Adding the missing operator overloads as free functions (even if hidden friends) didn't work, probably because name lookup stops when it finds the member operators. If Windows is not a target for QtWaylandBufferRef, then I think I could add all missing operators as members with only op==(const, const) being out-of-line. That would be forward-BC for all code that wouldn't have caused a compile error in either C++17 or C++20 already. Actually, come to think of it, that's also a solution for Windows: un-export the class, then add these members. Thanks for rubber-ducking 🙂 Marc
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
