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

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

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

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] Updating the minimal supported version of libxcb

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

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

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

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

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

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

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] Outfit based collation (was: RFC: Proposal for a semi-radical change in Qt APIs taking strings)

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

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

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 work

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

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

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

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

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

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

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