On 2015-10-13 15:59, Jake Petroules wrote: > On Oct 13, 2015, at 1:46 PM, Marc Mutz wrote: >> 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. > > 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.
While I don't necessarily disagree with that article, I think that the points being made are orthogonal to what Marc is proposing. The idea of QStringView would, I presume, be similar to that of std::string_view; namely, to provide an abstraction over a bag of "characters" (using that term rather loosely). It does NOT in any way relate to doing any sort of operations (besides slicing) on a "string". The idea is to be able to inexpensively pass around "text", whether it comes from QString, QStringRef, wchar_t*, or what have you, without having to perform superfluous memory allocations to convert to One True Form (i.e. QString) when the consumer doesn't actually care. That said... I note that slots probably still need to take QString, because a queued call with a QStringView is horribly broken (for reasons which I hope are obvious). At least unless the event dispatcher is clever enough to promote these to QString in the event. -- Matthew _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development