Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Tuesday 13 October 2015 22:46:36 Marc Mutz wrote: > I would propose to package the two into a class, called > - you guessed it - QStringView. I now started work on QStringView (and later QByteArrayView), here: https://codereview.qt-project.org/#/q/topic:qstringview,n,z Input welcome.

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Tuesday 20. October 2015 23.37.27 Thiago Macieira wrote: > Em qua 21 out 2015, às 06:29:30, Knoll Lars escreveu: > > As I remember it, the change from QSubString to QStringRef was a simple > > API > > naming decision, i.e. independent of the implementation details. > > Then it must be a

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 22/10/15 10:56, "Paul Olav Tvete" wrote: >On Tuesday 20. October 2015 23.37.27 Thiago Macieira wrote: >> Em qua 21 out 2015, às 06:29:30, Knoll Lars escreveu: >> > As I remember it, the change from QSubString to QStringRef was a >>simple >> > API >> > naming

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Em qua 21 out 2015, às 06:45:53, Knoll Lars escreveu: > >That doesn't work. I've tried to change QStringRef and it broke in a lot > >of places. > > Do you remember what broke? Not really. When I tracked down the failures, I did find out that it was related to the original QString being

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Em qua 21 out 2015, às 06:29:30, Knoll Lars escreveu: > As I remember it, the change from QSubString to QStringRef was a simple API > naming decision, i.e. independent of the implementation details. Then it must be a coincidence that it changed internals more or less at the same time. > The

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 21/10/15 08:37, "development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira" wrote: >Em qua 21 out 2015, às 06:29:30, Knoll Lars escreveu: >> As I

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 20/10/15 18:11, "development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira" wrote: >On Tuesday 20 October 2015 08:49:17 André Somers wrote: >> Op

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Op 19-10-2015 om 17:54 schreef Thiago Macieira: > First of all, QStringRef keeps a pointer to the original QString, so it isn't > as fragile as QStringView. In fact, during the development of the XML stream > classes, there was a QSubString class that did more or less what QStringView > would do.

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 20, 2015 08:43:26 Thiago Macieira wrote: > On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote: >> So if deep copies loose their ineffciency myth, what reason remains to not >> use QSV in all functions taking QString? > > Complicating the API. > > You

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Tuesday 20 October 2015 01:08:31 Thiago Macieira wrote: > So the summary of QStringView is: > a) never used as return type > b) used only as a parameter if the function processes the data and never > stores it and will never, ever store it (lazy processing) > c) for existing API, needs

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

ith=theqtcompany@qt-project.org> on behalf of Marc Mutz <marc.m...@kdab.com> Sent: Monday, October 19, 2015 11:26 PM To: development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings On Monday 19 October 2015 21:56:54 Smith

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

ent: Tuesday, October 20, 2015 9:13 AM To: Marc Mutz; development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings I see. But then, if I have QStringView, doesn't that eliminate most of the reasons for needing the other string contai

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Martin <martin.sm...@theqtcompany.com> Sent: Tuesday, October 20, 2015 9:13 AM To: Marc Mutz; development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings I see. But then, if I have QStringView, doesn't that eliminate most of

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

_ > From: development-bounces+martin.smith=theqtcompany@qt-project.org > <development-bounces+martin.smith=theqtcompany@qt-project.org> on > behalf of Marc Mutz <marc.m...@kdab.com> > Sent: Monday, October 19, 2015 11:26 PM > To:

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 20, 2015 10:10:36 Knoll Lars wrote: > On 20/10/15 09:59, "Bubke Marco" wrote: > >>On October 20, 2015 08:43:26 Thiago Macieira >>wrote: >> >>> On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote:

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Tuesday 20 October 2015 11:08:51 Иван Комиссаров wrote: > Btw, isn't the QStringView is the same as Range > { Container::Iterator begin; Container::Iterator end; } ? No. A string_view (or QStringView) is targeted at string operations. A range is just a pair of iterators. > Why we introduce

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Tuesday 20 October 2015 09:13:18 Smith Martin wrote: > I see. But then, if I have QStringView, doesn't that eliminate most of the > reasons for needing the other string containing classes? If I want the > efficiency of QStringView, won't QString underneath always be the right > choice? No. Two

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Op 20-10-2015 om 11:08 schreef Иван Комиссаров: > Btw, isn't the QStringView is the same as Range > { Container::Iterator begin; Container::Iterator end; } ? > Why we introduce only QStringView/QByteArrayView? Maybe we should > think about adding range API to all containers? > > Alexandrescus

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Op 19-10-2015 om 22:31 schreef Bubke Marco: > For example the highlighting can show that the parameter is an in or in/out > parameter so you don't need to use pointers anymore for in/out parameters > etc. But it is getting off topic. https://bugreports.qt.io/browse/QTCREATORBUG-14468 André

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote: > So if deep copies loose their ineffciency myth, what reason remains to not > use QSV in all functions taking QString? Complicating the API. You cannot possibly prove that doing something O(n) is as efficient as doing something O(1),

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Le lundi 19 octobre 2015 à 16:08 -0700, Thiago Macieira a écrit : > > So the summary of QStringView is: > a) never used as return type > b) used only as a parameter if the function processes the data and never > stores it and will never, ever store it (lazy processing) > c) for

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 20/10/15 09:59, "Bubke Marco" wrote: >On October 20, 2015 08:43:26 Thiago Macieira >wrote: > >> On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote: >>> So if deep copies loose their ineffciency myth, what reason remains to >>>not >>>

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Tuesday 20 October 2015 10:06:28 Julien Blanc wrote: > Le lundi 19 octobre 2015 à 16:08 -0700, Thiago Macieira a écrit : > > So the summary of QStringView is: > > a) never used as return type > > b) used only as a parameter if the function processes the data and never > > stores it and

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Tuesday 20 October 2015 08:49:17 André Somers wrote: > Op 19-10-2015 om 17:54 schreef Thiago Macieira: > > First of all, QStringRef keeps a pointer to the original QString, so it > > isn't as fragile as QStringView. In fact, during the development of the > > XML stream classes, there was a

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote: > On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote: > > That the proposal is that every single function currently taking a > > QString should instead be changed to take a QStringView instead, unless > > a few exceptional cases

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

