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(),
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
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.
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
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
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
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
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 -
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
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
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
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
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.
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
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
>>
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
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
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
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,
>
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).
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
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
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
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
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,
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
> 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
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
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
101 - 129 of 129 matches
Mail list logo