I guess it's not by incidence that there's also a std::string_view coming, see e.g.
https://www.youtube.com/watch?v=H9gAaNRoon4 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html So, is this really the same, except non-templated and for QString (with conversion from/to Qt types)? Or do you have other differences in mind? Regards Kai > -----Original Message----- > From: development-bounces+kai.koehne=theqtcompany....@qt-project.org > [mailto:development-bounces+kai.koehne=theqtcompany....@qt-project.org] > On Behalf Of Marc Mutz > Sent: Tuesday, October 13, 2015 10:47 PM > To: development@qt-project.org > Subject: [Development] RFC: Proposal for a semi-radical change in Qt APIs > taking strings > > Hi, > > After looking quite a bit into the current state of string handling in Qt for > my > QtWS talk last week, I have become frustrated by the state of string handling > in > Qt. > > We have such powerful tools for string handling (QStringRef, QStringBuilder), > but all APIs outside QString and its immediate surroundings only deal in > QString. > The correct way would be to overload every function taking QString with > QLatin1String and QStringRef versions, and then, for some other rare cases, > const QChar *, int size. Let alone std::basic_string<char16_t>. > > I would therefore like to propose to abandon QString for new API (and over > time > phase it out of existing API), and only provide (const QChar*, size_t) as the > most > general form. I would propose to package the two into a class, called > - you guessed it - QStringView. > > =FAQ= > > Q: Why not just use QStringRef? > > A: QStringRef is tied to QString. E.g. you can't create a QStringRef from a > pair of > QChar*, int. It also is kind of stuck in historic mistakes making it > undesireable as > a cheap-to-pass parameter type. > > Q: What mistakes do you refer to? > > A: The fact that it has copy ctor and assignment operator, so it's not a > trivally- > copyable type and thus cannot efficiently passed by-value. It may also be too > large for pass-by-value due to the rather useless QString pointer (should have > been QStringData*, if any). Neither can be fixed before Qt 6. > > Q: Why size_t? > > A: The intent of QStringView (and std::experimental::string_view) is to act > as an > interface between modules written with different compilers and different > flags. > A std::string will never be compatible between compilers or even just > different > flags, but a simple struct {char*, size_t} will always be, by way of it's C > compatibility. > > So the goal is not just to accept QString, QStringRef, and (QChar*,int) (and > QVarLengthArray<QChar>!) as input to QStringView, but also > std::basic_string<char16_t> and std::vector<char16_t>. > > Q: What about the plans to make QString UTF-8-backed? > > A: QStringView-using code will need to be ported just as QString-using code > will. > > Q: What future do you have in mind for QStringRef? > > A: None in particular, though I have found a need for an owning QStringRef in > some places. But I expect Qt 6' QString to be able to provide a restricted > view on > shared data, such that it would subsume QStringRef completely. > > Q: What about QLatin1String? > > A: Once QString is backed by UTF-8, latin-1 ceases to be a special charset. We > might want something like QUsAsciiString, but it would just be a UTF-8 > string, so > it could be packed into QStringView. > > Q: What about QByteArray, QVector? > > A: I'm unsure about QByteArrayView. It might not pull its weight compared to > std::(experimental::)string_view, but I also note that we're currently > missing a > QByteArrayRef, so a QBAView might make sense while we wait for the std one > to become available to us. > > I'm actively opposed to a QArrayView, because I don't think it provides us > with > anything std::(experimental::)array_view doesn't already. > > Q: What about a rope? > > A: A rope is a more complex string that can provide complex views on existing > data as well as store rules for generating stretches of data (as opposed to > the > data itself). > > A rope is a very complex data structure and would not work as a universal > interface type. It would be cool if Qt had a rope, but that is outside the > scope of > my proposal. > > Q: What do you mean when you say "abandon QString"? > > A: I mean that functions should not take QStrings as arguments, but > QStringViews. Then users can transparently pass QString, QStringRef and any of > a number of other "string" types without overloading the function on each of > them. > > I do not mean to abandon QString, the class. Only QString, the interface type. > > Q: What API should QStringView have? > > A: Since it's mainly an interface type, it should have implicit conversions > from all > kinds of "string" types, but explicit conversion _to_ those string types. It > should > carry all the API from QString that can be implemented on just a (QChar*, > size_t) > (e.g. trimmed(), left(), mid(), section(), split(), but not append(), > replace() (except > maybe the (QChar,QChar) overload. > Corresponding QString/Ref API could (eventually) just forward to the > QStringView one. > > Thanks, now fire away, > Marc > > -- > Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB > (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
