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

[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 } */
> > 
> > -
> > 
> > > explicitly means "no owning, deep-copy when necessary"
> > 
> > And when is it necessary?
> 
> In a given example, left() derives the original data, even when it isn't
> shared, whilst leftRef() produces a non-shared QString, just like proposed
> QStringView.

You missed the point.

The whole problem of QString::fromRawData is that the method you called may 
store the QString and thus keep referencing the string you had, even past the 
point where your string changed.

In fact, that happens with QStringLiteral too. If you use QStringLiteral in a 
plugin and the plugin gets unloaded, the application may crash.

The whole point here was "deep-copy when necessary": when is it necessary? If 
we can't solve the two problems above, we are going to make the problem worse.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Saturday 17 October 2015 01:52:27 Kurt Pattyn wrote:
> > Bottomline: I don't need a fancy anylysis to tell me that less
> > allocations =  faster programs = more happy Qt users.
> 
> But to what extent? If I run my application on a workstation, the effect is
> negligible, as my application has more to do than handling strings. If I
> have an embedded application, every piece of performance gain could
> benefit, but my experience tells me (for MY use cases) that the graphics
> stack is more a bottleneck than string handling.

I object to the notion that a desktop would not benefit from more efficient 
string handling. Hardware doesn't get faster the way it used to. If the speed 
of C++ wasn't needed, your workstation would only run Java apps (and Sun 
tried, but failed).

> >
> > And please don't forget that QString fanboys can continue to massacre the
> > heap  if they so wish. After all, we've had QStringRef for a long time
> > now, but most people still write str.mid(n).toInt() instead of
> > str.midRef().toInt(). QStringView won't change that: A function taking
> > QStringView accepts a QString, too (either by implicit conversion, or
> > where it makes sence, by QString overload).
> 
> The word 'fanboys' disturbs me (I know you don't mean it that way) because
> there are no 'hard' numbers on how 'bad' the current situation really is.
> It would really be helpful to have an idea how 'real-world' applications
> suffer from the current implementation of QString. That would give a very
> good context to decide how Qt can help to leverage these problems.

If you want real-world numbers, follow the optimisations Milian did in moc. 
IIRC, he documented the speedup.They are not (all) string-related, but I also 
don't claim that QStringView will single-handedly make your apps go faster. I 
wrote about QList already. There's more where these topics came from, but 
essentially they all boil down to: "minimise allocations".

> That said, I like the idea of QStringView.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Konstantin Ritt]

2015-10-17 6:23 GMT+04:00 Thiago Macieira :

> On Saturday 17 October 2015 03:34:51 Konstantin Ritt wrote:
> > - QString::fromRawData(u"hello world", 5) /* { d=nullptr, b=.., s=5 } */
> -
> > explicitly means "no owning, deep-copy when necessary"
>
> And when is it necessary?
>

In a given example, left() derives the original data, even when it isn't
shared, whilst leftRef() produces a non-shared QString, just like proposed
QStringView.
Then, all we need is to check `d != nullptr` in every non-const method and
simply COW, as usual. Modifying a back storage of a fromRawData string via
the high level isn't what we really should allow anyways.

Alternatively, it could be
QString QString::left(int n) const { return QString(d ? d : new Data,
b, n); }
thus copying a part of the data when the original string isn't shared.
Though I don't like this idea too much.


Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[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?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Kurt Pattyn]

