On Wednesday 17 June 2015 20:32:48 Stephen Kelly wrote: > It seems that most people, but not everyone, in the discussion see the > inconsistency and there are good reasons that it is not a good thing.
I *do* see the inconsistency. I'm just not convinced that it *matters*. Paraphrasing Sharekspeare: What's in a name? that which we call a Qt3D::QTransform By any other name would work as well. IMHO, the fact that our implicitly-shared value types have an even chance of having or not having a move constructor[1] is something much more worrisome than the imminently bike-shaddable question of Qt3DTransform vs. Qt3D::QTransfom vs. Qt3D::Transform. People *will* deal with namespaces just fine - they've been doing so since the first C++ standard came out, incl. the transition from non-std:: to std::names - but they *cannot* tolarate the 10x (H. Hinnant) slowdown when resizing a vector<QFoo>, just because there's no QFoo move ctor or it's not marked as noexcept. [1] those that use a naked d-pointer have (inline) move ctors, those that use a smart d-pointer would have to define it out-of-line, thus the C++98/11 BC requirement makes it impossible to add them atm. Thanks, Marc -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
