On 11/06/15 16:33, "Marc Mutz" <[email protected]> wrote: >On Thursday 11 June 2015 13:43:15 Knoll Lars wrote: >> Well, QSslEllipticCurve is problematic IMO. The class only contains one >> int and accesses it inline. Since we might have other backends than >> openssl implementing this in the future, I’d like have this non inline >>and >> a qint64 as data type (so we could replace it with a d pointer later on >>if >> required). > >Please read the discussion on https://codereview.qt-project.org/94022 > >TL;DR: >There will never be more than a few dozen elliptic curves. They will >never be >mutable. So their state can be kept in a read-only location with the int >indexing into it. > >The urge to hide everything behind a d-pointer is strong in Qt, but here, >it >makes no sense.
Ok for me. Just wanted to make sure we’re all fine with this. > >> The presharedkey authenticator is missing a copy constructor taking a >> rvalue ref, but that’s minor and can be fixed BC in 5.6 as well. > >Can't have an inline move ctor, as it's using QSharedDataPointer. Can't >have >an out-of-line move ctor, since that's currently forbidden. Maybe in 5.6, >if >we require rvalue refs. > >BTW: Can someone send a summary of Qt 5.6 vs. C++11 to the ML, for those >that >couldn't attend? The short summary (full one will hopefully still come from whoever took notes): Compiler wise we’ll have VS2012 and gcc 4.7 as a baseline. It’s ok to use the C++11 language features supported by these compilers unconditionally in Qt (both in headers and implementations). This also means we can remove some ifdefs for rvalue refs, Q_DECL_OVERRIDE etc. Some care is still required when using STL features that might cause BC issues for us. Cheers, Lars _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