> 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 me on replying on a 
'side-branch' :-)
> 
> If you need a real-world example of where QStringView would be handy: Some 
> 3rd-party code returns you a char16_t *path, and you want to perform a 
> QDir::cd(). Currently, you need to create a QString (which allocates). Had 
> QDir::cd() taken a QStringView, you wouldn't have that allocation.
> 
> Another example I already mentioned:
> 
>> E.g. local QStrings could be replaced by QVarLengthArray,
>> 
>> e.g. in code like this:
>>QString joinstr = QLatin1String("\"\n");
>>joinstr += indent;
>>joinstr += indent;
>>joinstr += QLatin1Char('"');
>> 
>>QString rc(QLatin1Char('"'));
>>rc += result.join(joinstr);
>>rc += QLatin1Char('"');
>> 
>> Even when replaced with QStringBuilder:
>>QString joinstr = QLatin1String("\"\n") + indent + indent
>> 
>>   + QLatin1Char('"');
>> 
>>QString rc = QLatin1Char('"') + result.join(joinstr) +
>>QLatin1Char('"');
>> 
>> But the main benefit would be that we only ever need one overload for a
>> QString-taking function, not N, N > 3.
> 
> Final with QStringView (and a minor modification to QStringBuilder):
> 
>  QVarLengthArray joinstr // doesn't alloc (for most 'indent's)
>  = QLatin1String("\"\n") + indent + indent + QLatin1Char('"');
> 
>  // in this line, QStringList::join() doesn't know about QVarLengthArray.
>  // but it takes a QStringView and therefore transparently accepts QVLA
>  QString rc = QLatin1Char('"') + result.join(joinstr) + QLatin1Char('"');
> 
> Please understand my POV: I am of the firm belief that Qt has no business 
> creating inefficiencies for its users by sloppy implementation. Anywhere. We 
> cannot know whether one user is calling QString::multiArg() in a tight loop. 
> It might be dominating her runtime. 99.9% of users probably couldn't care 
> less 
> about QString::multiArg() performance. But we need to care about the 0.1%, 
> because that number is much closer to 100% if you integrate it over all 
> users' 
> critical paths (iow: every Qt user will have *some* part of Qt that she 
> wished 
> was faster, heck, iirc KMail ran into QObject::connect as a bottleneck at 
> some 
> point in the past!).
Don't misunderstand me, I completely understand your POV. You are right: Qt IS 
about convenience and performance. Only, if I see the 'heated' discussions, it 
would be convenient if some baseline could be defined.
> 
> The inefficiencies I (and Sergio and Milian and, I'm happy to see, 
> Friedemann, 
> and others) care about are not ones you will find in a profiler in those 
> 99.9% 
> of cases, because they are not used in a critical path. But even for the 
> 99.9% 
> of users, if we make all of Qt 10% faster on average, their apps will run 
> close to 10% faster, too. Automatically.
> 
> So yes, I care about performance. I find it intolerable that todays software 
> takes 1000x the memory, 1000x the CPU capacity and doesn't get a given jobs 
> done in less wallclock time than software 20 years ago.
These are 'numbers'. Is it like that? Really 1000x the memory, 1000x the CPU 
capacity?
I tend to say 'yes you are right', but then we still need some concrete 
measurements.
> And people don't use 
> C++ because it's pretty. You cannot compete with Java on programmer 
> efficiency. 
> Its standard library is orders of magnitude larger than C++'s. People choose 
> C++ (and accept the associated loss in programmer efficiency), because they 
> require the bare metal efficiency of C++. And if Qt gets in the way, they 
> will 
> look for alternatives and find them in places that make Qt look like paradise.
But Qt IS like paradise :-)
> 
> That said, QStringView is as much about
> 
> - slim interface type vs. thick, fat, storage type
> - interop with 3rd-party and native code
> 
> than it is about efficiency.
> 
> Bottomline: I don't need a fancy anylysis to tell me that less allocations = 
> faster programs = more happy Qt users.
But to what extent? If I run my application on a workstation, the effect is 
negligible, as my application has more to do than handling strings. If I have 
an embedded application, every piece of performance gain could benefit, but my 
experience tells me (for MY use cases) that the graphics stack is more a 
bottleneck than string handling.
> 
> And please don't forget that QString fanboys can continue to massacre the 
> heap 
> if they so wish. After all, we've had QStringRef for a long time now, but 
> most 
> people still write str.mid(n).toInt() instead of str.midRef().toInt(). 
> QStringView won't change that: A function taking QStringView accepts a 
> QString, too (either by implicit conversion, or where it makes sence, by 
> 

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

[Konstantin Ritt]

If QString in Qt6 could be { QArrayData *d; ushort *b; int s }, then it
supersedes QStringView in all aspects:
- QString(u"hello world", 5) /* { d=.., b=.., s=5 } */ - still has a
superpower of COW, etc
- QString::fromRawData(u"hello world", 5) /* { d=nullptr, b=.., s=5 } */ -
explicitly means "no owning, deep-copy when necessary"

then we could get rid of QStringRef (or typedef it to QString) and do
something like:

private:
QString(QArrayData *dd, ushort *unicode, int size) { if (dd) { dd->ref(); }
d = dd; b = unicode; s = size; } /* not that trivial, of course, just to
describe the idea */
public:
QString QString::left(int n) const { return QString(d, b, n); }
QString QString::leftRef(int n) const { return QString(nullptr, b, n); }


> That said, QStringView is as much about
>
> - slim interface type vs. thick, fat, storage type
> - interop with 3rd-party and native code

So as QString now... i.e.

DWORD dwBufferSize = 0;
if (::GetUserProfileDirectory(token, NULL, &dwBufferSize) == 0 &&
dwBufferSize != 0) {
QVarLengthArray userDirectory(dwBufferSize);
if (::GetUserProfileDirectory(token, userDirectory.data(),
&dwBufferSize) == 0) {
QString dirName = QString::fromRawData(userDirectory.constData(),
dwBufferSize); // still unsafe, but it is clearly documented for years and
nothing has really changed for its users anyways
return QDir().exists(
dirName.rightRef(dirName.lastIndexOf(QLatin1Char('\\';
}
}


Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Fwd: Change in qt/qtbase[5.6]: Make the C++11 atomic support the default, if available

[Thiago Macieira]

FYI

Please report any issues you have with broken compilers that did not implement 
std::atomic properly. I'd like to include them in the release notes.

These are already known to fail, so please don't report them:
- Xcode 5.0's clang compiler says it supports constexpr but doesn't
- ICC on OS X has a broken  header that misses some casts

Those compilers are now blacklisted in C++11 mode. For Qt 5.6, you can pass 
the configure option -std=c++98 or -no-c++11 and you'll be able to use them. 
They will not be supported in Qt 5.7, so please schedule your upgrade before 
the 5.7 release.

--  Forwarded Message  --

Qt CI Bot has approved a build with this change and it was merged.

Change subject: Make the C++11 atomic support the default, if available
..

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On Saturday 17 October 2015 01:18:06 Marc Mutz wrote:
> If you need a real-world example of where QStringView would be handy: Some 
> 3rd-party code returns you a char16_t *path, and you want to perform a 
> QDir::cd(). Currently, you need to create a QString (which allocates). Had 
> QDir::cd() taken a QStringView, you wouldn't have that allocation.

Bad example. You can use QString::fromRawData. While that today allocates the 
d pointer, for Qt 6 it wouldn't (null d pointer) and there would be no code 
change for the user.

There is, however, the danger of fromRawData: you need to be sure the called 
function won't try to store the QString. With a QStringView or the unsharable 
QString that Brano proposed in the other email, it would be clear that a deep 
copy needs to happen.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On Friday 16 October 2015 22:08:59 Branislav Katreniak wrote:
> Thiago described Qt6 QString as { QArrayData *d; ushort* b; qsize size }.
> That is pretty close to QStringView, just extra *d makes it slightly bigger.
> 
> This is how I understand this class:
> QString will have (typical) case when b points into d. QString own one
> reference in d in this case.
> QString will have special case when b points to text section and d does not
> own anything.
> QString will have special case for SSO.
> 
> Can QString have special case for not owned, non persistent b pointer
> (non-owning / view mode)?

How is that different from your second case? If it doesn't own, it doesn't need 
a d pointer.

> Non-owning QString can be created with special static QString method. It
> stays non-owning only while being passed through const &. Code that cares
> about keeping QString in view mode, must stick to const QString & all the
> time. Copy assignment on non-owning QString results in owning QString - it
> triggers deep copy into newly created shared data.

Ok, I understand the difference, but why do you want this behaviour? BTW, this 
is the unsharable strings that we're getting rid of.

This would make sense to view a string of ephemeral data. But if the data is 
ephemeral, why can't we use the refcounter? In other words, if someone owns 
this data, why isn't that QString?

> It solves the queued connection problem that existed with QStringView
> class. I suppose that queued connection internally performs QString copy.

True, but I think that having QString share refcount of substrings solves the 
problem that QStringView was proposed for in the first place.

> I have no idea about performance implications for code paths that do not
> care about this use case. But having just one string class would be very
> convenient.

That is the problem. That's the reason we're trying to get rid of unsharable 
containers: performance impact on the code paths that don't need it, which are 
the majority of cases.

There are two possibilities for the unsharable flag:

1) it's inside the d pointer, which means the d pointer must be non-null. That 
means even the non-owning QString needs to allocate memory for the d pointer 
block.

2) it's outside the d pointer, which means that
 a) it doesn't need to allocate memory
 b) we need to extend QString to be:
  { QArrayData *d; ushort *b; qsize size; int flags; }
  (24 bytes if qsize is 32-bit on 64-bit platforms; 32 if it is 64-bit; always 
   16 bytes on 32-bit platforms)

Either way, the existence of the flag means that every QString copy-assignment 
needs to check this flag, instead of simply incrementing the refcount if d is 
not null and being done with it. That means code bloat for the deep copy 
showing up everywhere.

I really don't want the unsharable flag.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

Kurt,

The mail you're replying to has nothing to do with QStringView. It was a 
tangent about std::string_view.

If you need a real-world example of where QStringView would be handy: Some 
3rd-party code returns you a char16_t *path, and you want to perform a 
QDir::cd(). Currently, you need to create a QString (which allocates). Had 
QDir::cd() taken a QStringView, you wouldn't have that allocation.

Another example I already mentioned:

> E.g. local QStrings could be replaced by QVarLengthArray,
> 
> e.g. in code like this:
> QString joinstr = QLatin1String("\"\n");
> joinstr += indent;
> joinstr += indent;
> joinstr += QLatin1Char('"');
> 
> QString rc(QLatin1Char('"'));
> rc += result.join(joinstr);
> rc += QLatin1Char('"');
> 
> Even when replaced with QStringBuilder:
> QString joinstr = QLatin1String("\"\n") + indent + indent
> 
>+ QLatin1Char('"');
> 
> QString rc = QLatin1Char('"') + result.join(joinstr) +
> QLatin1Char('"');
> 
> But the main benefit would be that we only ever need one overload for a
> QString-taking function, not N, N > 3.

Final with QStringView (and a minor modification to QStringBuilder):

  QVarLengthArray joinstr // doesn't alloc (for most 'indent's)
  = QLatin1String("\"\n") + indent + indent + QLatin1Char('"');

  // in this line, QStringList::join() doesn't know about QVarLengthArray.
  // but it takes a QStringView and therefore transparently accepts QVLA
  QString rc = QLatin1Char('"') + result.join(joinstr) + QLatin1Char('"');

Please understand my POV: I am of the firm belief that Qt has no business 
creating inefficiencies for its users by sloppy implementation. Anywhere. We 
cannot know whether one user is calling QString::multiArg() in a tight loop. 
It might be dominating her runtime. 99.9% of users probably couldn't care less 
about QString::multiArg() performance. But we need to care about the 0.1%, 
because that number is much closer to 100% if you integrate it over all users' 
critical paths (iow: every Qt user will have *some* part of Qt that she wished 
was faster, heck, iirc KMail ran into QObject::connect as a bottleneck at some 
point in the past!).

The inefficiencies I (and Sergio and Milian and, I'm happy to see, Friedemann, 
and others) care about are not ones you will find in a profiler in those 99.9% 
of cases, because they are not used in a critical path. But even for the 99.9% 
of users, if we make all of Qt 10% faster on average, their apps will run 
close to 10% faster, too. Automatically.

So yes, I care about performance. I find it intolerable that todays software 
takes 1000x the memory, 1000x the CPU capacity and doesn't get a given jobs 
done in less wallclock time than software 20 years ago. And people don't use 
C++ because it's pretty. You cannot compete with Java on programmer efficiency. 
Its standard library is orders of magnitude larger than C++'s. People choose 
C++ (and accept the associated loss in programmer efficiency), because they 
require the bare metal efficiency of C++. And if Qt gets in the way, they will 
look for alternatives and find them in places that make Qt look like paradise.

That said, QStringView is as much about

- slim interface type vs. thick, fat, storage type
- interop with 3rd-party and native code

than it is about efficiency.

Bottomline: I don't need a fancy anylysis to tell me that less allocations = 
faster programs = more happy Qt users.

And please don't forget that QString fanboys can continue to massacre the heap 
if they so wish. After all, we've had QStringRef for a long time now, but most 
people still write str.mid(n).toInt() instead of str.midRef().toInt(). 
QStringView won't change that: A function taking QStringView accepts a 
QString, too (either by implicit conversion, or where it makes sence, by 
QString overload).

Thanks,
Marc

On Friday 16 October 2015 21:42:23 Kurt Pattyn wrote:
> Marc,
> 
> It is clear that your main concern is performance (needless conversions)
> and convenience (being able to work efficiently with 3rd party libraries).
> Regarding performance, I think it would be good if we could come up with
> some numbers. How 'bad' is the current implementation compared to an
> 'ideal' situation? And then define some acceptable target keeping into
> account convenience. Otherwise I am afraid that discussions can keep going
> forever over 1 instruction more or less. Regarding convenience, and that
> is what Qt is all about, I think you made a tremendous proposal that can
> really bring Qt a big step forward. The idea is very sound and clear. Of
> course, there are technical challenges, but that is what we are supposed
> to solve.
> 
> I also agree that we should aim for simplicity. QString and QStringView is
> simple to understand, iff we can get rid of all other string related
> classes. The ideal case would be just to have one QString class, although
> I doubt that is achievable.
> 
> I think it w

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

[Branislav Katreniak]

Thiago described Qt6 QString as { QArrayData *d; ushort* b; qsize size }.
That is pretty close to QStringView, just extra *d makes it slightly bigger.

This is how I understand this class:
QString will have (typical) case when b points into d. QString own one
reference in d in this case.
QString will have special case when b points to text section and d does not
own anything.
QString will have special case for SSO.

Can QString have special case for not owned, non persistent b pointer
(non-owning / view mode)?

Non-owning QString can be created with special static QString method. It
stays non-owning only while being passed through const &. Code that cares
about keeping QString in view mode, must stick to const QString & all the
time. Copy assignment on non-owning QString results in owning QString - it
triggers deep copy into newly created shared data.

It solves the queued connection problem that existed with QStringView
class. I suppose that queued connection internally performs QString copy.

I have no idea about performance implications for code paths that do not
care about this use case. But having just one string class would be very
convenient.

Kind regards
 Brano
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Kurt Pattyn]