ago Macieira <thiago.macie...@intel.com> Sent: Sunday, October 18, 2015 10:55 PM To: development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote: > That the p

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Monday 19 October 2015 06:10:41 Smith Martin wrote: > >Return values must always be QString, never QStringView. Returning a view > >is like returning a reference and goes against Qt's library code policy. > > But an assumption is the user manages the ownership of the underlying > string, so it

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

opment] RFC: Proposal for a semi-radical change in Qt APIs taking strings On Monday 19 October 2015 06:10:41 Smith Martin wrote: > >Return values must always be QString, never QStringView. Returning a view > >is like returning a reference and goes against Qt's library code policy.

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Mutz <marc.m...@kdab.com> Sent: Monday, October 19, 2015 11:23 AM To: development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote: > On Sunday 18 October 2015 21:27:31 Gi

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 2015-10-16 19:52, Kurt Pattyn wrote: > On 17 Oct 2015, at 01:18, Marc Mutz wrote: >> 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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Monday 19 October 2015 11:23:38 Marc Mutz wrote: > On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote: > > On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote: > > > That the proposal is that every single function currently taking a > > > QString should instead be changed to take a

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Monday 19 October 2015 07:14:55 Smith Martin wrote: > >The point I'm trying to make > >is that returning a non-owning copy means that something else must own the > >data. That's what goes against the library code policy. > > The library code policy is an one that has always made sense in the >

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Monday 19 October 2015 21:56:54 Smith Martin wrote: > >This API here simply cannot exist because the returned value would be a > >dangling reference. > > I don't understand. Implicit for using the QStringView data() function is > knowing that once the QByteArray is set, it is never changed.

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 19, 2015 21:38:51 Thiago Macieira wrote: > On Monday 19 October 2015 18:38:52 Smith Martin wrote: >> >Again, please try writing this method: >> Doesn't that example just mean there are some classes that can't have a >> QStringView API? A class should have a

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Monday 19 October 2015 18:38:52 Smith Martin wrote: > >Again, please try writing this method: > Doesn't that example just mean there are some classes that can't have a > QStringView API? A class should have a QStringView API if it can be used > safely. Right. I'm simply saying that "if it can

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

any@qt-project.org <development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of Thiago Macieira <thiago.macie...@intel.com> Sent: Monday, October 19, 2015 5:54 PM To: development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

ent@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings On Monday 19 October 2015 18:38:52 Smith Martin wrote: > >Again, please try writing this method: > Doesn't that example just mean there are some classes that can't have a

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Monday 19. October 2015 23:26:45 Marc Mutz wrote: > This particular mistake is easy to prevent statically, though: > >QStringView(QString &&) = delete; No. We want this to work: if (isValidIdentifier(myVariant.toString())) with isValidIdentifier taking a QStringView and toString

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Tuesday 20 October 2015 00:51:58 Olivier Goffart wrote: > On Monday 19. October 2015 23:26:45 Marc Mutz wrote: > > This particular mistake is easy to prevent statically, though: > > > >QStringView(QString &&) = delete; > > No. > > We want this to work: > > if

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Monday 19 October 2015 20:31:53 Bubke Marco wrote: > On October 19, 2015 21:38:51 Thiago Macieira wrote: > > Right. I'm simply saying that "if it can be used safely" is very, very > > restricted. > > > > Suppose you have in v1: > > > > class Foo > > { > >

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

