> On Oct 13, 2015, at 1:46 PM, Marc Mutz <marc.m...@kdab.com> wrote:
>
> 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
In general this sounds like a dangerous idea because it carries over all the
old API concepts (i.e. (QChar *, size_t) is an extremely broken abstraction).
You need to read and truly comprehend
https://developer.apple.com/swift/blog/?id=30 before suggesting any changes to
string-related APIs for the next major version of Qt, because if anything, THAT
is what it should look like. Anything but that is a near-useless wrapper around
binary data, not a true string class.
--
Jake Petroules - jake.petroules at petroules.com
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