Marc,

It is clear that your main concern is performance (needless conversions) and 
convenience (being able to work efficiently with 3rd party libraries).
Regarding performance, I think it would be good if we could come up with some 
numbers. How 'bad' is the current implementation compared to an 'ideal' 
situation? And then define some acceptable target keeping into account 
convenience. Otherwise I am afraid that discussions can keep going forever over 
1 instruction more or less.
Regarding convenience, and that is what Qt is all about, I think you made a 
tremendous proposal that can really bring Qt a big step forward. The idea is 
very sound and clear. Of course, there are technical challenges, but that is 
what we are supposed to solve.

I also agree that we should aim for simplicity. QString and QStringView is 
simple to understand, iff we can get rid of all other string related classes. 
The ideal case would be just to have one QString class, although I doubt that 
is achievable.

I think it would be good to come up with some real-world use-cases that show 
how a Qt user and a Qt application could benefit from your proposal. 
Personally, I never experienced a performance problem with QString; but then 
the applications I write are not very string oriented. I am a QString 
aficionado :-)

After all, what I really like about Qt is convenience, simplicity and 
portability. I think this should be the main focus of Qt, and that also implies 
smooth collaboration with the outside world.

Cheers,

Kurt

> On 16 Oct 2015, at 21:47, Marc Mutz  wrote:
> 
>> On Friday 16 October 2015 19:31:50 Thiago Macieira wrote:
>> The conversion from one to the other is one instruction.
> 
> Which is one instruction too much for tail-call optimisation, e.g.
> 
> But the point was about std::string_view binary compatibility. As basically a 
> C struct with no ownership semantics, it would be a perfect vehicle to pass 
> strings around different programming languages and compilers, but only if the 
> ABI (ie. the data members) were specified.
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 16 October 2015 19:31:50 Thiago Macieira wrote:
> The conversion from one to the other is one instruction.

Which is one instruction too much for tail-call optimisation, e.g.

