Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Friday 16 October 2015 19:03:18 Marc Mutz wrote: > The problem is that I feel we can't wait for string_view because we already > drown in QString equivalents. Plus, we'd get the usual replies if anyone > suggested to use std::string_view as such a fundamental Qt type. Naturally, > QStringView would trivially convert to and from std::u16string_view with no > runtime overhead (unless compiler writers ruin the concept of string_view > by implementing it as (T*, size_t) in one compiler and (T*, T*) in > another) The conversion from one to the other is one instruction. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Friday 16 October 2015 19:31:50 Thiago Macieira wrote: > The conversion from one to the other is one instruction. Which is one instruction too much for tail-call optimisation, e.g. But the point was about std::string_view binary compatibility. As basically a C struct with no ownership semantics, it would be a perfect vehicle to pass strings around different programming languages and compilers, but only if the ABI (ie. the data members) were specified. -- Marc Mutz| 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
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Marc, It is clear that your main concern is performance (needless conversions) and convenience (being able to work efficiently with 3rd party libraries). Regarding performance, I think it would be good if we could come up with some numbers. How 'bad' is the current implementation compared to an 'ideal' situation? And then define some acceptable target keeping into account convenience. Otherwise I am afraid that discussions can keep going forever over 1 instruction more or less. Regarding convenience, and that is what Qt is all about, I think you made a tremendous proposal that can really bring Qt a big step forward. The idea is very sound and clear. Of course, there are technical challenges, but that is what we are supposed to solve. I also agree that we should aim for simplicity. QString and QStringView is simple to understand, iff we can get rid of all other string related classes. The ideal case would be just to have one QString class, although I doubt that is achievable. I think it would be good to come up with some real-world use-cases that show how a Qt user and a Qt application could benefit from your proposal. Personally, I never experienced a performance problem with QString; but then the applications I write are not very string oriented. I am a QString aficionado :-) After all, what I really like about Qt is convenience, simplicity and portability. I think this should be the main focus of Qt, and that also implies smooth collaboration with the outside world. Cheers, Kurt > On 16 Oct 2015, at 21:47, Marc Mutzwrote: > >> On Friday 16 October 2015 19:31:50 Thiago Macieira wrote: >> The conversion from one to the other is one instruction. > > Which is one instruction too much for tail-call optimisation, e.g. > > But the point was about std::string_view binary compatibility. As basically a > C struct with no ownership semantics, it would be a perfect vehicle to pass > strings around different programming languages and compilers, but only if the > ABI (ie. the data members) were specified. > > -- > Marc Mutz | 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
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Then after we add QStringView, we will have QString for containing a string and QStringView for passing its contents out of Qt? martin From: m...@kdab.comon behalf of Marc Mutz Sent: Friday, October 16, 2015 10:07 AM To: Smith Martin Cc: development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings On Friday 16 October 2015 07:59:40 Smith Martin wrote: > Can you refocus the discussion for everyone? For me at least? > > QString is my favorite class of all time. I use it every day in every > program; it always works, and I never make a mistake. Then you can continue to be blissfully ignorant of reality as you are :) If you are a QString fanboy and don't care about 3rd-party code and/or efficiency, then you can just continue as before. > 1. What is the problem with QString that QStringView will solve? TL;DR: Inefficient conversion from/to QString, leading to inefficiencies within pure Qt-code and in particular when interfacing with 3rd-party code, BiC issues, > 2. Why can't QString be fixed? Because it is a container, not an interface type. An interface type needs to be BC across most of compilers and languages (incl. C and - potentially Java). A container needs to handle (as in own) memory. An interface type (quite obviously, if it's to work with C, too) cannot. > 3. What is a string view? A pimped { QChar *begin, QChar *end; } Thanks, Marc -- Marc Mutz | 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
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
> On Oct 16, 2015, at 9:10 AM, Poenitz Andre> wrote: > > > Marc Mutz wrote: >>> I think too we should embrace the standard library more and don't replicate >>> their features. >> >> So you think that QStringView is too experimental and _at the same time_ >> replicating the standard. Sounds paradoxal to me. > > It's not paradoxical at all. It would be a new implementation with the usual > need for maturing even if it implements a well-known standard concepts. > > And there is indeed room for actual experiments, e.g. when it comes > structure layout. Pointer+int offset is not the only possible choice. > > You cannot do that in Qt proper, due to BC promises. And there would also be some room in Qt Creator to experiment with and gather experience on how all this fits with corresponding API changes, which I also do not see how that could be done in Qt without lots of #ifdefs. > Compile-time opt-in > is a way to exempt it from BC, but then your main reason to have it in Qt > and not in Creator, namely 'more widespread use', is void, as barely anyone > will opt in. You'll get more public exposure (with less risk!) if it's used by > default in Creator code for a while before the then-matured implementation > goes to the library. > > Andre' > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On October 16, 2015 08:53:33 Marc Mutzwrote: > On Friday 16 October 2015 01:32:26 Bubke Marco wrote: >> On October 16, 2015 00:20:22 Marc Mutz wrote: >> > Guys, this thread is for QStringView. Could we keep it on-topic, please? >> > There are more than enough bits floating around to create your own >> > threads (with a tip of the hat to Kai). >> >> Good argument but actually I think before we introduce something new to our >> string handling we should test it out. Why not add it Qt creator like >> André proposed and see how it works. > > I have already answered why I think this is a bad idea. Yes, I read it. That why I proposed the experimental playground. It is not so much about QStringView but about the following changes. What is so bad about to play around features before we see all the implications. My experiences whisper to me that if I like an idea too much I should be careful because I love to ignore unpleasant side effects. >> I think we don't want to end with something like our model view system or >> QtControls. Lets test it before we make changes. >> >> I think too we should embrace the standard library more and don't replicate >> their features. > > So you think that QStringView is too experimental and _at the same time_ > replicating the standard. Sounds paradoxal to me. Is it already in the standard? The standard has an experimental stage too. And I like this concept very much. >> A better process to add features would be helpful too. First they should >> be experimental so we can change them easily. Second we should be better >> at removing features. If we do not remove things we will getting slower >> and slower to add new interesting stuff. It is hard to find the balance >> but if you are too conservative you will getting slowly less used. We >> tried to be very innovative with Qml and we learned much about it. >> >> So the question is how can we maximize the usefulness of Qt with our man >> power. Is replicating the standard library really helping? > > My stance on replicating std functionality and the NIH syndrome should by now > be above suspicion, even for the casual reader. It was not about you or me. It was about us an organization. How we can work better together. How can we make a difference, how can we help other developers. > I have already argued why I think QStringView is needed, but QArrayView is > not. Sorry if you got the impression it was about you. I should be more careful with my arguments. I try to disconnect arguments from the self. I thinking the argument should stand for himself in his context and not so much by the person who speaks it. To make it clear, I find QStringView promising but still we should explore the concept with all their implications more. Actually I think we sould add more of this kind of changes in an experimental stage like #include . So we are forced to evaluate for every release how it works out and if it looks well we move it to the normal include path. So experimental would be an area in every repository so that everybody could try it out. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Friday 16 October 2015 01:32:26 Bubke Marco wrote: > On October 16, 2015 00:20:22 Marc Mutzwrote: > > Guys, this thread is for QStringView. Could we keep it on-topic, please? > > There are more than enough bits floating around to create your own > > threads (with a tip of the hat to Kai). > > Good argument but actually I think before we introduce something new to our > string handling we should test it out. Why not add it Qt creator like > André proposed and see how it works. I have already answered why I think this is a bad idea. > I think we don't want to end with something like our model view system or > QtControls. Lets test it before we make changes. > > I think too we should embrace the standard library more and don't replicate > their features. So you think that QStringView is too experimental and _at the same time_ replicating the standard. Sounds paradoxal to me. > A better process to add features would be helpful too. First they should > be experimental so we can change them easily. Second we should be better > at removing features. If we do not remove things we will getting slower > and slower to add new interesting stuff. It is hard to find the balance > but if you are too conservative you will getting slowly less used. We > tried to be very innovative with Qml and we learned much about it. > > So the question is how can we maximize the usefulness of Qt with our man > power. Is replicating the standard library really helping? My stance on replicating std functionality and the NIH syndrome should by now be above suspicion, even for the casual reader. I have already argued why I think QStringView is needed, but QArrayView is not. Thanks, Marc -- Marc Mutz | 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
Re: [Development] Updating the minimal supported version of libxcb
On 15/10/15 17:59, "Thiago Macieira"wrote: >On Thursday 15 October 2015 18:26:23 Александр Волков wrote: >> Hi, >> >> Currently Qt supports libxcb 1.5, which is very old (it was released on >> December 3, 2009) >> It complicates adding new bundled xcb libraries, because they have to be >> checked >> for compatibility with this old version and maybe patched. >> >> Qt officially supports the following platforms that use libxcb: >> OpenSuSE 13.1 (libxcb 1.9.1, xcb-proto 1.8) >> Red Hat Enterprise Linux 6.6 (libxcb 1.9, xcb-proto 1.8) >> Ubuntu 14.04 - 64bit (libxcb 1.10, xcb-proto 1.10) >> >> What do you think about updating the minimal supported version of libxcb >> to 1.9? > >Unless it's critical, let's do it only in 5.7. Yes, I don’t know of larger issues that would require a change in 5.6. But for 5.7 by all means go ahead and update the minimum requirement to 1.9. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Marc Mutz wrote: > > I think too we should embrace the standard library more and don't replicate > > their features. > > So you think that QStringView is too experimental and _at the same time_ > replicating the standard. Sounds paradoxal to me. It's not paradoxical at all. It would be a new implementation with the usual need for maturing even if it implements a well-known standard concepts. And there is indeed room for actual experiments, e.g. when it comes structure layout. Pointer+int offset is not the only possible choice. You cannot do that in Qt proper, due to BC promises. Compile-time opt-in is a way to exempt it from BC, but then your main reason to have it in Qt and not in Creator, namely 'more widespread use', is void, as barely anyone will opt in. You'll get more public exposure (with less risk!) if it's used by default in Creator code for a while before the then-matured implementation goes to the library. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Allan Jensen as maintainer for Qt WebEngine
+1 On 10/15/2015 11:25 AM, Koehne Kai wrote: > Hi, > > I hereby nominate Allan Jensen as the official maintainer for the Qt > WebEngine module. He's been the official maintainer for Qt WebKit already, > but nowadays works full time on Qt WebEngine, and is also the default > assignee for the WebEngine component in JIRA. > > Regards > > Kai > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Outfit based collation (was: RFC: Proposal for a semi-radical change in Qt APIs taking strings)
Hi Marco, On 16/10/15 11:46, "Bubke Marco"wrote: > >>> That is the >>> power of iterators and with the new features of C++ they get really >>>useful. >>> But anyway, I don't say that we have to change everything. The last >>>time >>> we did that we broke our event system which is still not working like >>>it >>> was before we introduced QWindow. I think we should have an >>>evolutionary >>> process to adapt to the changing environment and not try to reiterate >>> what was successful in the past. >> >> I agree with what you said in this paragraph. But it does not lead to a >> conclusion about using UTF-8 or even providing our own UTF-8 class. >> > >Introducing an utf 8 class is not that hard but providing the framework >around. Collations are the problem. We have to use utf8 in QtCreator >anyway so we could find out what is an useful API. But colation support >in Qt would be really helpful in the longer run. The problem with Collation and utf-8 is that the only API offering utf-8 based collation is ICU (which offers both utf-8 and utf-16 based collation). Mac and Windows only offer utf-16. So we’d still need to convert in most cases. It would probably be possible to do that on the stack for small strings to avoid a malloc though. So we can discuss adding a QCollator::collateUtf8(const char *s1, int len1, const char *s2, int len2). But just out of curiosity, where does Creator need collation in a performance critical place? Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Outfit based collation (was: RFC: Proposal for a semi-radical change in Qt APIs taking strings)
Wow... I have no idea how my mail client autocorrected utf8 to Outfit. :) Cheers, Lars On 16/10/15 12:53, "Knoll Lars"wrote: >Hi Marco, > >On 16/10/15 11:46, "Bubke Marco" wrote: >> That is the power of iterators and with the new features of C++ they get really useful. But anyway, I don't say that we have to change everything. The last time we did that we broke our event system which is still not working like it was before we introduced QWindow. I think we should have an evolutionary process to adapt to the changing environment and not try to reiterate what was successful in the past. >>> >>> I agree with what you said in this paragraph. But it does not lead to a >>> conclusion about using UTF-8 or even providing our own UTF-8 class. >>> >> >>Introducing an utf 8 class is not that hard but providing the framework >>around. Collations are the problem. We have to use utf8 in QtCreator >>anyway so we could find out what is an useful API. But colation support >>in Qt would be really helpful in the longer run. > >The problem with Collation and utf-8 is that the only API offering utf-8 >based collation is ICU (which offers both utf-8 and utf-16 based >collation). Mac and Windows only offer utf-16. > >So we’d still need to convert in most cases. It would probably be possible >to do that on the stack for small strings to avoid a malloc though. So we >can discuss adding a QCollator::collateUtf8(const char *s1, int len1, >const char *s2, int len2). > >But just out of curiosity, where does Creator need collation in a >performance critical place? > >Cheers, >Lars > >___ >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
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
> > > You're misrepresenting the argument. QString doesn't support other > encodings > > because UTF-16 is the best for the task at hand and we have too much > legacy to > > support. Because of that, QCollator only supports UTF-16. > > I buy the legacy argument but I don't buy that utf 16 is the best > encoding. I think because of legacy we cannot change QString but I think we > should still support UTF 8 better. > So what? This doesn't change the fact UTF-16 has advantages over UTF-8 and thus QString's backing storage is UTF-16 - and won't be changed to anything else. Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating the minimal supported version of libxcb
16.10.2015 09:28, Knoll Lars пишет: > On 15/10/15 17:59, "Thiago Macieira"wrote: > >> On Thursday 15 October 2015 18:26:23 Александр Волков wrote: >>> Hi, >>> >>> Currently Qt supports libxcb 1.5, which is very old (it was released on >>> December 3, 2009) >>> It complicates adding new bundled xcb libraries, because they have to be >>> checked >>> for compatibility with this old version and maybe patched. >>> >>> Qt officially supports the following platforms that use libxcb: >>> OpenSuSE 13.1 (libxcb 1.9.1, xcb-proto 1.8) >>> Red Hat Enterprise Linux 6.6 (libxcb 1.9, xcb-proto 1.8) >>> Ubuntu 14.04 - 64bit (libxcb 1.10, xcb-proto 1.10) >>> >>> What do you think about updating the minimal supported version of libxcb >>> to 1.9? >> Unless it's critical, let's do it only in 5.7. > Yes, I don’t know of larger issues that would require a change in 5.6. But > for 5.7 by all means go ahead and update the minimum requirement to 1.9. Another question is what to do with the bundled libraries? With libxcb 1.9 they are all provided by the supported distros. The only exception is xcb-xkb, which we require to be from libxcb 1.10. So my proposal is to remove them from Qt, remove configure options -qt-xcb and -system-xcb, and use the bundled xcb-xkb library if we can't find the appropriate version on the system. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Back to the topic. Marc, what usecases of QStringView are not covered with QString { ushort* data; int size; QStringData *refcount; } Not sure i understand that "interface" terminology. Would it be possible to pass QStringView to other (non-qt) APIs? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Friday 16 October 2015 09:53:56 Smith Martin wrote: > Then after we add QStringView, we will have QString for containing a string > and QStringView for passing its contents out of Qt? Yes, except for "out of Qt". We already have - within Qt - lots of equivalent ways to provide a QChar-based string - and QString is only one (QStringRef and QVarLengthArray are others, as is QChar[]). As I said before, this is very similar to Q(Persistent)ModelIndex - QMI is the interface type, and it's transparent to the compiler and thus efficient to work with. QPMI is the storage type, intransparent to the compiler and very slow to work with. HTH, Marc -- Marc Mutz| 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
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Friday 16 October 2015 13:28:57 Иван Комиссаров wrote: > Back to the topic. > Marc, what usecases of QStringView are not covered with QString { ushort* > data; int size; QStringData *refcount; } > Not sure i understand that "interface" terminology. Would it be possible to > pass QStringView to other (non-qt) APIs? See my mail to Martin today. While not the first reason to create a QStringView, yes, a (ushort*, ushort*) can allow zero-copy string transfer between at least C, C++ and Java, possibly also JavaScript. So it may have a direct benefit for QML, though I don't know that code at all. Thanks, Marc -- Marc Mutz| 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
Re: [Development] Qt 5.6.0 header diff: QtWidgets.diff
On Monday 21 September 2015 11:05:52 Knoll Lars wrote: > QDesktopWidget::primaryScreenChanged signal > -> IMO this should be added as NOTIFY to the corresponding property. The signal is missing the int argument int primaryScreen() -> primaryScreenChanged(int), not: primaryScreenChanged() -- Marc Mutz| 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
Re: [Development] Updating the minimal supported version of libxcb
> Another question is what to do with the bundled libraries? The -qt-xcb switch is there to reduce run-time dependencies. There always will be somebody who wants to run the latest Qt version on some old linux distribution. Also I think it was decided that in Qt5 we can remove support for -no-x11extenssion-name switches in the Qt configure script. There is always -qt-xcb available if your distro does not provide the required dependencies. And it does not add any value not to compile-in the extension code. It should be a runtime decision, if X server has an extension available, we use it. From: development-bounces+gatis.paeglis=theqtcompany@qt-project.orgon behalf of Александр Волков Sent: Friday, October 16, 2015 2:02 PM To: Knoll Lars; Thiago Macieira; development@qt-project.org Subject: Re: [Development] Updating the minimal supported version of libxcb 16.10.2015 09:28, Knoll Lars пишет: > On 15/10/15 17:59, "Thiago Macieira" wrote: > >> On Thursday 15 October 2015 18:26:23 Александр Волков wrote: >>> Hi, >>> >>> Currently Qt supports libxcb 1.5, which is very old (it was released on >>> December 3, 2009) >>> It complicates adding new bundled xcb libraries, because they have to be >>> checked >>> for compatibility with this old version and maybe patched. >>> >>> Qt officially supports the following platforms that use libxcb: >>> OpenSuSE 13.1 (libxcb 1.9.1, xcb-proto 1.8) >>> Red Hat Enterprise Linux 6.6 (libxcb 1.9, xcb-proto 1.8) >>> Ubuntu 14.04 - 64bit (libxcb 1.10, xcb-proto 1.10) >>> >>> What do you think about updating the minimal supported version of libxcb >>> to 1.9? >> Unless it's critical, let's do it only in 5.7. > Yes, I don’t know of larger issues that would require a change in 5.6. But > for 5.7 by all means go ahead and update the minimum requirement to 1.9. Another question is what to do with the bundled libraries? With libxcb 1.9 they are all provided by the supported distros. The only exception is xcb-xkb, which we require to be from libxcb 1.10. So my proposal is to remove them from Qt, remove configure options -qt-xcb and -system-xcb, and use the bundled xcb-xkb library if we can't find the appropriate version on the system. ___ 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
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
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. > > 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!) as input to QStringView, but also > std::basic_string and std::vector. > > 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(),
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Friday 16 October 2015 17:03:41 Koehne Kai wrote: > 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? Nothing qualitatively different. Just std::basic_string_view with a subset of QString API, yes. The problem is that I feel we can't wait for string_view because we already drown in QString equivalents. Plus, we'd get the usual replies if anyone suggested to use std::string_view as such a fundamental Qt type. Naturally, QStringView would trivially convert to and from std::u16string_view with no runtime overhead (unless compiler writers ruin the concept of string_view by implementing it as (T*, size_t) in one compiler and (T*, T*) in another) Thanks, Marc -- Marc Mutz| 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
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Saturday 17 October 2015 01:18:06 Marc Mutz wrote: > If you need a real-world example of where QStringView would be handy: Some > 3rd-party code returns you a char16_t *path, and you want to perform a > QDir::cd(). Currently, you need to create a QString (which allocates). Had > QDir::cd() taken a QStringView, you wouldn't have that allocation. Bad example. You can use QString::fromRawData. While that today allocates the d pointer, for Qt 6 it wouldn't (null d pointer) and there would be no code change for the user. There is, however, the danger of fromRawData: you need to be sure the called function won't try to store the QString. With a QStringView or the unsharable QString that Brano proposed in the other email, it would be clear that a deep copy needs to happen. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Thiago described Qt6 QString as { QArrayData *d; ushort* b; qsize size }. That is pretty close to QStringView, just extra *d makes it slightly bigger. This is how I understand this class: QString will have (typical) case when b points into d. QString own one reference in d in this case. QString will have special case when b points to text section and d does not own anything. QString will have special case for SSO. Can QString have special case for not owned, non persistent b pointer (non-owning / view mode)? Non-owning QString can be created with special static QString method. It stays non-owning only while being passed through const &. Code that cares about keeping QString in view mode, must stick to const QString & all the time. Copy assignment on non-owning QString results in owning QString - it triggers deep copy into newly created shared data. It solves the queued connection problem that existed with QStringView class. I suppose that queued connection internally performs QString copy. I have no idea about performance implications for code paths that do not care about this use case. But having just one string class would be very convenient. Kind regards Brano ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Friday 16 October 2015 22:08:59 Branislav Katreniak wrote: > Thiago described Qt6 QString as { QArrayData *d; ushort* b; qsize size }. > That is pretty close to QStringView, just extra *d makes it slightly bigger. > > This is how I understand this class: > QString will have (typical) case when b points into d. QString own one > reference in d in this case. > QString will have special case when b points to text section and d does not > own anything. > QString will have special case for SSO. > > Can QString have special case for not owned, non persistent b pointer > (non-owning / view mode)? How is that different from your second case? If it doesn't own, it doesn't need a d pointer. > Non-owning QString can be created with special static QString method. It > stays non-owning only while being passed through const &. Code that cares > about keeping QString in view mode, must stick to const QString & all the > time. Copy assignment on non-owning QString results in owning QString - it > triggers deep copy into newly created shared data. Ok, I understand the difference, but why do you want this behaviour? BTW, this is the unsharable strings that we're getting rid of. This would make sense to view a string of ephemeral data. But if the data is ephemeral, why can't we use the refcounter? In other words, if someone owns this data, why isn't that QString? > It solves the queued connection problem that existed with QStringView > class. I suppose that queued connection internally performs QString copy. True, but I think that having QString share refcount of substrings solves the problem that QStringView was proposed for in the first place. > I have no idea about performance implications for code paths that do not > care about this use case. But having just one string class would be very > convenient. That is the problem. That's the reason we're trying to get rid of unsharable containers: performance impact on the code paths that don't need it, which are the majority of cases. There are two possibilities for the unsharable flag: 1) it's inside the d pointer, which means the d pointer must be non-null. That means even the non-owning QString needs to allocate memory for the d pointer block. 2) it's outside the d pointer, which means that a) it doesn't need to allocate memory b) we need to extend QString to be: { QArrayData *d; ushort *b; qsize size; int flags; } (24 bytes if qsize is 32-bit on 64-bit platforms; 32 if it is 64-bit; always 16 bytes on 32-bit platforms) Either way, the existence of the flag means that every QString copy-assignment needs to check this flag, instead of simply incrementing the refcount if d is not null and being done with it. That means code bloat for the deep copy showing up everywhere. I really don't want the unsharable flag. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: Change in qt/qtbase[5.6]: Make the C++11 atomic support the default, if available
FYI Please report any issues you have with broken compilers that did not implement std::atomic properly. I'd like to include them in the release notes. These are already known to fail, so please don't report them: - Xcode 5.0's clang compiler says it supports constexpr but doesn't - ICC on OS X has a broken header that misses some casts Those compilers are now blacklisted in C++11 mode. For Qt 5.6, you can pass the configure option -std=c++98 or -no-c++11 and you'll be able to use them. They will not be supported in Qt 5.7, so please schedule your upgrade before the 5.7 release. -- Forwarded Message -- Qt CI Bot has approved a build with this change and it was merged. Change subject: Make the C++11 atomic support the default, if available .. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Kurt, The mail you're replying to has nothing to do with QStringView. It was a tangent about std::string_view. If you need a real-world example of where QStringView would be handy: Some 3rd-party code returns you a char16_t *path, and you want to perform a QDir::cd(). Currently, you need to create a QString (which allocates). Had QDir::cd() taken a QStringView, you wouldn't have that allocation. Another example I already mentioned: > E.g. local QStrings could be replaced by QVarLengthArray, > > e.g. in code like this: > QString joinstr = QLatin1String("\"\n"); > joinstr += indent; > joinstr += indent; > joinstr += QLatin1Char('"'); > > QString rc(QLatin1Char('"')); > rc += result.join(joinstr); > rc += QLatin1Char('"'); > > Even when replaced with QStringBuilder: > QString joinstr = QLatin1String("\"\n") + indent + indent > >+ QLatin1Char('"'); > > QString rc = QLatin1Char('"') + result.join(joinstr) + > QLatin1Char('"'); > > But the main benefit would be that we only ever need one overload for a > QString-taking function, not N, N > 3. Final with QStringView (and a minor modification to QStringBuilder): QVarLengthArray joinstr // doesn't alloc (for most 'indent's) = QLatin1String("\"\n") + indent + indent + QLatin1Char('"'); // in this line, QStringList::join() doesn't know about QVarLengthArray. // but it takes a QStringView and therefore transparently accepts QVLA QString rc = QLatin1Char('"') + result.join(joinstr) + QLatin1Char('"'); Please understand my POV: I am of the firm belief that Qt has no business creating inefficiencies for its users by sloppy implementation. Anywhere. We cannot know whether one user is calling QString::multiArg() in a tight loop. It might be dominating her runtime. 99.9% of users probably couldn't care less about QString::multiArg() performance. But we need to care about the 0.1%, because that number is much closer to 100% if you integrate it over all users' critical paths (iow: every Qt user will have *some* part of Qt that she wished was faster, heck, iirc KMail ran into QObject::connect as a bottleneck at some point in the past!). The inefficiencies I (and Sergio and Milian and, I'm happy to see, Friedemann, and others) care about are not ones you will find in a profiler in those 99.9% of cases, because they are not used in a critical path. But even for the 99.9% of users, if we make all of Qt 10% faster on average, their apps will run close to 10% faster, too. Automatically. So yes, I care about performance. I find it intolerable that todays software takes 1000x the memory, 1000x the CPU capacity and doesn't get a given jobs done in less wallclock time than software 20 years ago. And people don't use C++ because it's pretty. You cannot compete with Java on programmer efficiency. Its standard library is orders of magnitude larger than C++'s. People choose C++ (and accept the associated loss in programmer efficiency), because they require the bare metal efficiency of C++. And if Qt gets in the way, they will look for alternatives and find them in places that make Qt look like paradise. That said, QStringView is as much about - slim interface type vs. thick, fat, storage type - interop with 3rd-party and native code than it is about efficiency. Bottomline: I don't need a fancy anylysis to tell me that less allocations = faster programs = more happy Qt users. And please don't forget that QString fanboys can continue to massacre the heap if they so wish. After all, we've had QStringRef for a long time now, but most people still write str.mid(n).toInt() instead of str.midRef().toInt(). QStringView won't change that: A function taking QStringView accepts a QString, too (either by implicit conversion, or where it makes sence, by QString overload). Thanks, Marc On Friday 16 October 2015 21:42:23 Kurt Pattyn wrote: > Marc, > > It is clear that your main concern is performance (needless conversions) > and convenience (being able to work efficiently with 3rd party libraries). > Regarding performance, I think it would be good if we could come up with > some numbers. How 'bad' is the current implementation compared to an > 'ideal' situation? And then define some acceptable target keeping into > account convenience. Otherwise I am afraid that discussions can keep going > forever over 1 instruction more or less. Regarding convenience, and that > is what Qt is all about, I think you made a tremendous proposal that can > really bring Qt a big step forward. The idea is very sound and clear. Of > course, there are technical challenges, but that is what we are supposed > to solve. > > I also agree that we should aim for simplicity. QString and QStringView is > simple to understand, iff we can get rid of all other string related > classes. The ideal case would be just to have one QString class, although > I doubt that is achievable. > > I think it
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
If QString in Qt6 could be { QArrayData *d; ushort *b; int s }, then it supersedes QStringView in all aspects: - QString(u"hello world", 5) /* { d=.., b=.., s=5 } */ - still has a superpower of COW, etc - QString::fromRawData(u"hello world", 5) /* { d=nullptr, b=.., s=5 } */ - explicitly means "no owning, deep-copy when necessary" then we could get rid of QStringRef (or typedef it to QString) and do something like: private: QString(QArrayData *dd, ushort *unicode, int size) { if (dd) { dd->ref(); } d = dd; b = unicode; s = size; } /* not that trivial, of course, just to describe the idea */ public: QString QString::left(int n) const { return QString(d, b, n); } QString QString::leftRef(int n) const { return QString(nullptr, b, n); } > That said, QStringView is as much about > > - slim interface type vs. thick, fat, storage type > - interop with 3rd-party and native code So as QString now... i.e. DWORD dwBufferSize = 0; if (::GetUserProfileDirectory(token, NULL, ) == 0 && dwBufferSize != 0) { QVarLengthArray userDirectory(dwBufferSize); if (::GetUserProfileDirectory(token, userDirectory.data(), ) == 0) { QString dirName = QString::fromRawData(userDirectory.constData(), dwBufferSize); // still unsafe, but it is clearly documented for years and nothing has really changed for its users anyways return QDir().exists( dirName.rightRef(dirName.lastIndexOf(QLatin1Char('\\'; } } Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
> On 17 Oct 2015, at 01:18, Marc Mutzwrote: > > Kurt, > > The mail you're replying to has nothing to do with QStringView. It was a > tangent about std::string_view. Yes, but this thread is diverging on a lot of different things than the original, genuine intent you have. So, please forgive me on replying on a 'side-branch' :-) > > If you need a real-world example of where QStringView would be handy: Some > 3rd-party code returns you a char16_t *path, and you want to perform a > QDir::cd(). Currently, you need to create a QString (which allocates). Had > QDir::cd() taken a QStringView, you wouldn't have that allocation. > > Another example I already mentioned: > >> E.g. local QStrings could be replaced by QVarLengthArray, >> >> e.g. in code like this: >>QString joinstr = QLatin1String("\"\n"); >>joinstr += indent; >>joinstr += indent; >>joinstr += QLatin1Char('"'); >> >>QString rc(QLatin1Char('"')); >>rc += result.join(joinstr); >>rc += QLatin1Char('"'); >> >> Even when replaced with QStringBuilder: >>QString joinstr = QLatin1String("\"\n") + indent + indent >> >> + QLatin1Char('"'); >> >>QString rc = QLatin1Char('"') + result.join(joinstr) + >>QLatin1Char('"'); >> >> But the main benefit would be that we only ever need one overload for a >> QString-taking function, not N, N > 3. > > Final with QStringView (and a minor modification to QStringBuilder): > > QVarLengthArray joinstr // doesn't alloc (for most 'indent's) > = QLatin1String("\"\n") + indent + indent + QLatin1Char('"'); > > // in this line, QStringList::join() doesn't know about QVarLengthArray. > // but it takes a QStringView and therefore transparently accepts QVLA > QString rc = QLatin1Char('"') + result.join(joinstr) + QLatin1Char('"'); > > Please understand my POV: I am of the firm belief that Qt has no business > creating inefficiencies for its users by sloppy implementation. Anywhere. We > cannot know whether one user is calling QString::multiArg() in a tight loop. > It might be dominating her runtime. 99.9% of users probably couldn't care > less > about QString::multiArg() performance. But we need to care about the 0.1%, > because that number is much closer to 100% if you integrate it over all > users' > critical paths (iow: every Qt user will have *some* part of Qt that she > wished > was faster, heck, iirc KMail ran into QObject::connect as a bottleneck at > some > point in the past!). Don't misunderstand me, I completely understand your POV. You are right: Qt IS about convenience and performance. Only, if I see the 'heated' discussions, it would be convenient if some baseline could be defined. > > The inefficiencies I (and Sergio and Milian and, I'm happy to see, > Friedemann, > and others) care about are not ones you will find in a profiler in those > 99.9% > of cases, because they are not used in a critical path. But even for the > 99.9% > of users, if we make all of Qt 10% faster on average, their apps will run > close to 10% faster, too. Automatically. > > So yes, I care about performance. I find it intolerable that todays software > takes 1000x the memory, 1000x the CPU capacity and doesn't get a given jobs > done in less wallclock time than software 20 years ago. These are 'numbers'. Is it like that? Really 1000x the memory, 1000x the CPU capacity? I tend to say 'yes you are right', but then we still need some concrete measurements. > And people don't use > C++ because it's pretty. You cannot compete with Java on programmer > efficiency. > Its standard library is orders of magnitude larger than C++'s. People choose > C++ (and accept the associated loss in programmer efficiency), because they > require the bare metal efficiency of C++. And if Qt gets in the way, they > will > look for alternatives and find them in places that make Qt look like paradise. But Qt IS like paradise :-) > > That said, QStringView is as much about > > - slim interface type vs. thick, fat, storage type > - interop with 3rd-party and native code > > than it is about efficiency. > > Bottomline: I don't need a fancy anylysis to tell me that less allocations = > faster programs = more happy Qt users. But to what extent? If I run my application on a workstation, the effect is negligible, as my application has more to do than handling strings. If I have an embedded application, every piece of performance gain could benefit, but my experience tells me (for MY use cases) that the graphics stack is more a bottleneck than string handling. > > And please don't forget that QString fanboys can continue to massacre the > heap > if they so wish. After all, we've had QStringRef for a long time now, but > most > people still write str.mid(n).toInt() instead of str.midRef().toInt(). > QStringView won't change that: A function taking QStringView accepts a > QString, too (either by implicit conversion, or where
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Saturday 17 October 2015 03:34:51 Konstantin Ritt wrote: > - QString::fromRawData(u"hello world", 5) /* { d=nullptr, b=.., s=5 } */ - > explicitly means "no owning, deep-copy when necessary" And when is it necessary? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Saturday 17 October 2015 01:52:27 Kurt Pattyn wrote: > > Bottomline: I don't need a fancy anylysis to tell me that less > > allocations = faster programs = more happy Qt users. > > But to what extent? If I run my application on a workstation, the effect is > negligible, as my application has more to do than handling strings. If I > have an embedded application, every piece of performance gain could > benefit, but my experience tells me (for MY use cases) that the graphics > stack is more a bottleneck than string handling. I object to the notion that a desktop would not benefit from more efficient string handling. Hardware doesn't get faster the way it used to. If the speed of C++ wasn't needed, your workstation would only run Java apps (and Sun tried, but failed). > > > > And please don't forget that QString fanboys can continue to massacre the > > heap if they so wish. After all, we've had QStringRef for a long time > > now, but most people still write str.mid(n).toInt() instead of > > str.midRef().toInt(). QStringView won't change that: A function taking > > QStringView accepts a QString, too (either by implicit conversion, or > > where it makes sence, by QString overload). > > The word 'fanboys' disturbs me (I know you don't mean it that way) because > there are no 'hard' numbers on how 'bad' the current situation really is. > It would really be helpful to have an idea how 'real-world' applications > suffer from the current implementation of QString. That would give a very > good context to decide how Qt can help to leverage these problems. If you want real-world numbers, follow the optimisations Milian did in moc. IIRC, he documented the speedup.They are not (all) string-related, but I also don't claim that QStringView will single-handedly make your apps go faster. I wrote about QList already. There's more where these topics came from, but essentially they all boil down to: "minimise allocations". > That said, I like the idea of QStringView. Thanks, Marc -- Marc Mutz| 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
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
On Saturday 17 October 2015 07:14:58 Konstantin Ritt wrote: > 2015-10-17 6:23 GMT+04:00 Thiago Macieira: > > On Saturday 17 October 2015 03:34:51 Konstantin Ritt wrote: > > > - QString::fromRawData(u"hello world", 5) /* { d=nullptr, b=.., s=5 } */ > > > > - > > > > > explicitly means "no owning, deep-copy when necessary" > > > > And when is it necessary? > > In a given example, left() derives the original data, even when it isn't > shared, whilst leftRef() produces a non-shared QString, just like proposed > QStringView. You missed the point. The whole problem of QString::fromRawData is that the method you called may store the QString and thus keep referencing the string you had, even past the point where your string changed. In fact, that happens with QStringLiteral too. If you use QStringLiteral in a plugin and the plugin gets unloaded, the application may crash. The whole point here was "deep-copy when necessary": when is it necessary? If we can't solve the two problems above, we are going to make the problem worse. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development