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

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 decision, i.e. independent of the i

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 coinci

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 realloca

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 remember it, the change from QSubString to QStringRef was a simple API >> naming decision, i.e. independen

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

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 19-10-2015 om 17:54 schreef Thiago Macieira: >> > First of all, QStringRef keeps a pointer to the original QS

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 QSubS

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 wi

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 pre

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 on

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

rg > on > behalf of Smith Martin > 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'

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

@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 containing classes? If I want the efficiency of QStringView,

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: 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 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 >>> use QSV in all functions taking QString? >> >> Complicati

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 existing

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 cannot possibly prove that doing

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

bounces+martin.smith=theqtcompany@qt-project.org on behalf of Marc Mutz 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 Martin wro

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

z 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 Martin wrote: > >This API here simply cannot exist because the returned value w

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

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), therefo

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

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 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 > > { > > QString m_data; > > public: > >

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 (isValidIdentifier(myVarian

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 return

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 QStringView API if it can be

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

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

27;t it? martin From: development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Thiago Macieira Sent: Monday, October 19, 2015 9:38 PM To: development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt

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 b

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

=theqtcompany@qt-project.org on behalf of Thiago Macieira Sent: Monday, October 19, 2015 5:54 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 11:23:38 Marc Mutz wrote: > On S

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

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

oject.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 Giuseppe D'Angelo wrote: > > That the proposal is that every single function cu

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

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

From: development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Thiago Macieira Sent: Monday, October 19, 2015 8:21 AM To: development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings On Mon

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 s

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

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 proposal is that every single function currently taking a > QString should instead

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

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

take QString. From: development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Giuseppe D'Angelo Sent: Sunday, October 18, 2015 9:27 PM To: development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings Il 18/10

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 changed

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

f of Marc Mutz 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 a bit into the current state of string handling in Qt for my QtWS talk last week, I have be

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 so

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

__ From: development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Marc Mutz Sent: Saturday, October 17, 2015 10:13 PM To: development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs tak

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 bec

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

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 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 you are overreacting

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

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

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. >> > It would really be helpfu

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

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

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 discovered a more > efficient way

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

ober 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 about std::string_view. If you need a real-world example o

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

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,

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 m

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

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,

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

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 have. So, please forgive

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

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 cr

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 wi

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

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 semanti

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 w

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

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

y, 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 w

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 be

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 o

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 st

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 October 16, 2015 07:07:56 Thiago Macieira wrote: > 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 wh

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 p

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

@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

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 enough bits floating around to create your

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 imp

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

Op 15-10-2015 om 18:40 schreef Konstantin Ritt: 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 th

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

This is getting way off topic with regards to QStringView... On 16/10/15 07:07, "Thiago Macieira" wrote: >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 differen

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

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 the hat to Kai). > >

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

at is a string view? martin From: development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Marc Mutz Sent: Friday, October 16, 2015 1:28 AM To: development@qt-project.org Subject: Re: [Development] RFC: Proposal for a semi-radical c

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

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 so

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 Macieira

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

On October 15, 2015 00:27:45 Thiago Macieira wrote: > On Wednesday 14 October 2015 21:51:23 Bubke Marco wrote: >> On October 14, 2015 23:10:26 Thiago Macieira > wrote: >> > Do it on your own. You just said that ICU has the function you want, so >> > use >> > it. >> >> So Qt is always shipping

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? Did you ever look into t

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 clear

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 unexpectedly behaving >> code

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

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 go

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 > mailto:marco.bu...@theqtcompany.com>>: > On October 15, 2015 08:45:30 Knoll Lars > mailto:lars.kn...@theqtcompany.com>> wrote: > >> On 14/10/15 23:51, "Bubke Marco" >> mailto:marco.bu...@theqtcompany

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

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 > >>wrote: > >>> Qt does not have to provide a comparator that operates on something > >>>other than > >

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 wrote: On October 14, 2015 22:13:11 Thiago Macieira >>> wrote: And I don't w

  1   2   >