But the point was about std::string_view binary compatibility. As basically a 
C struct with no ownership semantics, it would be a perfect vehicle to pass 
strings around different programming languages and compilers, but only if the 
ABI (ie. the data members) were specified.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On Friday 16 October 2015 19:03:18 Marc Mutz wrote:
> The problem is that I feel we can't wait for string_view because we already 
> drown in QString equivalents. Plus, we'd get the usual replies if anyone
> suggested to use std::string_view as such a fundamental Qt type. Naturally,
> QStringView would trivially convert to and from std::u16string_view with no
> runtime overhead (unless compiler writers ruin the concept of string_view
> by implementing it as (T*, size_t) in one compiler and (T*, T*) in
> another)

The conversion from one to the other is one instruction.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 16 October 2015 17:03:41 Koehne Kai wrote:
> I guess it's not by incidence that there's also a std::string_view coming,
> see e.g.
> 
> https://www.youtube.com/watch?v=H9gAaNRoon4
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html
> 
> So, is this really the same, except non-templated and for QString (with
> conversion from/to Qt types)? Or do you have other differences in mind?

Nothing qualitatively different. Just std::basic_string_view with a 
subset of QString API, yes.

The problem is that I feel we can't wait for string_view because we already 
drown in QString equivalents. Plus, we'd get the usual replies if anyone 
suggested to use std::string_view as such a fundamental Qt type. Naturally, 
QStringView would trivially convert to and from std::u16string_view with no 
runtime overhead (unless compiler writers ruin the concept of string_view by 
implementing it as (T*, size_t) in one compiler and (T*, T*) in another)

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Updating the minimal supported version of libxcb

[Paeglis Gatis]

> Another question is what to do with the bundled libraries?

The -qt-xcb switch is there to reduce run-time dependencies. There always will 
be somebody who wants
to run the latest Qt version on some old linux distribution. 

Also I think it was decided that in Qt5 we can remove support for 
-no-x11extenssion-name switches in the Qt
configure script. There is always -qt-xcb available if your distro does not 
provide the required dependencies. And it does not add any value not to 
compile-in the extension code. It should be a runtime decision, if X server has 
an extension available, we use it.


From: development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
 on behalf 
of Александр Волков 
Sent: Friday, October 16, 2015 2:02 PM
To: Knoll Lars; Thiago Macieira; development@qt-project.org
Subject: Re: [Development] Updating the minimal supported version of libxcb

16.10.2015 09:28, Knoll Lars пишет:
> On 15/10/15 17:59, "Thiago Macieira"  wrote:
>
>> On Thursday 15 October 2015 18:26:23 Александр Волков wrote:
>>> Hi,
>>>
>>> Currently Qt supports libxcb 1.5, which is very old (it was released on
>>> December 3, 2009)
>>> It complicates adding new bundled xcb libraries, because they have to be
>>> checked
>>> for compatibility with this old version and maybe patched.
>>>
>>> Qt officially supports the following platforms that use libxcb:
>>> OpenSuSE 13.1 (libxcb 1.9.1, xcb-proto 1.8)
>>> Red Hat Enterprise Linux 6.6 (libxcb 1.9, xcb-proto 1.8)
>>> Ubuntu 14.04 - 64bit (libxcb 1.10, xcb-proto 1.10)
>>>
>>> What do you think about updating the minimal supported version of libxcb
>>> to 1.9?
>> Unless it's critical, let's do it only in 5.7.
> Yes, I don’t know of larger issues that would require a change in 5.6. But
> for 5.7 by all means go ahead and update the minimum requirement to 1.9.

Another question is what to do with the bundled libraries?
With libxcb 1.9 they are all provided by the supported distros.
The only exception is xcb-xkb, which we require to be from libxcb 1.10.
So my proposal is to remove them from Qt, remove configure options -qt-xcb
and -system-xcb, and use the bundled xcb-xkb library if we can't find
the appropriate version on the system.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Koehne Kai]

I guess it's not by incidence that there's also a std::string_view coming, see 
e.g.

https://www.youtube.com/watch?v=H9gAaNRoon4

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html

So, is this really the same, except non-templated and for QString (with 
conversion from/to Qt types)? Or do you have other differences in mind?

Regards

Kai

> -Original Message-
> From: development-bounces+kai.koehne=theqtcompany@qt-project.org
> [mailto:development-bounces+kai.koehne=theqtcompany@qt-project.org]
> On Behalf Of Marc Mutz
> Sent: Tuesday, October 13, 2015 10:47 PM
> To: development@qt-project.org
> Subject: [Development] RFC: Proposal for a semi-radical change in Qt APIs
> taking strings
> 
> Hi,
> 
> After looking quite a bit into the current state of string handling in Qt for 
> my
> QtWS talk last week, I have become frustrated by the state of string handling 
> in
> Qt.
> 
> We have such powerful tools for string handling (QStringRef, QStringBuilder),
> but all APIs outside QString and its immediate surroundings only deal in 
> QString.
> The correct way would be to overload every function taking QString with
> QLatin1String and QStringRef versions, and then, for some other rare cases,
> const QChar *, int size. Let alone std::basic_string.
> 
> I would therefore like to propose to abandon QString for new API (and over 
> time
> phase it out of existing API), and only provide (const QChar*, size_t) as the 
> most
> general form. I would propose to package the two into a class, called
> - you guessed it - QStringView.
> 
> =FAQ=
> 
> Q: Why not just use QStringRef?
> 
> A: QStringRef is tied to QString. E.g. you can't create a QStringRef from a 
> pair of
> QChar*, int. It also is kind of stuck in historic mistakes making it 
> undesireable as
> a cheap-to-pass parameter type.
> 
> Q: What mistakes do you refer to?
> 
> A: The fact that it has copy ctor and assignment operator, so it's not a 
> trivally-
> copyable type and thus cannot efficiently passed by-value. It may also be too
> large for pass-by-value due to the rather useless QString pointer (should have
> been QStringData*, if any). Neither can be fixed before Qt 6.
> 
> Q: Why size_t?
> 
> A: The intent of QStringView (and std::experimental::string_view) is to act 
> as an
> interface between modules written with different compilers and different 
> flags.
> A std::string will never be compatible between compilers or even just 
> different
> flags, but a simple struct {char*, size_t} will always be, by way of it's C
> compatibility.
> 
> So the goal is not just to accept QString, QStringRef, and (QChar*,int) (and
> QVarLengthArray!) as input to QStringView, but also
> std::basic_string and std::vector.
> 
> Q: What about the plans to make QString UTF-8-backed?
> 
> A: QStringView-using code will need to be ported just as QString-using code 
> will.
> 
> Q: What future do you have in mind for QStringRef?
> 
> A: None in particular, though I have found a need for an owning QStringRef in
> some places. But I expect Qt 6' QString to be able to provide a restricted 
> view on
> shared data, such that it would subsume QStringRef completely.
> 
> Q: What about QLatin1String?
> 
> A: Once QString is backed by UTF-8, latin-1 ceases to be a special charset. We
> might want something like QUsAsciiString, but it would just be a UTF-8 
> string, so
> it could be packed into QStringView.
> 
> Q: What about QByteArray, QVector?
> 
> A: I'm unsure about QByteArrayView. It might not pull its weight compared to
> std::(experimental::)string_view, but I also note that we're currently 
> missing a
> QByteArrayRef, so a QBAView might make sense while we wait for the std one
> to become available to us.
> 
> I'm actively opposed to a QArrayView, because I don't think it provides us 
> with
> anything std::(experimental::)array_view doesn't already.
> 
> Q: What about a rope?
> 
> A: A rope is a more complex string that can provide complex views on existing
> data as well as store rules for generating stretches of data (as opposed to 
> the
> data itself).
> 
> A rope is a very complex data structure and would not work as a universal
> interface type. It would be cool if Qt had a rope, but that is outside the 
> scope of
> my proposal.
> 
> Q: What do you mean when you say "abandon QString"?
> 
> A: I mean that functions should not take QStrings as arguments, but
> QStringViews. Then users can transparently pass QString, QStringRef and any of
> a number of other "string" types without overloading the function on each of
> them.
> 
> I do not mean to abandon QString, the class. Only QString, the interface type.
> 
> Q: What API should QStringView have?
> 
> A: Since it's mainly an interface type, it should have implicit conversions 
> from all
> kinds of "string" types, but explicit conversion _to_ those string types. It 
> should
> carry all the API from QString that can be implemented on just a (QChar*, 
> size_t)
> (e.g. trimmed(), le

Re: [Development] Qt 5.6.0 header diff: QtWidgets.diff

[Marc Mutz]

On Monday 21 September 2015 11:05:52 Knoll Lars wrote:
> QDesktopWidget::primaryScreenChanged signal
> -> IMO this should be added as NOTIFY to the corresponding property.

The signal is missing the int argument

int primaryScreen()
-> primaryScreenChanged(int),
not: primaryScreenChanged()

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Konstantin Ritt]