evelopment] RFC: Proposal for a semi-radical change in Qt APIs taking strings Il 18/10/2015 20:30, Smith Martin ha scritto: > After watching the video on string_view, it seems clear we have to offer a > QStringView, so I don't see what is "semi-radical" about your proposal. That th

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote: > That the proposal is that every single function currently taking a > QString should instead be changed to take a QStringView instead, unless > a few exceptional cases (for instance the function is used to store the > string somehow,

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

pment-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of Marc Mutz <marc.m...@kdab.com> Sent: Tuesday, October 13, 2015 10:46 PM To: development@qt-project.org Subject: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings Hi, After looking quite

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Il 18/10/2015 20:30, Smith Martin ha scritto: After watching the video on string_view, it seems clear we have to offer a QStringView, so I don't see what is "semi-radical" about your proposal. That the proposal is that every single function currently taking a QString should instead be

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Saturday 17 October 2015 22:51:28 Bubke Marco wrote: > But before we add new concepts we should agree in which direction we want > to go. I have the feeling that we build an airplan but some want a jumbo > jet, some a jet fighter and some, lets describe it so, they want to fly > to the moon

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Saturday 17 October 2015 22:42:35 Konstantin Ritt wrote: > > 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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

opment-bounces+martin.smith=theqtcompany@qt-project.org <development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of Marc Mutz <marc.m...@kdab.com> Sent: Saturday, October 17, 2015 10:13 PM To: development@qt-project.org Subject: Re: [Development] RFC: Proposal

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Hi Martin After watching https://youtu.be/H9gAaNRoon4 I got a much better picture of string view. I really recommend to watch it. My understanding is that qstringview would be a qt implementation of string view and the conversation cost would be zero. I find that very promising because it

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Saturday 17 October 2015 19:42:27 Bubke Marco wrote: > > Last time I profiled Qt Creator startup and parsing of projects, the two > > most expensive calls in QtCore were qHash and the SHA1 calculator. The > > former I've already fixed. The latter I was hoping that some colleagues > > would fix

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Saturday 17 October 2015 08:06:33 Marc Mutz wrote: > > 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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Hi Marc They thread mostly concentrated on performance but what about statical analysis? string_view and array_view are specifically designed for that. Maybe you mention it already but how is QStringView working for it. Sent from cellphone ___

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Mutz <marc.m...@kdab.com> Sent: Saturday, October 17, 2015 1:18 AM To: development@qt-project.org Subject: 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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Saturday 17 October 2015 15:51:35 Smith Martin wrote: > >Please understand my POV: I am of the firm belief that Qt has no business > >creating inefficiencies for its users by sloppy implementation. Anywhere. > > I think you are overreacting here, way too much. You have discovered a more >

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 17, 2015 19:22:55 Thiago Macieira wrote: > On Saturday 17 October 2015 08:06:33 Marc Mutz wrote: >> > 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. >>

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

2015-10-17 8:58 GMT+04:00 Thiago Macieira : > 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: > > > > -

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 17, 2015 21:05:29 Marc Mutz wrote: > On Saturday 17 October 2015 15:51:35 Smith Martin wrote: >> >Please understand my POV: I am of the firm belief that Qt has no business >> >creating inefficiencies for its users by sloppy implementation. Anywhere. >> >> I think

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 17, 2015 15:52:08 Smith Martin wrote: >>Please understand my POV: I am of the firm belief that Qt has no business >>creating inefficiencies for its users by sloppy implementation. Anywhere. > > I think you are overreacting here, way too much. You have

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

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

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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

015 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? > > Q

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_ >>

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 16, 2015 08:53:33 Marc Mutz wrote: > 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

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 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

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

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

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? ___

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

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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

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 hav

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,

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()

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

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

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

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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

> On 17 Oct 2015, at 01:18, Marc Mutz wrote: > > 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

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 -

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

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 } */ > > > > - > > > > >

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

2015-10-15 11:00 GMT+03:00 Bubke Marco : > On October 15, 2015 08:45:30 Knoll Lars > wrote: > > > On 14/10/15 23:51, "Bubke Marco" wrote: > > > >>On October 14, 2015 23:10:26 Thiago Macieira

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

