On Tuesday February 21 2012, Thiago Macieira wrote: > On terça-feira, 21 de fevereiro de 2012 08.24.52, Samuel Rødal wrote: > > Also, I guess we'll want convenience functions "QRectD QRectF::toRectD() > > const" etc. Can that be done with the typedefs proposed above, or does > > it require having "QRectD QRectD::toRectD() const" as well? > > With some template magic it can be done.
That simply being full template specialisation? That'd duplicate quite some code, though, yes. > If you write: > template <class t> class QBasicRect; > typedef QBasicRect<float> QRectF; > typedef QBasicRect<double> QRectD; > > Then you can't specialise QBasicRect<float or double> anymore. You can only > use the default expansion or partial specialisations that are yet to be > written. That means it's easier to add an "constexpr inline QRectD > toRectD() const;" to all classes than to just the float and integer ones. > > But someone really motivated can add more magic using QEnableIf. Specialising toRectD() to not appear in QRectD would force the same specialisation on generic code. So my feeling is that if there's a QBasicRect<>, then it should contain QBasicRect<T> toBasicRect<T>() const and convenience functions for all the existing typedefs. A tangential question: should QRect be QBasicRect<int> (in which case it would probably have a class invariant of right()-left()==width() instead of width()-1 as now. If there is a plan to move to CRect semantics (not sure I'd like that), then keeping QRect and using QRectI = QBasicRect<int> could do the trick. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