>
> > You're misrepresenting the argument. QString doesn't support other
> encodings
> > because UTF-16 is the best for the task at hand and we have too much
> legacy to
> > support. Because of that, QCollator only supports UTF-16.
>
> I buy the legacy argument but I don't buy that utf 16 is the best
> encoding. I think because of legacy we cannot change QString but I think we
> should still support UTF 8 better.
>

So what? This doesn't change the fact UTF-16 has advantages over UTF-8 and
thus QString's backing storage is UTF-16 - and won't be changed to anything
else.


Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 16 October 2015 13:28:57 Иван Комиссаров wrote:
> Back to the topic.
> Marc, what usecases of QStringView are not covered with QString { ushort*
> data; int size; QStringData *refcount; }
> Not sure i understand that "interface" terminology. Would it be possible to
> pass QStringView to other (non-qt) APIs?

See my mail to Martin today.

While not the first reason to create a QStringView, yes, a (ushort*, ushort*) 
can allow zero-copy string transfer between at least C, C++ and Java, possibly 
also JavaScript. So it may have a direct benefit for QML, though I don't know 
that code at all.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 16 October 2015 09:53:56 Smith Martin wrote:
> Then after we add QStringView, we will have QString for containing a string
> and QStringView for passing its contents out of Qt?

Yes, except for "out of Qt". We already have - within Qt - lots of equivalent 
ways to provide a QChar-based string - and QString is only one (QStringRef and 
QVarLengthArray are others, as is QChar[]).

As I said before, this is very similar to Q(Persistent)ModelIndex - QMI is the 
interface type, and it's transparent to the compiler and thus efficient to work 
with. QPMI is the storage type, intransparent to the compiler and very slow to 
work with.

HTH,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Updating the minimal supported version of libxcb

[Александр Волков]

16.10.2015 09:28, Knoll Lars пишет:
> On 15/10/15 17:59, "Thiago Macieira"  wrote:
>
>> On Thursday 15 October 2015 18:26:23 Александр Волков wrote:
>>> Hi,
>>>
>>> Currently Qt supports libxcb 1.5, which is very old (it was released on
>>> December 3, 2009)
>>> It complicates adding new bundled xcb libraries, because they have to be
>>> checked
>>> for compatibility with this old version and maybe patched.
>>>
>>> Qt officially supports the following platforms that use libxcb:
>>> OpenSuSE 13.1 (libxcb 1.9.1, xcb-proto 1.8)
>>> Red Hat Enterprise Linux 6.6 (libxcb 1.9, xcb-proto 1.8)
>>> Ubuntu 14.04 - 64bit (libxcb 1.10, xcb-proto 1.10)
>>>
>>> What do you think about updating the minimal supported version of libxcb
>>> to 1.9?
>> Unless it's critical, let's do it only in 5.7.
> Yes, I don’t know of larger issues that would require a change in 5.6. But
> for 5.7 by all means go ahead and update the minimum requirement to 1.9.

Another question is what to do with the bundled libraries?
With libxcb 1.9 they are all provided by the supported distros.
The only exception is xcb-xkb, which we require to be from libxcb 1.10.
So my proposal is to remove them from Qt, remove configure options -qt-xcb
and -system-xcb, and use the bundled xcb-xkb library if we can't find
the appropriate version on the system.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Иван Комиссаров]

Back to the topic.
Marc, what usecases of QStringView are not covered with QString { ushort*
data; int size; QStringData *refcount; }
Not sure i understand that "interface" terminology. Would it be possible to
pass QStringView to other (non-qt) APIs?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Outfit based collation (was: RFC: Proposal for a semi-radical change in Qt APIs taking strings)

[Knoll Lars]

Wow... I have no idea how my mail client autocorrected utf8 to Outfit. :)

Cheers,
Lars

On 16/10/15 12:53, "Knoll Lars"  wrote:

>Hi Marco,
>
>On 16/10/15 11:46, "Bubke Marco"  wrote:
>>
 That is the
 power of iterators and with the new features of C++ they get really
useful.
 But anyway,  I don't say that we have to change everything. The last
time
 we did that we broke our event system which is still not working like
it
 was before we introduced QWindow. I think we  should have an
evolutionary
 process to  adapt to the  changing environment and not try to
reiterate
 what was successful in the past.
>>>
>>> I agree with what you said in this paragraph. But it does not lead to a
>>> conclusion about using UTF-8 or even providing our own UTF-8 class.
>>>
>>
>>Introducing an utf 8 class is not that hard but providing the framework
>>around. Collations are the problem. We have to use utf8 in QtCreator
>>anyway so we could find out what is an useful API.  But colation support
>>in Qt would be really helpful in the longer run.
>
>The problem with Collation and utf-8 is that the only API offering utf-8
>based collation is ICU (which offers both utf-8 and utf-16 based
>collation). Mac and Windows only offer utf-16.
>
>So we’d still need to convert in most cases. It would probably be possible
>to do that on the stack for small strings to avoid a malloc though. So we
>can discuss adding a QCollator::collateUtf8(const char *s1, int len1,
>const char *s2, int len2).
>
>But just out of curiosity, where does Creator need collation in a
>performance critical place?
>
>Cheers,
>Lars
>
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Outfit based collation (was: RFC: Proposal for a semi-radical change in Qt APIs taking strings)

