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

On Wednesday 14 October 2015 20:09:56 Marc Mutz wrote: > On Wednesday 14 October 2015 12:41:12 Allan Sandfeld Jensen wrote: > > Why not a QCharArray? With external data constructor, that should be the > > same, shouldn't it? > > If you propose something like QString/QByteArray::fromRawData(),

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

On Wednesday 14 October 2015 20:04:12 Marc Mutz wrote: > On Wednesday 14 October 2015 18:11:26 Thiago Macieira wrote: > > and the fact that QStringLiterals don't share will cause the > > innocent-looking above code require 64 bytes of read-only data. > > They are shared, because it seems that

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

On Wednesday 14 October 2015 15:59:21 Matthew Woehlke wrote: > On 2015-10-14 07:15, Knoll Lars wrote: > > In addition, it might be tricky to use QStringView in signals and > > slots. > > As I previously stated, I'm pretty sure you *CAN'T* use QStringView to > call slots, except for direct call.

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

On Wednesday 14 October 2015 12:41:12 Allan Sandfeld Jensen wrote: > Why not a QCharArray? With external data constructor, that should be the > same, shouldn't it? If you propose something like QString/QByteArray::fromRawData(), then that allocates the control block, so no, not really an

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

On Wednesday 14 October 2015 18:11:26 Thiago Macieira wrote: > and the fact that QStringLiterals don't share will cause the > innocent-looking above code require 64 bytes of read-only data. They are shared, because it seems that lambdas within the same function have the same type. At least last

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

On 13/10/15 22:46, "Matthew Woehlke" wrote: >On 2015-10-13 15:59, Jake Petroules wrote: >> On Oct 13, 2015, at 1:46 PM, Marc Mutz wrote: >>> I would therefore like to propose to abandon QString for new API (and >>>over >>> time phase it out of existing API), and only

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

I’m not a huge fan of having different overloads with QString, QStringRef and QLatin1String and in some cases (QChar *, int) for many methods neither. But while your proposal solves some problems it introduces others. A QStringView class would only work for methods that read the data contained in

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

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

On Wednesday 14 October 2015 08:37:19 Knoll Lars wrote: > I’m not a huge fan of having different overloads with QString, QStringRef > and QLatin1String and in some cases (QChar *, int) for many methods > neither. But while your proposal solves some problems it introduces others. > > A QStringView

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

Hi Lars Knoll Lars > Agree here as well. We can’t make QString utf-8 backed without breaking > way too much code. I also don’t see the need for it. The native encoding > on Windows and Mac (Cocoa) is utf-16 as well, on Linux it’s utf-8. So no > matter which platform

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

On Wednesday 14 October 2015 17:55:34 Bubke Marco wrote: > Think about a local aware compare which is called very very often. You don't > want malloc in between. In in most cases you get an const char* or const > shor* in this cases It would be nice if your interface would support UTF-8 > and not

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

On Wed, Oct 14, 2015 at 06:37:19AM +, Knoll Lars wrote: > Agree here as well. We can’t make QString utf-8 backed without breaking > way too much code. I also don’t see the need for it. The native encoding > on Windows and Mac (Cocoa) is utf-16 as well, on Linux it’s utf-8. So no > matter which

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

On Wednesday 14 October 2015 22:56:15 André Pönitz wrote: > > I think there’s actually quite a few of those. In addition, it might be > > tricky to use QStringView in signals and slots. > > One could try to be clever and go through an intermediate QString > object at least in queued connections.

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

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 with ICU? It can be disabled on

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

On October 14, 2015 22:13:11 Thiago Macieira wrote: > On Wednesday 14 October 2015 17:55:34 Bubke Marco wrote: >> Think about a local aware compare which is called very very often. You don't >> want malloc in between. In in most cases you get an const char* or const >>

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

On Wednesday 14 October 2015 20:52:12 Bubke Marco wrote: > On October 14, 2015 22:13:11 Thiago Macieira wrote: > > On Wednesday 14 October 2015 17:55:34 Bubke Marco wrote: > >> Think about a local aware compare which is called very very often. You > >> don't want

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

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 want an utf 8 baked >> QString. For my use cases implicit

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

On Wed, Oct 14, 2015 at 11:15:55AM +, Knoll Lars wrote: > >That leaves classes which simply store the string. You cited QUrl. I > >don't see > >a problem providing QString overloads for these, esp. considering that > >we're > >starting out with an all-QString API here. Then again, once we

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

On Tuesday 13 October 2015, Marc Mutz wrote: > Hi, > > After looking quite a bit into the current state of string handling in Qt > for my QtWS talk last week, I have become frustrated by the state of > string handling in Qt. > > We have such powerful tools for string handling (QStringRef, >

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

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 QString and to iterate directly > (std::{,w,u16}string don't allow that, which makes parsing them actually a > lot more cumbersome).

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

Hi Andre, On Wednesday 14 October 2015 22:37:01 André Pönitz wrote: > That's why I'd like to propose the following: > > Since experiments within Qt proper are difficult due to the BC > and SC guarantees we give and the practical impossibility to un-do > additions we should simply not do it

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

On Wed, Oct 14, 2015 at 11:15:55AM +, Knoll Lars wrote: > >> >> A: Once QString is backed by UTF-8, [...] > > It’s worthwhile discussing, but any such change would have huge > implications on our QString API. > indeed. > In any case, it’s nothing we can do in Qt 5. > i don't think this is

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

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 QString and to iterate directly > > (std::{,w,u16}string don't allow

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

Marc Mutz > I'm not optimising. I'm decoupling the concept of a "QString" from the owning > implementation "QString", so that we don't need to either convert from/to > QString quite so often or you can use "foreign types" > (std::basic_string, char16_t[], ...) in lieu of

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

On 2015-10-14 07:15, Knoll Lars wrote: > In addition, it might be tricky to use QStringView in signals and > slots. As I previously stated, I'm pretty sure you *CAN'T* use QStringView to call slots, except for direct call. In any other case, you risk the backing data being modified or, worse,

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

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 bytes is slower than upping an atomic int > through an indirection) or

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

> On Oct 13, 2015, at 1:46 PM, Marc Mutz wrote: > > Hi, > > After looking quite a bit into the current state of string handling in Qt for > my QtWS talk last week, I have become frustrated by the state of string > handling in Qt. > > We have such powerful tools for

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

I like idea to devide the job of manipulating data and sending data around in different classes. Many times I get string from different sources in different formats with different ownerships. And for performance reasons you don't want copy or convert that strings. Many sources like databases

[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

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

On 2015-10-13 15:59, Jake Petroules wrote: > On Oct 13, 2015, at 1:46 PM, Marc Mutz wrote: >> I would therefore like to propose to abandon QString for new API (and over >> time phase it out of existing API), and only provide (const QChar*, size_t) >> as >> the most general form. I would propose

<    1   2