On Monday 17 October 2011 14:46:12 ext Oswald Buddenhagen wrote: > On Sun, Oct 16, 2011 at 04:30:39PM +0200, ext Thiago Macieira wrote: > > When I talked to João this week, he expressed the desire to unify the > > header code of QVector, QByteArray and QString. > > > whether deriving from qvector makes sense i don't know, but i'm very > much in favor of implementing QString and QByteArray as > QStringBase<QChar> and QStringBase<QByte>. for compatibility, data() > would have to continue to return QChar* resp. uchar*, but more unified > access could be granted via array() (or wrappedData()) (returning QChar* > resp. QByte*) and optionally podArray() (or podData()) (returning > ushort* resp. uchar*).
Not sure. This somehow smells a bit like an "Ivory Tower" kind of thing to me. Making the interfaces "mostly identical" would certainly be nice. Templating the whole code (and potentially even put everything into the header because "someone perhaps might want QStringBase<float>" at some time) looks significantly less interesting to me, especially as a simple "typedef QStringBase<QChar> QString;" would break all existing code that has forward declarations of QString and therefore the "try hard to stay source compatible" promise. I also _do_ like the fact that a QByteArray is reported as QByteArray by the usual suspects and not something similar to std::basic_string<char, std::char_traits<char>, std::allocator<char> > Having templated code to work on QString and QByteArray (and things like regexps actually might want to) is possible also with two plain classes. Andre' _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