[Knoll Lars]

Hi Marco,

On 16/10/15 11:46, "Bubke Marco"  wrote:
>
>>> That is the
>>> power of iterators and with the new features of C++ they get really
>>>useful.
>>> But anyway,  I don't say that we have to change everything. The last
>>>time
>>> we did that we broke our event system which is still not working like
>>>it
>>> was before we introduced QWindow. I think we  should have an
>>>evolutionary
>>> process to  adapt to the  changing environment and not try to reiterate
>>> what was successful in the past.
>>
>> I agree with what you said in this paragraph. But it does not lead to a
>> conclusion about using UTF-8 or even providing our own UTF-8 class.
>>
>
>Introducing an utf 8 class is not that hard but providing the framework
>around. Collations are the problem. We have to use utf8 in QtCreator
>anyway so we could find out what is an useful API.  But colation support
>in Qt would be really helpful in the longer run.

The problem with Collation and utf-8 is that the only API offering utf-8
based collation is ICU (which offers both utf-8 and utf-16 based
collation). Mac and Windows only offer utf-16.

So we’d still need to convert in most cases. It would probably be possible
to do that on the stack for small strings to avoid a malloc though. So we
can discuss adding a QCollator::collateUtf8(const char *s1, int len1,
const char *s2, int len2).

But just out of curiosity, where does Creator need collation in a
performance critical place?

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Allan Jensen as maintainer for Qt WebEngine

[Peter Varga]

+1

On 10/15/2015 11:25 AM, Koehne Kai wrote:
> Hi,
>
> I hereby nominate Allan Jensen as the official maintainer for the Qt 
> WebEngine module. He's been the official maintainer for Qt WebKit already, 
> but nowadays works full time on Qt WebEngine, and is also the default 
> assignee for the WebEngine component in JIRA.
>
> Regards
>
> Kai
>

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

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 why many people use Qt,  they want to have a
>> GUI but don't want to invest to much time in it. The interesting stuff 
>> which is differentiating you from others is mostly home grown in connection
>> with much more specialized libraries. And this libraries are much more
>> important to the users. So we should support them, their interfaces and not
>> force our interfaces on them. 
>
> That's a slippery slope. If we have to support every library's interface, 
> we'll have a horrible mish-mash of an API that tries to support everything 
> and 
> doesn't support anything really well.

I agree but do we have not that already. We have so many modules which are not 
up to a really big job. They are very convenient but you can run in performance 
trouble because they are slower. It is a trade off and we  choosed convenience. 
Then you try an other solution and you feel the pain of a break. You have to 
change so much because integrating the external solution in Qt is quite hard. 
What would be your feelings in that case? ;-) 

I think in that case we should make it easier to integrate the external 
solution. 

> I'd rather we supported the "One Qt Way" really well. Supporting other ways 
> is 
> possible, as long as we don't cause too much maintenance trouble.

But is the "One Qt Way" not historical grown. Why did we avoid the standard 
library. Was it because we thought our way is better? Or because it was broken 
for a very long time. The usability of the standard library get better and 
better so we have maybe reevaluate their usefulness.

>> I know binary
>> compatibility is important for you but is it really that important outside
>> of the special linux distribution cocoon. 
>
> Yes. Lots of users don't recompile the world when Qt issues a new release, 
> but 
> still try to upgrade.

But I  don't see how this usecase would be broken by the standard library. They 
have their ABI breaks like we have ours but it is not that horrible. Actually 
how many applications do you know which ships not their own libraries and are 
not part of the distribution do you know? 

> And besides, if we have to maintain binary compatibility for 99% of the API 
> anyway because of Linux distributions, then we might as well go the extra 
> mile 
> and keep it for everyone.

Do we really have it? Is it really worth the price of all tge overhead? 

>> Is it important under Windows, 
>> is it important under Mac, is it important under embedded Linux? I think
>> the advantages are smaller than the drawbacks.
>
> I disagree.

;-) I think it is hard to argument about it because it depends so much on the 
context. 

> Not to mention that "embedded Linux" these days is not different from 
> "regular 
> Linux". Even devices with 32 MB of RAM have package managers and install 
> software from a central repository.

Do you would really install a stock Qt or if it would be easy use a tailored 
version of Qt for your usecase. If every penny counts and the difference 
between a stock and an optimized version would make the difference I would 
choose the last. But it should be easy. 

It would nice if Qt could be compiled easily with feedback optimization and 
link time optimization. And if we strip automatically everything away which 
isn't used. :-) 

>> > That's one of the two main advantages of native code. There's no sandbox
>> > to
>> > escape from.
>> > 
>> > Qt already supports doing locale-aware comparison. We even have a class
>> > for
>> > it, so it can be done efficiently: QCollator and it supports our native
>> > string type (QString).
>> 
>> Do you like to live on a native island?
>
> Yes. I love writing native code. That's one of the biggest powers of Qt 
> compared to any other cross-platform solution out there. So, yeah, native 
> island is good.

I  meant the use of native as Qt native. I love native too but I don't love it 
that much that I need to many. ;-) I think the native solutions should 
integrate with each other quite well and not diverge to much from each other. 

> Did you mean to ask if I like constraining myself to only Qt-style APIs? The 
> answer is also yes. I hate the Standard Library API because it's confusing 
> (to 
> me, obviously not so much to the people who wrote it), limited in convenience 
> forcing me to write more code than focusing on getting stuff done. I often 
> feel 
> that the Standard Library tries to achieve 100% support of some tiny feature, 
> overengineering it and not focusing on making developers' lives easier. The 
> example is std::chrono.

Okay, in the last time after reevaluating the standard library I like it very 
much. Some concepts are still not very nice but I like many features much 

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

[Ziller Eike]

> On Oct 16, 2015, at 9:10 AM, Poenitz Andre  
> wrote:
> 
> 
> Marc Mutz wrote:
>>> I think too we should embrace the standard library more and don't replicate
>>> their features.
>> 
>> So you think that QStringView is too experimental and _at the same time_
>> replicating the standard. Sounds paradoxal to me.
> 
> It's not paradoxical at all. It would be a new implementation with the usual 
> need for maturing even if it implements a well-known standard concepts.
> 
> And there is indeed room for actual experiments, e.g. when it comes 
> structure layout. Pointer+int offset is not the only possible choice. 
> 
> You cannot do that in Qt proper, due to BC promises.

And there would also be some room in Qt Creator to experiment with and gather 
experience on how all this fits with corresponding API changes, which I also do 
not see how that could be done in Qt without lots of #ifdefs.