> On Oct 14, 2015, at 5:14 PM, Matthew Woehlke wrote: > > On 2015-10-14 10:30, André Somers wrote: >> Op 14-10-2015 om 15:59 schreef Matthew Woehlke: >>> STL should change. In Qt and Python, you can use negative indices to >>> refer to a distance (length) relative to

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Thursday 15 October 2015 06:05:34 Thiago Macieira wrote: > On Thursday 15 October 2015 02:22:50 Marc Mutz wrote: > > On Thursday 15 October 2015 00:27:14 Thiago Macieira wrote: > > > Way too much code would break if we did that because we allow people > > > access > > > to the data pointer in

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 14/10/15 23:51, "Bubke Marco" wrote: >On October 14, 2015 23:10:26 Thiago Macieira >wrote: > >> On Wednesday 14 October 2015 20:52:12 Bubke Marco wrote: >>> On October 14, 2015 22:13:11 Thiago Macieira >>> >>

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 15, 2015 08:45:30 Knoll Lars wrote: > On 14/10/15 23:51, "Bubke Marco" wrote: > >>On October 14, 2015 23:10:26 Thiago Macieira >>wrote: >> >>> On Wednesday 14 October 2015 20:52:12 Bubke Marco

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 2015-10-15 02:38, Ziller Eike wrote: > So from where does 's.indexOf(‘c’, i-2)' search? > > This is similar to integer overflow, and I think utilizing that in an > API leads to less readable and potentially unexpectedly behaving > code. It depends on the value of i, of course. And you're not

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 15, 2015 14:53:29 Konstantin Ritt wrote: > 2015-10-15 11:00 GMT+03:00 Bubke Marco > >: > On October 15, 2015 08:45:30 Knoll Lars > >

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Thursday 15 October 2015 14:52:46 Konstantin Ritt wrote: > For everything but US-ASCII / Latin-1, UTF-8 isn't faster than UTF-16 (feel > free to compare their complexity against UTF-32). > And why "pure Chinese signs" again? Did you ever look into the Unicode's > Scripts.txt [1], for example?

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 2015-10-14 18:27, Thiago Macieira wrote: > On Wednesday 14 October 2015 21:51:23 Bubke Marco wrote: >> Is UTF 16 seekable? You still have surrogates and you can merge merge code >> points. > > Seekable enough. It's much easier to deal with than UTF-8. A surrogate pair, > as its name says,

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On October 15, 2015 15:56:35 Matthew Woehlke wrote: > On 2015-10-15 02:38, Ziller Eike wrote: >> So from where does 's.indexOf(‘c’, i-2)' search? >> >> This is similar to integer overflow, and I think utilizing that in an >> API leads to less readable and potentially

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Op 15-10-2015 om 14:52 schreef Konstantin Ritt: > > > For everything but US-ASCII / Latin-1, UTF-8 isn't faster than UTF-16 > (feel free to compare their complexity against UTF-32). > And why "pure Chinese signs" again? Did you ever look into the > Unicode's Scripts.txt [1], for example? It

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

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). Thanks, Marc On Thursday 15 October 2015 23:02:09 Bubke Marco wrote: > On October 15, 2015 00:27:45 Thiago

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Thursday 15 October 2015 21:02:09 Bubke Marco wrote: > Actually I think Qt is not main developing library people use. It is there > to make the boring stuff easy, to hide the different interfaces between > different platforms. That is why many people use Qt, they want to have a > GUI but don't

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

2015-10-15 17:52 GMT+03:00 André Somers : > Op 15-10-2015 om 14:52 schreef Konstantin Ritt: > > > > > > For everything but US-ASCII / Latin-1, UTF-8 isn't faster than UTF-16 > > (feel free to compare their complexity against UTF-32). > > And why "pure Chinese signs" again?

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Op 14-10-2015 om 15:59 schreef Matthew Woehlke: > >>> Yes, signed please. We can discuss whether it should be 64bit for Qt 6. >> The current std API uses size_t. Do you (= both of you) expect that ever to >> change? If it doesn't, Qt will forever be the odd one out, until we finally >> drop

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On 2015-10-14 10:30, André Somers wrote: > Op 14-10-2015 om 15:59 schreef Matthew Woehlke: >> STL should change. In Qt and Python, you can use negative indices to >> refer to a distance (length) relative to the end (length) of the string. >> In STL you can't do that, which is a significant

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 09:59:28 Matthew Woehlke wrote: > On 2015-10-14 06:16, Marc Mutz wrote: > > First, afaiu from what Thiago mentions in reviews, Q6String will have SSO > > (small-string-optimisation) which makes many short strings expensive to > > copy (if you think that copying 24

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 08:51:11 Thiago Macieira wrote: > The separation of the string itself from the size and the d pointer allows > the compiler, if it wants to, to share strings. In fact, disassembly of > > f(QStringLiteral("foo"), QStringLiteral("foo")) > > produces one copy

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

On Wednesday 14 October 2015 12:16:47 Marc Mutz wrote: > > >But as a condition to be even considered, it needs to be only for the > > >methods > > >that do not hold a copy of the string. That is, methods that immediately > > >consume the string and no longer need to reference its contents. > >

  1   2   >