> Compile-time opt-in
> is a way to exempt it from BC, but then your main reason to have it in Qt 
> and not in Creator, namely 'more widespread use', is void, as barely anyone 
> will opt in. You'll get more public exposure (with less risk!) if it's used by
> default in Creator code for a while before the then-matured implementation
> goes to the library.
> 
> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Smith Martin]

Then after we add QStringView, we will have QString for containing a string and 
QStringView for passing its contents out of Qt?

martin


From: m...@kdab.com  on behalf of Marc Mutz 
Sent: Friday, October 16, 2015 10:07 AM
To: Smith Martin
Cc: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in  Qt   
APIs taking strings

On Friday 16 October 2015 07:59:40 Smith Martin wrote:
> Can you refocus the discussion for everyone? For me at least?
>
> QString is my favorite class of all time. I use it every day in every
> program; it always works, and I never make a mistake.

Then you can continue to be blissfully ignorant of reality as you are :) If
you are a QString fanboy and don't care about 3rd-party code and/or efficiency,
then you can just continue as before.

> 1. What is the problem with QString that QStringView will solve?

TL;DR: Inefficient conversion from/to QString, leading to inefficiencies within
pure Qt-code and in particular when interfacing with 3rd-party code, BiC
issues,

> 2. Why can't QString be fixed?

Because it is a container, not an interface type.

An interface type needs to be BC across most of compilers and languages (incl.
C and - potentially Java).

A container needs to handle (as in own) memory. An interface type (quite
obviously, if it's to work with C, too) cannot.

> 3. What is a string view?

A pimped { QChar *begin, QChar *end; }

Thanks,
Marc

--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] r-value references in API (was: RFC: Proposal for a semi-radical change in Qt APIs taking strings)

[Koehne Kai]

> -Original Message-
> From: development-bounces+kai.koehne=theqtcompany@qt-project.org
> [mailto:development-bounces+kai.koehne=theqtcompany@qt-project.org]
> On Behalf Of Bubke Marco
> Sent: Thursday, October 15, 2015 10:14 PM
> To: Thiago Macieira ; development@qt-
> project.org
> Subject: Re: [Development] r-value references in API (was: RFC: Proposal for a
> semi-radical change in Qt APIs taking strings)
> 
> On October 15, 2015 17:58:27 Thiago Macieira 
> wrote:
> 
> > On Thursday 15 October 2015 07:34:30 Koehne Kai wrote:
> >> > -Original Message-
> >> > [...]
> >> >
> >> > >BTW: functions storing a passed QString as-is should provide a
> >> > >QString&& overload, and that might be a good idea even when
> >> > >otherwise using QStringView only.
> >> >
> >> > Yes, agree with this.
> >>
> >> I guess this advice is not only for QString arguments though (from
> >> 5.7 onwards). Which other types should get an && overload?
> >>
> >> Does API exposed via Q_PROPERTY/ QML benefit from an r-value
> >> reference overloads, too?
> >>
> >> I think it's a good idea to create some recommendations for 5.7 now,
> >> before everyone develops his own rules ...
> >
> > I didn't address this in my reply to Marc...
> >
> > This part of his proposal falls apart the moment that the API function
> > calls something else to do the processing. Now you need to duplicate
> > almost every code path from the user-facing API down to the processing
> > of the data. And when the API has two data types, now the permutations
> explode...
> >
> > rvalue refs only make sense for very simple sink functions. Not even
> > most QString overloads would be able to do it.

Ok. I'll try to rephrase this then to come up with an easy advice:

'''
Consider providing an && overload for simple setter functions that take a not 
trivially copyable value type as an argument (e.g. QString, QVector ...). 

For example:

void setName(const QString &name) {  m_name = name; }
void setName(QString &&name) { m_name = std::move(name); }
'''


Anyhow, we could also decide that, now that we expect C++11 to be available, we 
can also rely on move semantics and only use pass-by-value. This was actually 
suggested by Olivier in 2012 (!), see 
http://permalink.gmane.org/gmane.comp.lib.qt.devel/3484 :

Lars replied back then though that this "moves the code required for making the 
copy for the cases where the compiler can't optimize it away to the caller, ie. 
from a shared to a non shared location. This can increase the total size of the 
code generated." (see http://permalink.gmane.org/gmane.comp.lib.qt.devel/3502).

Olivier then retracted the proposal. Should we reconsider it though, now that 
we can expect C++11 from 5.7 onwards? Or does the code size increase still 
hold? Shall we do some more experiments with this?

> I see the move semantics as a good way for ownership transfer. It is a much
> better ideom than sharing because you easily ask for țrouble if you share.
> Working on the same data structure from many processors is very inefficient. 
> So
> the move semantics would make it clear that you should not share. Otherwise if
> you want process read only data you can use const references. I think the new
> model is much better than all type of pointers. The problem with pointers is 
> that
> they can be null and you should check in interfaces but semantically you have 
> no
> description in your concept that the structure is not there.

I understand that there are other uses of r-value references, but for the 
moment I'd personally like to keep the discussion focused on simple setter 
functions, because they're so common.

Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

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 own
>> > threads (with a tip of the hat to Kai).
>> 
>> Good argument but actually I think before we introduce something new to our
>> string handling we should test it out. Why not add it Qt creator like
>> André proposed and see how it works.
>
> I have already answered why I think this is a bad idea.

Yes, I read it. That why I proposed the experimental playground. It is not so 
much about QStringView but about the following changes. What is so bad about to 
play around features before we see all the implications. My experiences whisper 
to me that if I like an idea too much I should be careful because I love to 
ignore unpleasant side effects. 

>> I think we don't want to end with something like our model view system or
>> QtControls. Lets test it before we make changes.
>> 
>> I think too we should embrace the standard library more and don't replicate
>> their features.
>
> So you think that QStringView is too experimental and _at the same time_ 
> replicating the standard. Sounds paradoxal to me.

Is it already in the standard? The standard has an experimental stage too. And 
I  like this concept very much. 

>> A better process to add features would be helpful too.  First they should
>> be experimental so we can change them easily. Second we should be better
>> at removing features. If we do not remove things we will getting slower
>> and slower to add new interesting stuff. It is hard to find the balance
>> but if you are too conservative you will getting slowly less used. We
>> tried to be very innovative with Qml and we learned much about it.
>> 
>> So the question is how can we maximize the usefulness of Qt with our man
>> power. Is replicating the standard library really helping?
>
> My stance on replicating std functionality and the NIH syndrome should by now 
> be above suspicion, even for the casual reader.

It was not about you or me. It was about us an organization. How we can work 
better together. How can we make a difference, how can we help other 
developers. 

> I have already argued why I think QStringView is needed, but QArrayView is 
> not.

Sorry if you got the impression it was about you. I should be more careful with 
my arguments. I try to disconnect arguments from the self. I thinking the 
argument should stand for himself in his context and not so much by the person 
who speaks it. 

To make it clear,  I find QStringView promising but still we should explore the 
concept with all their implications more. Actually I think we sould add more of 
this kind of changes in an experimental stage like #include 
. So we are forced to evaluate for every release 
how it works out and if it looks well we move it to the normal include path. So 
experimental would be an area in every repository so that everybody could try 
it out. 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Poenitz Andre]

Marc Mutz wrote:
> > I think too we should embrace the standard library more and don't replicate
> > their features.
> 
> So you think that QStringView is too experimental and _at the same time_
> replicating the standard. Sounds paradoxal to me.

It's not paradoxical at all. It would be a new implementation with the usual 
need for maturing even if it implements a well-known standard concepts.

And there is indeed room for actual experiments, e.g. when it comes 
structure layout. Pointer+int offset is not the only possible choice. 

You cannot do that in Qt proper, due to BC promises. Compile-time opt-in
is a way to exempt it from BC, but then your main reason to have it in Qt 
and not in Creator, namely 'more widespread use', is void, as barely anyone 
will opt in. You'll get more public exposure (with less risk!) if it's used by
default in Creator code for a while before the then-matured implementation
goes to the library.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[André Somers]

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 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 clearly shows UTF-16
covers
> [almost] all spoken languages, without any performance hits (in
> compare to UTF-8), and all we have to pay is an extra byte per every
> Base Latin character (in compare to UTF-8, again).
>
> [1] http://www.unicode.org/Public/8.0.0/ucd/Scripts.txt
>
"All we have to pay"? Isn't that quite a significant cost, if your
every
other byte in your data is going to be null?


Only for US-ASCII / Latin-1.

What percentage of the strings you deal with in your applications falls 
withing that category? I can tell you that for us (dealing with 
databases, XML, etc.) that percentage is quite high. Even if we do 
translate our user interfaces to support Chinese among other languages. 
The vast majority of the strings in our application would fare very well 
with UTF-8 indeed. The user visible strings are but a tiny fraction. You 
have also been shown the source for Google.cn page as a nice example.


André


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Knoll Lars]

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 different interfaces between
>> different platforms. That is why many people use Qt,  they want to have
>>a
>> GUI but don't want to invest to much time in it. The interesting stuff
>> which is differentiating you from others is mostly home grown in
>>connection
>> with much more specialized libraries. And this libraries are much more
>> important to the users. So we should support them, their interfaces and
>>not
>> force our interfaces on them.

Other libraries are important to our users, but you underestimate how many
of them are using Qt if you think they are more important. And in any
case, we do not know the APIs that these libraries are using.
>> 
>
>That's a slippery slope. If we have to support every library's interface,
>we'll have a horrible mish-mash of an API that tries to support
>everything and 
>doesn't support anything really well.
>
>I'd rather we supported the "One Qt Way" really well. Supporting other
>ways is 
>possible, as long as we don't cause too much maintenance trouble.

Yes. Consistency in our APIs and ease of use is extremely important. This
is a lot of what made Qt what it is today.
>
>> How many users use the standard library too,
>> especially the new features, why don't we support them not much better.
>>Why
>> do we have to reinvent the wheel again and again.
>
>I won't bother repeating the arguments of why we can't use some of the
>standard library features. And see the discussion on std::chrono as a
>replacement for QTime(Span).

Let’s take this the other way round. Many developers shy away from C++
because they see the STL as rather complex and hard to use API. They
learning curve for newcomers is extremely steep.

Qt has always been about making C++ easier to use, and bringing it in line
with other languages such as Java. This has been a good part of the reason
behind our success. Let’s not forget that many of our users are not C++
experts. They are often engineers that simply want to get their work done.
>
>> I know binary
>> compatibility is important for you but is it really that important
>>outside
>> of the special linux distribution cocoon.
>
>Yes. Lots of users don't recompile the world when Qt issues a new
>release, but 
>still try to upgrade.
>
>And besides, if we have to maintain binary compatibility for 99% of the
>API 
>anyway because of Linux distributions, then we might as well go the extra
>mile 
>and keep it for everyone.
>
>> Is it important under Windows,
>> is it important under Mac, is it important under embedded Linux? I think
>> the advantages are smaller than the drawbacks.
>
>I disagree.
>
>Not to mention that "embedded Linux" these days is not different from
>"regular 
>Linux". Even devices with 32 MB of RAM have package managers and install
>software from a central repository.

This is a discussion that’s recurring every two years. Apart from the
upgradability, there is the large advantage that keeping SC and BC is a
way to restrict ourselves from changing too much. This is not to be
underestimated, as our users very much value the stability.

Yes, I also have a list of things I’d like to change in a non BC way, so
probably have many other people on the mailing list. But there is no way,
we would be able to do all these changes without also breaking source
compatibility. And that is something we can only do very rarely.
>
>> > That's one of the two main advantages of native code. There's no
>>sandbox
>> > to
>> > escape from.
>> > 
>> > Qt already supports doing locale-aware comparison. We even have a
>>class
>> > for
>> > it, so it can be done efficiently: QCollator and it supports our
>>native
>> > string type (QString).
>> 
>> Do you like to live on a native island?
>
>Yes. I love writing native code. That's one of the biggest powers of Qt
>compared to any other cross-platform solution out there. So, yeah, native
>island is good.
>
>Did you mean to ask if I like constraining myself to only Qt-style APIs?
>The 
>answer is also yes. I hate the Standard Library API because it's
>confusing (to 
>me, obviously not so much to the people who wrote it), limited in
>convenience 
>forcing me to write more code than focusing on getting stuff done. I
>often feel 
>that the Standard Library tries to achieve 100% support of some tiny
>feature, 
>overengineering it and not focusing on making developers' lives easier.
>The 
>example is std::chrono.

+1. While I see that lots is happening in STL land, unfortunately the APIs
feel very alien to someone being used to Qt style APIs. They feel even
worse for someone coming from Java or most other languages.
>
>> > Providing extra support for a character encoding that is not what
>>QString
>> > uses falls in that 1%. Just use I

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

[Marc Mutz]

On Friday 16 October 2015 07:59:40 Smith Martin wrote:
> Can you refocus the discussion for everyone? For me at least?
> 
> QString is my favorite class of all time. I use it every day in every
> program; it always works, and I never make a mistake.

Then you can continue to be blissfully ignorant of reality as you are :) If 
you are a QString fanboy and don't care about 3rd-party code and/or efficiency, 
then you can just continue as before.

> 1. What is the problem with QString that QStringView will solve?

TL;DR: Inefficient conversion from/to QString, leading to inefficiencies within 
pure Qt-code and in particular when interfacing with 3rd-party code, BiC 
issues,

> 2. Why can't QString be fixed?

Because it is a container, not an interface type.

An interface type needs to be BC across most of compilers and languages (incl. 
C and - potentially Java).

A container needs to handle (as in own) memory. An interface type (quite 
obviously, if it's to work with C, too) cannot.

> 3. What is a string view?

A pimped { QChar *begin, QChar *end; }

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development