Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bubke Marco]

Folly string is doing CoW only for sizes bigger than 255 and I believe Facebook 
has measured it because for them it is money. ;-) I am not sure if they use 
atomics. Maybe you could benchmark them too. 


On January 24, 2016 03:21:31 Marc Mutz  wrote:

> On Sunday 24 January 2016 03:01:57 Kevin Kofler wrote:
>> Marc Mutz wrote:
>> > On Friday 22 January 2016 20:46:54 Marc Mutz wrote:
>> >> Which one is faster? On a dual-core, probably QVector. On a 64-core
>> >> processor,  probably std::vector.
>> > 
>> > Running attached test program (4 cores + 2-fold HT), I get these numbers:
>>
>> That's already 8 virtual cores. He wrote "on a dual-core". :-)
>
> Not that I didn't post the code, so you could run the benchmark on your 
> machine, or with numThreads hard-coded to 2...
>
> QVector:
>
> 1: 111
> 2: 100
> 4: 111
> 8: 115
> 16: 139
> 32: 179
> 64: 204
> 128: 337
> 256: 644
> 512: 1287
> 1024: 2611
> 2048: 5020
> 4096: 10113
>
> std::vector:
>
> 1: 63
> 2: 63
> 4: 65
> 8: 69
> 16: 119
> 32: 198
> 64: 264
> 128: 375
> 256: 735
> 512: 1385
> 1024: 2719
> 2048: 5545
> 4096: 10444
>
> (numThread == 2, same box)
>
> Copying is still not significantly slower than ref-counting, even for 4K 
> elements.
>
> And yes, this suprises even me, but since it perfectly matches my 
> expecations, 
> at least qualitatively, I won't spend more time trying to understand this. 
> The 
> code is there, I took great care to make it fair, now the CoW fanboys can 
> explain this (or find a bug in the benchmark).
>
> At least it seems as if the allocator has a very fast path for 
> alloc/dealloc/alloc/dealloc/etc chains of a same-sized memory block.
>
> 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

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bubke Marco]

On January 24, 2016 21:11:18 Hausmann Simon <simon.hausm...@theqtcompany.com> 
wrote:

> Hi,
>
> Could you elaborate where you see copy on write causing writes to shared 
> cache lines? Are you concerned about the shared cache line for the reference 
> count?
>
> For reading MESI allows for shared cache lines and for hyper threads the 
> shared l1 data cache mode favors sharing and thus CoW.

I was speaking about distinct caches and the latency you introduce if you are 
invalidate a cache line. It really depends on your out of order implementation 
but so far I understand atomics are still much slower as if you simply not 
share at all. But like I said it is better to measure it. 

But my general question is why do we use CoW,  how often it helps, how often it 
hurts. What are other techniques? How can we help with tools,  so the we fix it 
much earlier and not at run time. Could we find out with some kind of profiling 
the cases where sharing would be good and add fixits for it? 
E.g.

You returned this really big member in the test run. We can change it to a 
shared pointer or a CoW container.  Do you want it?  Yes or no? 

Actually I think many mistakes like unneeded copies could be hinted by the code 
model too. 

> What am I missing to understand your statement?
>
>
> Simon
>
>   Original Message
> From: Bubke Marco
> Sent: Sunday, January 24, 2016 19:10
> To: Kevin Kofler; development@qt-project.org
> Subject: Re: [Development] Question about QCoreApplicationData::*_libpaths
>
>
> On January 24, 2016 17:45:36 Kevin Kofler <kevin.kof...@chello.at> wrote:
>
>> Marc Mutz wrote:
>>> (numThread == 2, same box)
>>>
>>> Copying is still not significantly slower than ref-counting, even for 4K
>>> elements.
>>
>> But it is already slower with as little as 32 elements, and stops being
>> significantly faster already at 16 elements.
>>
>> And now try with numThread == 1 for some extra fun. :-) A lot of code out
>> there is still single-threaded.
>>
>
>  Yes but in the future the processors getting more and more parallel. If I am 
> working on the bigger dataset with parallel algorithms I don't want to share 
> writes to the same cache like. Something which CoW is providing.
>
>> Kevin Kofler
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
> --
> Sent from cellphone, sorry for the typos
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bubke Marco]

Actually what is happen if I am in the middle of changing a qvector,  and then 
copying the vector in an other thread? 

--
Sent from cellphone, sorry for the typos



On January 22, 2016 18:34:46 Matthew Woehlke  wrote:

> On 2016-01-22 13:13, Marc Mutz wrote:
>> On Friday 22 January 2016 17:44:40 Thiago Macieira wrote:
>>> On Friday 22 January 2016 11:14:47 Marc Mutz wrote:
 On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote:
> What
> i'm missing?

 You haven't done the exercise with the int first.
>>>
>>> Here's the exercise with int. This is thread-safe:
>>>
>>> int f()
>>> {
>>> return 1;
>>> }
>>>
>>> auto x = f();
>>> ++x;
>>>
>>> No matter how many threads call f(), all of them will get a value from f,
>>> can assign it to a variable and modify without caring what other threads
>>> do.
>>>
>>> Replace int with QMap or QString and you have the same behaviour.
>> 
>> This part of the discussion was about copying a container. You return a new 
>> instance instead. Returning a new instance does not copy, nor move, due to 
>> NRVO.
>
> The same assertions would hold if Thiago had written:
>
>   int f()
>   {
> static int result = 1;
> return result;
>   }
>
> ...or anything else for the body of f().
>
> And in fact, you're again attacking a straw man. The implementation of
> getMap() was not shown; for all you know, it too might have returned a
> new instance every time. (Probably not, but doesn't matter.)
>
> What matters is that the result is returned *by value*. It is thread
> safe because it is not a reference, it is a copy. Qt containers are
> likewise thread safe because they behave (in a thread-safe manner) *as
> if* an actual copy was made (even though the actual copy might not
> happen until some time later, if ever).
>
> -- 
> Matthew
>
> ___
> 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] What kind of airplane we want to build?

[Bubke Marco]

On January 22, 2016 09:52:31 Hausmann Simon <simon.hausm...@theqtcompany.com> 
wrote:

> Hi,
>
> I think answering the question about the kind of airplane to build is closely 
> tied to another question that may be worthwhile
> asking. I think it's worthwhile because I'm convinced that answers diverge 
> greatly depending on who you ask.
>
> Why are we trying to build an airplane?
>
> Or differently put: What is our mission?
>
> Is our mission to transport people from A to B? Is the mission to transport 
> goods from A to B? Is our mission to get people from
> A to B in the quickest way? Or is it about safety? The answer greatly 
> influences the type of airplane to build (in the event that
> the airplane is the right method of transportation).
>
>
> I'm of the opinion that our mission should be to make life easier for 
> programmers.

I strongly agree with you. 

One of my fears is that we add too much implicit magic to make it easier for 
the novice but providing headache for the average programmer. The very 
experienced programmer will find a way around our magic so I don't care so much 
about him. 

One example is CoW and false sharing. CoW is good for novices but an average 
programmer who gets a performance problem which is popping up here and there 
because of false sharing is lost. 

And don't forget performance is a feature too. If your program is slow from 
time to time you have to fix it. Like I was running in performance problems 
with the clang code model. 

So I think we should try to provide a two layer approach. One layer without 
magic where you have to be very explicit and one with magic on top. 

In the sense of CoW for most cases it is not important. If we return a vector 
member of 100 small items from time to time the difference is nelectable in the 
big picture. Only on some hot spots it is getting important and here we have in 
my opinion to measure what is better. 

I don't know the answer but I mistrust every deductive anwser which is based on 
what you think. Modern computers are fat too complex to make a guess. It is far 
better to measure and to measure under a simular workload.. 

> That includes also novice programmers and especially people who's first 
> language is not English.
>
> Who else agrees with me?
>
> Ways to achieve that include tooling to increase work flow productivity, 
> intuitive and consistent APIs that are easy to remember
> and easy to use, especially for non-native english speakers. These are 
> considerations that greatly affect the naming of functions
> (which may or may not justify diverging from the STL for example).
>
>
> Simon
>
> ____
> From: Development <development-boun...@qt-project.org> on behalf of Bubke 
> Marco <marco.bu...@theqtcompany.com>
> Sent: Wednesday, January 20, 2016 11:48
> To: Development@qt-project.org
> Subject: [Development] What kind of airplane we want to build?
>
> Hello
>
> After the exciting discussions in the last time with all the energy spend on 
> them I want to try to make a short summary.  Maybe we can transform the heat 
> on some steam to progress further. ;-)
>
> I think many feel that C++ is rapidly changing. With C++ 17 on the horizon 
> there is some excitement but also fear that Qt will not stay relevant if we 
> not adapt. But there are arguments too about existing users who would be left 
> in the cold we we change to much.
>
> So let use an airplane as metaphor. We built a fine piston engine airplane on 
> that little bit cumbersome piston engine called C++. But now we see Jet 
> engines coming up but all our technology is built the old piston engine 
> technology so the adaption of jet engines is not that cheap. The jet engines 
> are different but we are not sure about their advantages but we are sure it 
> would be a big investment to change to them. So people propose different 
> designs. Some say we should minimize investments and only apapt slowly other 
> proposed to build a hyper mach airplane.
>
> The metaphor is not perfect but I hope it is productive enough.
>
> I think the big elephant is the massive move of the processing technology to 
> multi cores,  massive multi cores formerly known as GPUs and the new parallel 
> mechanism which are proposed to utilize them. Resumable functions, ranges, 
> parallel stl and how they all are called. This will change how C++ looks but 
> how can we change Qt in that picture to utilize this new technologies.
>
> I think it would be productive for the discussion to build story of what we 
> want to do. A story of the big picture. Maybe as a first step we can show how 
> we tackle problems with Qt 5 and what are the proposed technologies in the 
> future C++ standard.
>
> Maybe

Re: [Development] What kind of airplane we want to build?

[Bubke Marco]

On January 21, 2016 1:28:58 AM Marc Mutz  wrote:

> On Wednesday 20 January 2016 21:52:49 Thiago Macieira wrote:
>> On Wednesday 20 January 2016 21:08:07 Pau Garcia i Quiles wrote:
>> > Replacing QThread with std::thread? Please don't.
>> 
>> Unlike the containers or even futures/promises vs QtConcurrent, we can
>> easily  argue that QThread provides a lot more functionality than
>> std::thread. In just one word: signals.
>
> What happened to "you're doing it wrong!"? :) AFAIU that blog post, you're 
> supposed to use the signals of QObjects living in that thread, not the 
> QThread 
> itself.
>
> And that's perfectly possible with std::thread, too:
>
>  auto po = new ProcessingObject();
>  connect(po, ...);
>  po->moveToThread(nullptr); // enable "pulling" moveToThread()
>  auto t = std::thread([po, gui = QThread::currentThread()]() {
>  QEventLoop loop;
>  po->moveToThread(QThread::currentThread());
>  connect(po, ..., , ::quit);
>  loop.exec();
>  po->moveToThread(gui);
>  // or: delete po;
>  }
>
> Am I missing something?

The question is if you really want an event loop here. Mostly I want a command 
queue where I can prioritize and merge the commands. I want to poll for cancel 
commands  without much overhead and it should support move only types.

I really think we should step back and look at the broader picture before we 
apply our tools. 

>> We should provide QThread::makeThread() taking a lambda and some other 
>> niceties, though.
>
> -- 
> 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

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bubke Marco]

On January 21, 2016 3:51:09 PM Bo Thorsen  wrote:

> Den 21-01-2016 kl. 14:15 skrev Milian Wolff:
>> On Donnerstag, 21. Januar 2016 05:44:05 CET Kevin Kofler wrote:
>>> I consider reserve() to be a technical detail and a micro-optimization I
>>> really should not have to bother with in 99+% of the cases.
>
> That's how it should be.
>
>> This is very wrong. In my experience with profiling applications, the most
>> hotspots can be fixed by adding reserve to loops where the size is known or
>> can be guessed. This has a tremendous effect on runtime speed, also for
>> QVector using realloc
>
> And this is how it is.
>

make my_work_as_I_am_going_home

I tried it in camel case but that was not working. :-p

> Bo Thorsen,
> Director, Viking Software.
>
> -- 
> Viking Software
> Qt and C++ developers for hire
> http://www.vikingsoft.eu
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Bubke Marco]

On January 20, 2016 21:08:50 Pau Garcia i Quiles  wrote:

> On Wed, Jan 20, 2016 at 3:25 PM, Bo Thorsen 
> > wrote:
>
>
> Why do you think people hate C++? I love C++ but I hate the string classes. I 
> like some part of the std containers, I don't like their API.
>

I really think professional developers are not driven by their emotions but by 
reason and arguments. I think as a productive developer you should always train 
your ability to get in a new context. 

>
> Spot on.
>
> People run scared from Boost-like C++. That kind of code is very performant 
> but it's neither easy to write, understand or, in many cases, figure out.

Yes but with const expressions and concepts the code gets  readable again. 

> On the other hand, Qt is usually love at first sight. Makes C++ look doable. 
> Even easy. Sure, some people who have spent a lot of time writing C++ move on 
> from Qt and like Boost-like code the better but that kind of code, those 
> APIs, are to blame for the very bad opinion many people have on C++. They 
> hurt C++ jobs.

It really depends, not everything in boost its bad. The futures are nice. And 
the big problem are templates but concept should make templates easier to 
program. 

> Replacing QThread with std::thread? Please don't.

I think it is more a question of maintenance. I prefer std::tread because it is 
quite simple. 

>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] What kind of airplane we want to build?

[Bubke Marco]

Hello

After the exciting discussions in the last time with all the energy spend on 
them I want to try to make a short summary.  Maybe we can transform the heat on 
some steam to progress further. ;-)

I think many feel that C++ is rapidly changing. With C++ 17 on the horizon 
there is some excitement but also fear that Qt will not stay relevant if we not 
adapt. But there are arguments too about existing users who would be left in 
the cold we we change to much. 

So let use an airplane as metaphor. We built a fine piston engine airplane on 
that little bit cumbersome piston engine called C++. But now we see Jet engines 
coming up but all our technology is built the old piston engine technology so 
the adaption of jet engines is not that cheap. The jet engines are different 
but we are not sure about their advantages but we are sure it would be a big 
investment to change to them. So people propose different designs. Some say we 
should minimize investments and only apapt slowly other proposed to build a 
hyper mach airplane. 

The metaphor is not perfect but I hope it is productive enough. 

I think the big elephant is the massive move of the processing technology to 
multi cores,  massive multi cores formerly known as GPUs and the new parallel 
mechanism which are proposed to utilize them. Resumable functions, ranges, 
parallel stl and how they all are called. This will change how C++ looks but 
how can we change Qt in that picture to utilize this new technologies. 

I think it would be productive for the discussion to build story of what we 
want to do. A story of the big picture. Maybe as a first step we can show how 
we tackle problems with Qt 5 and what are the proposed technologies in the 
future C++ standard. 

Maybewe see that we don't have to change so much.  Maybe we find out the change 
would be so massive that we cannot call it Qt 6 anymore. There are many maybes 
because the future is uncertain but we handled uncertainty in the past so why 
we should not do it in the future?

I really believe that before we make little changes like the containers etc. we 
have to find a story. A story how the future Qt should look, a story for the 
long run. In my opinion we have to build the story TOGETHER and this story 
should be build on actual experience and measured facts. We should be careful 
about emotions like doubt,  fear or excitement. I think we should be stay calm.

So we can try now this new C++ prototypes, find out how they fit with our 
technology like signal/slots,  CoW etc.. And later if they are getting momentum 
we can provide our magic sauce on top to make our users more productive. 

And if we want change Qt much we have to provide a technology to make the 
adaptation of our users easy and reliable. So the gain should be bigger than 
the cost. I think Clang based technologies provide us some possible tools but 
we have to find out. It is not only about providing the tool kit for new shine 
projects but for existing ones too. Some maybe they don't want to change and 
that is a respectable decision but for the user who want and need to adapt we 
should make it easy. 

I know this sounds like common sense but after all the discussions in last time 
I think we should step back and get a bigger picture before starting detailed 
discussions again. 

So lets go out,  start prototypes,  gain experience and come back to fruitful 
discussions.  ;-)

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bubke Marco]

On January 19, 2016 09:39:17 Knoll Lars  wrote:

> On 15/01/16 23:20, "Development on behalf of Thiago Macieira" 
>  
> wrote:
>
>>On Friday 15 January 2016 18:42:43 Marc Mutz wrote:
>>> And you will see it over and over again until enough people are fixing 
>>> premature pessimisations in existing Qt code. There's a notable increase 
>>> already. But it takes a long time to turn a supertanker around...
>>
>>Some of us call them "trade-offs". Every trade-off is a pessimisation 
>>somewhere for an optimisation somewhere else. Often, they're not measured in 
>>the same units or not quantifiable at all.
>>
>>API quality and consistency fall under those definitions.
>
> Exactly this. 
>
>>
>>> And no, I cannot believe that using the Qt containers leads to faster
>>> applications. It may lead to applications faster, but not to faster
>>> applications.
>>
>>Exactly. TTM is a significant factor and we all know Paretto's Law (80-20 
>>rule).
>
> And this. Let’s not forget to ask ourselves the question why many developers 
> use Qt in C++ development, often even in the case where they don’t need a UI. 
> For the past 20 years a lot of our focus has been on making development easy, 
> and creating APIs that serve that goal. This means that we are in many case 
> optimising for TTM more than for ultimate speed.
>
> I think we agree that std containers are in many cases faster than the Qt 
> containers. But they are harder to use and especially developers that come 
> from other languages often appreciate the ease of use of the Qt containers. 
>
> The main question IMO is how we can bring these two worlds closer together 
> for Qt 6 (or maybe even to some extent in Qt 5.x). 

I think we should start minimal and try to layer QVector over std::vector. If 
you want performance you use in many cases a vector. The second important item 
would be IMHO  benchmarks,  maybe we use google benchmark which has some nice 
threading feature. Without benchmarking discussions get IMHO easily non 
substantial. 

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

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bubke Marco]

On January 19, 2016 13:42:33 Olivier Goffart  wrote:

> On Dienstag, 19. Januar 2016 12:02:12 CET Knoll Lars wrote:
>> Things are not just black and white. But we can’t do a Qt6 that simply
>> removes all of them completely. We’d leave most of our users behind on Qt 5
>> forever. So we have to find better, and maybe more incremental, ways to
>> handle this. With a radical 'let’s throw them all away' approach we will
>> leave all our current users behind.
>
> Just an idea:
>
> We deprecate them, so all our api use std::vector and such.
> We add a qt5support library which contains classes like:
>
> template class QVector : public std::vector 
> {
>   QVector(std::vector); // implicit conversion from std::vector
>   /* All the Qt API  goes here */
> };
>
> I believe this should be mostly source compatible.

But it is a behavior change which are the worst of all. You get  no clear 
feedback what is wrong but your code is suddenly slow. We should have a version 
with CoW too. 


> This also assume we can use std in our ABI (which i think we should allow)
>
> Marc Mutz wrote:
>> > E.g. QVector seriously needs to support move-only types (like 
>> > unique_ptr) in a C++11 world. Oops... it never will... it's CoWed...
>
> Actually, it might be possible, using SFINAE, to disable the copy constructor 
> of QVector when the T is not copyable.  (and we also do not call detach for 
> such T since it cannot be copyed and therefore cannot be shared)
>
> -- 
> Olivier 
>
> Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bubke Marco]

Hi Matthew, 

Your whole point was relocation but my point was traversing. Relocation can be 
easily fixed by reserve but if traversing is slow it is much harder to remove 
the convenience structures. I don't say we should not provide them, I only say 
they should be on top. 

On January 18, 2016 18:48:07 Matthew Woehlke <mwoehlke.fl...@gmail.com> wrote:

> On 2016-01-16 07:06, Bubke Marco wrote:
>> On January 16, 2016 06:08:14 Kevin Kofler wrote:
>>> I suspect we would lose at least some optimizations from 
>>> Q_DECLARE_TYPEINFO.
>> 
>> std::is_trivially_copyable and other type traits are your friends.
>
> Not really. There is a huge difference between a relocatable type (many,
> if not most), and a trivially copyable type (a lot fewer). Operations
> such as growing the buffer can be vastly more expensive if the item type
> is not relocatable vs. if it is. However, C++ itself currently does not
> provide any support for relocation.

So how many people define there objects as relocatable? Anyway for large 
vectors I use always reserve which is a quite common optimization. For pattern 
were you are holding references in the vector you have to do it anyway. 

> I want to say e.g. std::string is relocatable, but it is certainly not
> trivially copyable. Now, imagine a std::vector where both
> the vector and strings are very large. When the vector needs to resize,
> it will have to do a deep copy of ever single item, allocating and
> freeing lots of memory in the process. Compare to QVector
> (assume Q_DECLARE_TYPEINFO declares std::string relocatable), which...
> will do a realloc(). Worst case, that's 1 alloc, 1 free, and 1 block
> copy... and 0 ctor/dtor calls.
>
> That's a *significant* difference.
>
> (Even using QString instead of std::string does not help much... the
> QVector still just does a realloc, while std::vector must perform 2*N
> atomic operations.)
>
> ...and then there's QList, which just does a realloc(), *always*.

So you optimized the container for growing with allocations. I don't think it 
is the most common case. Having cache misses in traversing the container can be 
much worse and is much harder to fix than a reserve. 

>
>> There are other pitfalls in the qt containers,  e.g.
>> 
>> if (container.contains(key)) 
>>auto value = container.value(key);
>> 
>> auto iterator = container.find(key);
>> if (iterator! = container.den()) 
>>   auto value = iterator.value();
>> 
>> The first looks nice but leads to two lookups. And I have seen it very 
>> often. 
>
> Probably because a) it's easier / clearer to read, b) it's MUCH easier
> to write, and c) most of the time the performance doesn't matter enough
> to justify the ugliness of the latter. Specifically, I know I have
> written code like that *in full knowledge* that it's inefficient, simply
> because I don't judge it sufficiently inefficient to justify the ugly
> and obtuse STL syntax.

I don't think it's is so obscure. In Qt we have many obscure patters too but 
you adapt to it. As I was coming from python I found Qt ugly but it changed 
with time. ;-)

> That said, the *correct* fix is:
>
>   auto value = container.maybe_at(key);
>   if (value)
> do_something(*value);
>
> (...using std::optional or similar)
>
> This is easy to read, easy to write, *and* efficient.

I would prefer ranges. I think the next big step is easy writable parallel 
algorithms and hand written code like that is in my opinion not that 
maintainable. But we will see. 

>> I understand the problem. But my problem is more that I have the
>> atomic pointer which can slow your code done unexpectedly.
>
> Compared to what? The pointer only kicks in during a copy or destroy. At
> the point of the copy, the question is if a deep copy is slower than an
> atomic operation. At the point of destruction, you are probably slow
> anyway, though if it's just a dereference, you have potentially saved a
> heap free.

What about begin? Sorry, why are many other moving away from CoW for small data 
structures? Do we know something what they are not knowing? Atomics with multi 
cores can slow down your code considerable so copying can be smarter in that 
case. 

>> If you provide data structures which are trivially copy able the
>> simply could be moved in memory for a vector which is quite fast.
>
> ...except not nearly so many data structures are trivially copyable as
> you would like to think. Many are *relocatable* (a concept that does not
> yet exist in C++ proper), but *not* trivially copyable.

Actually many of my demanding structures are trivially copyable.  ;-)

> Even move semantics are less efficient than relocation (usually not by
> much, but still by some).
&g

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bubke Marco]

On January 18, 2016 19:57:48 Matthew Woehlke <mwoehlke.fl...@gmail.com> wrote:

> On 2016-01-18 13:40, Bubke Marco wrote:
>>> On 2016-01-16 07:06, Bubke Marco wrote:
>>>> std::is_trivially_copyable and other type traits are your friends.
>>>
>>> Not really. There is a huge difference between a relocatable type (many,
>>> if not most), and a trivially copyable type (a lot fewer). Operations
>>> such as growing the buffer can be vastly more expensive if the item type
>>> is not relocatable vs. if it is. However, C++ itself currently does not
>>> provide any support for relocation.
>> 
>> So how many people define there objects as relocatable?
>
> Only Qt users. C++ proper doesn't have such a concept (yet) :'(.

I mean how many Qt users using that feature. ;-)

>> Anyway for large vectors I use always reserve which is a quite common 
>> optimization.
>
> This of course assumes that a) you know in advance how large your vector
> needs to be, and b) that it will actually be that large, or that the
> cost of possibly unused memory is low.

Unused memory for big chunkd is not that expensive in many cases because of 
overcommitment. 

> I'll still assert that C++ needs relocatability :-).

I believe that to. It would be nice if there would be a zero move constructor 
optimization too.  So if your move it sets you memory to zero so whole range 
would be simply memsetted. So you can simply copy that span and than memset the 
old area to zero. 

Building a structure which defaults to zero is not that hard in many cases. 

>>>   auto value = container.maybe_at(key);
>>>   if (value)
>>> do_something(*value);
>>>
>>> (...using std::optional or similar)
>>>
>>> This is easy to read, easy to write, *and* efficient.
>> 
>> I would prefer ranges.
>
> How do ranges solve the problem of doing something with an element iff
> it exists in the container?
>
>> I think the next big step is easy writable parallel algorithms and
>> hand written code like that is in my opinion not that maintainable.
>
> I'm not sure what you mean by "hand written code"? How *else* would you
> write something like the above?

I mean it is more functional. But for that cases you have to know the context. 

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

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bubke Marco]

On January 16, 2016 06:08:14 Kevin Kofler <kevin.kof...@chello.at> wrote:

> Bubke Marco wrote:
>> Actually this convince is hurting you if you need performance. I would
>> prefer the convenience on top of lower level api.
> [and at the end:]
>> It really depends what you want to do. I would prefer it we had a CoW
>> wrapper around std vector. Best of both worlds.
>
> The question is whether such a wrapper would be able to support all 
> functionality of the current QVector or whether it would run into some 
> limitations. I suspect we would lose at least some optimizations from 
> Q_DECLARE_TYPEINFO. There might also be some API that cannot be implemented, 
> or at least not efficiently. (This could be even worse for other containers 
> than QVector.) So, it sounds like a great idea in theory, but I wonder how 
> practical it is in practice. I guess I would have to see a practical 
> implementation to know for sure.

Is std::is_trivially_copyable amd other type traits are your friends. They make 
it still easier than the qt workaround. 
>
> What I know for sure is that my priority queue abstraction on top of 
> std::priority_queue can support only a very limited API, and it would be the 
> same if QQueue were to be implemented on top of std::queue: The current 
> QQueue publicly inherits the underlying QList. The STL API, instead, wraps 
> the underlying vector and only offers the queue primitives, a completely 
> different philosophy that leads to a much more limited API. Of course, this 
> could be worked around by wrapping std::vector directly (or maybe 
> std::dequeue), or by simply keeping QQueue implemented on top of QList and 
> only changing QList. But there might be other such API limitations in the 
> STL.

I would not change all types.  The hash implementations of the stl are not that 
day to my knowledge. I care about interfaces and there you want to use a vector 
in the most cases. Maybe a flat unordered map on top of vector would be nice. 

I would be discourage the use of QList and promote vector instead. I don't use 
the extras features of QList  so I think most people do but QList is can be 
very suboptimal if you use it with entries which are larger than a pointer. 

There are other pitfalls in the qt containers,  e.g.

if (container.contains(key)) 
   auto value = container.value(key);

auto iterator = container.find(key);
if (iterator! = container.den()) 
  auto value = iterator.value();

The first looks nice but leads to two lookups. And I have seen it very often. 


> And QList might not be implementable at all on top of the STL, at least not 
> the flexible way it is now (array of pointers, except when the type can be 
> put in the place of the pointer).
>
>> I prefer algorithms which are based on iterators to handwritten loops.
>> They are easier to parallise in the future too.
>
> Well, then I have good news for you:
> some_algorithm(myQVector.begin(), myQVector.end());
> is perfectly safe. If myQVector was shared, the begin() or end() call, 
> whichever is executed first, will detach, and then some_algorithm will 
> operate on a new deep copy of myQVector that nothing else can possibly have 
> seen yet. If myQVector was not shared to begin with, then it is of course 
> safe too and there is no detach in that case.
>
> The iterators are only problematic when you keep an iterator across an 
> assignment, such as:
> QVector::iterator evil = myQVector.begin();
> QVector broken = myQVector;
> *evil = 666;
> where "evil" will corrupt "broken".

I understand the problem. But my problem is more that I have the atomic pointer 
which can slow your code done unexpectedly. 

> IMHO, this is simply a user error and a case of "don't do that then". This 
> issue is explicitly warned about in the Qt documentation.

I buy your argument but documentation is not the solution. You put the burden 
on the programmer to understand that his value semantic is not quite a value 
semantic. Do you look in the documentation all the time before you use a 
function? ;-) Sometimes 'lets document it' is an excuse for a interface with 
unexpected behavior. :-)

> If you really need 
> a copy of myQVector at this place, then you can use this:
> QVector::iterator evil = myQVector.begin();
> QVector unbroken = myQVector;
> unbroken.data(); // force detach
> *evil = 666;
> and everything will magically work again.
>
>> Atomics on the other side can produce strange performance bugs with false
>> sharing. I don't believe they are the future in a many core environment
>> where you share cache lines very often.
>
> Well, we could in principle do CoW without atomics (Qt 3 did them that way), 
> but the drawback then is that we would lose thread-safety (which is of 
&g

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Bubke Marco]

On January 16, 2016 00:44:57 Kevin Kofler  wrote:

> Marc Mutz wrote:
>
>> On Friday 15 January 2016 03:58:12 Kevin Kofler wrote:
>>> So why not just add a QOptional that works the same as std::optional?
>> 
>> a) because we can't (we don't yet require the necessary language features)
>
> A QOptional that works with Qt's implicitly-shared data objects (such as 
> QStringList, which is what it is wanted for here) only really needs this:
> T data;
> bool present;
> (I guess that order will give the better memory layout than the opposite 
> order.) If present is false, you just put a default-constructed T into the 
> (ignored) data field, which will simply have a null d-pointer and thus cost 
> you almost no time to construct. I don't see what further language features 
> are needed for us.
>
>> b) because once introduced, people will add all kinds of Qt-specific stuff
>>   to it, making it impossible to replace it with std::optional down the
>>   road. And since it will be good enough for the low demands of Qt
>>   development, it will no longer see development and fall behind the state
>>   of the art.
>
> So what? Qt users are not forced to use it, and I'm sure several will, maybe 
> BECAUSE of the "all kinds of Qt-specific stuff" that people actually find 
> convenient.

Actually this convince is hurting you if you need performance. I would prefer 
the convenience on top of lower level api. 

>> 
>> Consider QVector: it has been Qt-ifed by both adding (technically) useless
>> duplicate Qt-ish API, CoW, and a Qt-specific type classification scheme
>> plus corresponding optimisations that make it very hard to argue for
>> std::vector use instead. The Qt community had two decades where they could
>> have influenced the direction std::vector would take so it could allow the
>> same optimisations that QVector has, but the time and energy was instead
>> put into re-writing the containers for every major release (yes, for Qt 5,
>> too, and Thiago's Qt 6 QVector again looks much different from the Qt 5
>> one).
>
> But the Qt-ish API and the CoW are exactly what makes the Qt containers NICE 
> to use, unlike the STL. I have found myself more than once using QtCore in a 
> project solely and explicitly for the container classes! They are what makes 
> C++ a nice-to-use language.

It makes also easy to shoot yourself in the foot. The Qt containers love to 
malloc. ;-)

I really prefer the the proposed ranges API. 

>> The CoW makes QVector slow and increase code size, leads to hidden
>> detaches that not even Qt experts regularly avoid in their daily work, and
>
> Well, I am well aware of the issue, and know to use e.g.:
> static_cast(vec).first()
> when needed. (I guess this is actually more efficient than the popular 
> .at(0) workaround. It is definitely not less efficient.) But normally I will 
> just always operate on const data structures (usually const references) when 
> I'm not writing to them, so I don't have to cast anything. (And of course, 
> when I'm writing to them, chances are the detach is exactly what I want or 
> need.)
>
>> doesn't even work properly because you can take iterators into a QVector
>> and, after copying the vector, change both copies through the iterator
>> into the first. That is a conscious trade-off because making the container
>> unsharable, as it must become once it hands out iterators, would make CoW
>> fail to take effect _all the time_. But it leads to careless copying of
>> QVectors that also doesn't really help with porting to std::vector.
>
> So don't use iterators into QVector, use indexes, it's a random-access 
> container. The non-const operator[] that you use then DOES detach when 
> needed. (And of course, for read-only iteration, foreach works great.)

> The only container type where I found iterators to be truly useful is maps 
> (QMap, QHash, etc.), where the iterator can give me both key and value at 
> once and saves me the key lookup.

I prefer algorithms which are based on iterators to handwritten loops. They are 
easier to parallise in the future too. 

>> All the while - and I don't believe I'm saying this - std::vector *blazes
>> the trail* with move semantics, emplace_back and stateful allocators
>> (making QVarLengthArray all but useless). Does QVector use move semantics?
>> No.
>
> Move semantics are mainly an ugly way to avoid copies if you don't have CoW. 
> With CoW data structures, all you save through move semantics is the 
> reference counting. And move semantics make it easy to shoot yourself in the 
> foot. (Either you leave behind an invitation for a use-after-free bug, or 
> you end up swapping instead of assigning, which is also a pessimization.)

In my opinion move semantics are about ownership. After using them for some 
time I really like them to manage resources. 

Atomics on the other side can produce strange performance bugs with false 
sharing. I don't believe they are the future in a many core environment 

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 25, 2015 13:24:43 Thiago Macieira  wrote:

> On Friday 25 December 2015 10:35:02 Marc Mutz wrote:
>> There are a lot of problems with the C declarator syntax (implicit
>> narrowing  conversions, hard-to-parse for humans, "most vexing parse",
>> non-uniformity), and auto and uniform init and template aliases are the
>> fixes. If you don't use them, then you're stuck in the C declarator syntax.
>> You need to use a radically different syntax to get the nicer rules.
>
> Except when they mean different things.
>
>   auto v1 = QVector{1, 2};
>   auto v2 = QVector(1, 2);
>

The second contructor looks misleading. ;-)

Actually I never used size in the constructor. And if you need something like 
that a factory function would would be much nicer. What I using today is 

function({1, 2, 3})
 for testing if the function expect an vector. And

auto values = createValues({{"one", 1}, {"two", 2} , {"three", 3});
If I use value classes. It makes test driven development much easier because I 
can change things easier. And the test code is more readable. 

or I use

Vector values;
values.reserve(4096);

To initialize a vector. 

auto values = reserve(Vector(),  4046); 
Could be nice too but that is C++ 17.

After using python for years C++ syntax looks still ugly to me but you get used 
to it.

So my advice is that you use it for some time and then judge. Taste is 
changing. ;-)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

Clazy is nice but it's under GPL so it's not possible to integrate it in the 
creator clang code model. But I think we need something like clazy for the 
clang code model too.


From: Development  on behalf of Giuseppe 
D'Angelo 
Sent: Tuesday, December 22, 2015 11:59 AM
To: development@qt-project.org
Subject: Re: [Development] RFC: more liberal 'auto' rules?

Il 22/12/2015 11:26, Ziller Eike ha scritto:
> So funny/unwanted behavior can occur both because one used the wrong explicit 
> type, and because one used auto instead of an explicit type.

These shortcomings of auto are recognized in the community, but yes,
they're real and dangerous. Clazy [1] already has a warning for the
danger of auto with QStringBuilder, I guess it can be extended to other
cases.

N4035 [2] proposes general purpose workarounds ("operator auto",
specializations to std::decay, etc.) to address these issues.

> [1] https://github.com/KDE/clazy/blob/master/README
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf

My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

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

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

I think in the end we will look if it is easier to implement something similar. 
It's a tradeoff. 


On December 22, 2015 13:06:42 Konstantin Tokarev <annu...@yandex.ru> wrote:

> 22.12.2015, 14:50, "Bubke Marco" <marco.bu...@theqtcompany.com>:
>> Clazy is nice but it's under GPL so it's not possible to integrate it in the 
>> creator clang code model. But I think we need something like clazy for the 
>> clang code model too.
>
> I see at least 2 options how to integrate clazy:
>
> 1. Include it as a separate GPL-only plugin, users of commercial edition will 
> be able to install it separately. If that's too cumbersome to separate this 
> checks from code model, guard them with ifdefs so Clang plugin could be 
> compiled as GPL or as LGPL

I don't think it is feasible but you must ask lawyers about that. 
>
> 2. Just use it as external tool and parse its output.

Sorry,  this is not how the code models works. It would be much easier to 
reimplement the functionality of clazy. 
>
>>
>> 
>> From: Development <development-boun...@qt-project.org> on behalf of Giuseppe 
>> D'Angelo <giuseppe.dang...@kdab.com>
>> Sent: Tuesday, December 22, 2015 11:59 AM
>> To: development@qt-project.org
>> Subject: Re: [Development] RFC: more liberal 'auto' rules?
>>
>> Il 22/12/2015 11:26, Ziller Eike ha scritto:
>>>  So funny/unwanted behavior can occur both because one used the wrong 
>>> explicit type, and because one used auto instead of an explicit type.
>>
>> These shortcomings of auto are recognized in the community, but yes,
>> they're real and dangerous. Clazy [1] already has a warning for the
>> danger of auto with QStringBuilder, I guess it can be extended to other
>> cases.
>>
>> N4035 [2] proposes general purpose workarounds ("operator auto",
>> specializations to std::decay, etc.) to address these issues.
>>
>>>  [1] https://github.com/KDE/clazy/blob/master/README
>>>  [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf
>>
>> My 2 c,
>> --
>> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
>> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
>> KDAB - The Qt Experts
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
> -- 
> Regards,
> Konstantin
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFF: nullptr rules

[Bubke Marco]

I think it less a technical issue. To me it looked very perlish 
to use zero to mark a defined invalid pointer but C++ is full of this expert 
language hacks. I think it is more a social issue because Qt can look to old 
fashion. 
New people who discover Qt maybe get the same feeling as I got in
nineties as I looked at Motif.

So I think the question should be how much harm is produced
by this policy? I don't see any except people have to change their
habits. 

From: Development  on behalf of Joerg 
Bornemann 
Sent: Thursday, December 10, 2015 3:02 PM
To: development@qt-project.org
Subject: Re: [Development] RFF: nullptr rules

On 10-Dec-15 14:36, Marc Mutz wrote:

> As for why we need to have rules for nullptr: It's a funny you should ask,
> because you're contributing to a project that mandates the placement of {}s in
> minute detail. It's unclear why there should be no guideline for 0 vs. nullptr
> if there is for for() vs. for ().
>
> The rationale, in both cases, of course, is: consistency.

The consequence of this argument is that we need a rule for every
language feature for consistency. Please, no.

I was arguing that the unconditional enforcement of nullptr is solving a
non-issue.


BR,

Joerg
___
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: more liberal 'auto' rules?

[Bubke Marco]

I would like to bring up the a case from creator:

const TextEditor::FontSettings  = 
TextEditor::TextEditorSettings::instance()->fontS
ettings();

I really prefer in that case 

const auto  = 
TextEditor::TextEditorSettings::instance()->fontSettings();




Should we recommend forward(universal) references in for loops (which are 
"const " for "const values"):

for (auto & : values)

or

for (const auto  : values)

to show the difference to

for (auto  : values)

From: Development  on behalf of Knoll Lars 

Sent: Wednesday, December 09, 2015 1:18 PM
To: Giuseppe D'Angelo
Cc: development@qt-project.org
Subject: Re: [Development] RFC: more liberal 'auto' rules?

On 09/12/15 11:19, "Giuseppe D'Angelo"  wrote:



>On Wed, Dec 9, 2015 at 11:16 AM, Knoll Lars  
>wrote:
>> And I’d say it’s about time to stop that particular sub-thread. It’s neither 
>> productive nor leading anywhere.

Just for the record here, I was only asking to stop the off topic part of the 
discussion (about python and who’s right there). Let’s focus on auto in c++ and 
how we want to use it.

>
>Is there a consensus otherwise about a more liberal use of auto in our
>source code?

I don’t think there is a full consensus. Let me try to summarise where we are, 
what I think we agree upon and then add my thoughts :)

As a primary goal, auto should be used wherever it increases readability of the 
code. I think we all agree here. The problem is that there’s dissent in what 
‘more readable code’ is in practice.

I think everybody also agrees one the use cases listed in 
https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now is 
what additional use cases do most of us agree to? And how to put that into 
rules, as a listing with 50 entries won’t help anybody.

While I don’t think we should go and implement aaa right now, I would probably 
be ok with a somewhat broader usage than the current coding conventions imply.

Marc presented some use cases. Going through those, I don’t think I heard any 
disagreement about using auto in template, so I think we can probably add that 
one to our guidelines.

For loop variables, I don’t think we should require ‘auto’. Using it can be the 
right thing to do in some cases, esp when using patterns like ‘for(auto item: 
items)’ , but when looping using integer indices, I still prefer ‘for (int 
i=...; cond; ++i)’.

Are these cases something we can agree upon?

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

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 5, 2015 12:08:51 Julien Blanc  wrote:

> Le vendredi 04 décembre 2015 à 18:10 -0500, Matthew Woehlke a écrit : 
>> On 2015-12-04 17:43, André Pönitz wrote:
>> > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
>> >> Which of these is easier to read? (More importantly, which is easier to
>> >> *verify* that it is correct?)
>> >>
>> >>   for (int i = 0; i < list.size(); ++i)
>> >> foo(list[i]);
> [snip] 
>> 
>> >>   for (auto i : qtIndexRange(list.size())
>> >> foo(list[i]);
>> > 
>> > In any case, this is an uncommon pattern, using some unknown qtIndexRange()
>> > function.
>> 
>> Really?
>> 
>>   (Python)
>>   for i in range(len(list))
>
> Am I the only one to think that this example is inherently broken ? I
> mean, why wouldn’t any sane person write :
>
> for(auto const& element : list)
> foo(element)
>
> or
> std::for_each(list.begin(), list.end(), foo);
>
> Because :
> - it’s shorter
> - it’s more readable
> - it works for non random-access-container types
> - bonus : range checking is not needed, so it should be more performant
> - bonus : it doesn’t resort to a temporary value, same remark

What if you want to iterate over two lists.

for token,  cursors in zip(tokens,  cursors):
   ... 

is quite handy. 

You can use std::transform for some cases but C++ is sometimes very far behind. 
To my understanding Ranges should provide a good solution for it but they hide 
the type for good reasons. 

>
> Now, getting back to what Marc proposed initially, because the debate
> has gone far away from his initial proposal :
>
>> - template code (esp., but not necessarily only, when the type name
>> would require the use of 'typename')
>
> This is the one i’m not at ease with. Template code tends to be
> difficult to read, partly *because* there’s no type information. For
> readability concerns, i would prefer a local typedef named by the
> concept. Yes, that makes it two lines instead of one, but i think that’s
> one case where hinting the reader with a well-chosen type name makes a
> lot of sense.

Most typedefs I have seen was about hiding pointer or container types like 
CursorPointer or Cursors. But is CursorPointer a unique pointer,  a shared 
pointer and which flavor is it. Cursors is the same because it could be 
std::vector or QList. Some would hide a dictionary behind this name. So the 
typedef can be misleading. In that case I prefer auto. 

std::shared cursorPointer = document.cursorAtPostion(46);

CursorPointer cursorPointer = document.cursorAtPostion(46);

auto cursorPointer = document.cursorAtPostion(46);

I prefer the last but we need good tooling to show the type. It would be nice 
to have much more information like size,  is it movable or copyable. It is not 
only the type and we can provide that information. 

>> - all loop variables (both index and iterators)
>>   the reason being that spelling out the name is usually wrong:
>>  size_t i = stdVector.size() // wrong, should be
>>  std::vector::size_type...
>>  also helps when porting from Qt containers to STL ones
>
> That looks perfectly fine for me. Index based loops should be avoided
> whenever it is possible, and for iterator based loops auto makes no harm
> (seriously, who wants to write
> std::vector::const_iterator instead of auto ?).
>
>> - all references to elements in a collection (same problem - way too
>> easy to misspell std::pair for std::pair...)
>
> Same thing.
>
> Regards,
>
> Julien
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 4, 2015 08:35:19 Randall O'Reilly  
wrote:

> This debate between the std:: lib and wider C++ community vs. the Qt 
> traditions seems never-ending :)  At the risk of perpetuating the inevitable 
> flame war, my perspective is well captured in this article:  
> http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/
>
> C++ is WAY too complex of a language, and other alternatives are rapidly 
> gaining users (particularly Python in the domain of scientific computing).  
> The STL and its sea of recursive templates has in particular been incredibly 
> daunting.  C++11 helps, but the complexity remains..
>
> Of course, there is no “right” answer in any of these language debates: only 
> different people optimizing different ends of many different fundamental 
> tradeoffs.
>
> C and C++ in general tend to attract people who favor optimization over 
> simplicity / usability of the language.  Marc is clearly in that camp, 
> advocating many ways of optimizing performance..  With all the new language 
> options, presumably those that stick with C++ are even more apt to be 
> obsessed with performance..
>
> But Qt is beloved by many (myself included) because it provides a *simple*, 
> elegant, well-designed, well-named API, that does a lot of stuff..  Not 
> because of its optimal performance or cutting-edge language features and 
> adherence to the C++ standard..

Hmm,  do you really believe we cannot improve? If you compare signal and slots 
with resumable functions it looks quite complicated for many use cases. Look 
how complicated our network API is. It could be much easier with resumable 
functions. I don't say signal slots should go away but should be used in places 
their they have still an advantage. 

Ranges are quite nice too. With Qt we made C++ of the nineties much nicer but 
now C++ is incorporating many advanced features for concurrency and other areas 
from C#,  Python and other interesting languages. The world is changing and we 
should adapt to this changing context. 

> I got “stuck” in C++ for historical reasons: it was the only viable option 
> for object-oriented programming in the 1990’s.  Sure, I care about 
> optimization for my critical inner loops.  But for everything else, I really 
> wish it was a lot simpler.  And again, I value Qt for making it so in the 
> GUI, which consumes a huge amount of my code, and has minimal performance 
> demands, because it is a GUI and the human in the loop is almost always the 
> rate limiting factor.  Of course we don’t want exponential slowdowns with 
> large numbers of Widgets etc, but I’ve never found that to be a problem in Qt.
>
> So anyway, this is just a vote to keep with the solid tradition of favoring 
> simplicity, clarity, usability, readability, etc, instead of just following 
> the std:: C++ crowd!  Without Qt, I would have to suck it up and rewrite 
> everything in Go or Python or something.. :)
>
> - Randy
>
>> On Dec 4, 2015, at 12:49 AM, Marc Mutz  wrote:
>> 
>> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote:
>>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
 That depends on how big the remainder is. I argue that we're relevant
 enough  that our own direction is big enough to be of relevance.
>>> 
>>> That didn't come out right. Rephrasing:
>>> 
>>> Qt has enough market share by itself that we can choose our own direction
>>> and still be relevant. We are allowed to disagree with what others do.
>> 
>> Yes, but only if we know *better*.
>> 
>> I very much doubt that more than very few people in Qt development have the 
>> knowledge to objectively overrule the accepted C++ authorities. I myself 
>> have 
>> seen over and over again that how I thought a feature should be used was 
>> blown 
>> to smithereens by members of the committee, usually rightfully so.
>> 
>> So the default should be to follow what the greater C++ community is doing, 
>> while *divergence* from that needs to be argued for.
>> 
>> Everything else is approaching hubris, imo.
>> 
>>> we don't use exceptions
>> 
>> ...and look at the sorry state of error handling in Qt - every class does it 
>> differently... It's ok not to use exceptions, but not having a consistent 
>> error 
>> handling strategy doesn't put us into a position to throw that stone.
>> 
>>> we don't use underscores
>> 
>> ... except we do (grep "qt_"). And there's *nothing* wrong with that!
>> 
>> 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
>
> ___
> Development mailing list
> Development@qt-project.org
> 

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 4, 2015 10:45:19 Blasche Alexander 
 wrote:

>> -Original Message-
>> From: Development [mailto:development-boun...@qt-project.org] On Behalf
>> Of Thiago Macieira
>> Sent: Friday, 4 December 2015 9:14
>> To: development@qt-project.org
>> Subject: Re: [Development] RFC: more liberal 'auto' rules?
>> 
>> On Friday 04 December 2015 08:49:14 Marc Mutz wrote:
>> > > Qt has enough market share by itself that we can choose our own direction
>> > > and still be relevant. We are allowed to disagree with what others do.
>> >
>> > Yes, but only if we know *better*.
>> >
>> > I very much doubt that more than very few people in Qt development have the
>> > knowledge to objectively overrule the accepted C++ authorities.
>> 
>> That's why we use the mailing list and discuss the issue. Our collective 
>> minds
>> together are quite powerful.
>
> First of all I'd like to point out that I agree with Thiago and Randall. In 
> fact, I added the auto policy to the Qt coding conventions.
>
> This policy has been in place for much longer in Qt Creator (and therefore 
> the Qt version  just an adoption). I had my fair share of arguing over what 
> is better or worse readability wise. At the end of the day it's subjective 
> which makes argumentation about right or wrong harder. For me the point is 
> that if I have to look up a function signature to figure out what type is 
> behind the return values auto type then that's bad. An always auto policy is 
> just asking for such situations. 

With the clang code model it is quite easy to provide that information. In my 
opinion it is better to give your functions and variables descriptive names so 
you don't need to look for the declaration. 

For Test Driven Development it is better to use auto if you must exchange types 
with mocks. So the interface(concepts) is important but not the type.

>> You're calling for "opt-in by default" approach, while I am calling for an
>> "opt-out by default" approach.
>
> +1
> --
> Alex
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 4, 2015 16:39:14 Curtis Mitch  wrote:

>> -Original Message-
>> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
>> Olivier Goffart
>> Sent: Friday, 4 December 2015 2:25 PM
>> To: development@qt-project.org
>> Subject: Re: [Development] RFC: more liberal 'auto' rules?
>> 
>> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
>> > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
>> > > And as an aside, since it has been mentioned in this thread: in
>> > > Python _all_ variables are 'auto'. All. Without exception. Are
>> > > Python programmers more intelligent? Or do they just tolerate more
>> > > pain? :)
>> >
>> > i'd suggest the latter.
>> > no, really. people use external static checkers because the language
>> > lacks the feature.
>> > the lack of static typing is a common feature of scripting languages
>> > and makes them convenient to a degree, but it is an utter nightmare
>> > for any "real" software development. i really wouldn't want to go there.
>> 
>> But auto is still staticaly typed.
>> 
>> 
>> When you have code like
>> 
>>foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));
>>
>> You don't see any type.
>> 
>> This code that use auto is not less readable. Even if you don't know
>> what's the type of bar without looking it up.
>> 
>>   auto *bar = foo->bar();
>>   bar->setFaz(m_factory->createFaz(bar->type()));
>> 
>
> Isn't this kind of a bad example, because there was no type declared/visible 
> in the first place?
>
> Anyway, if you're going to take the time to move the result of foo->bar() 
> onto its own line, why not just declare a type? What benefit does auto give 
> here?

We have a maximum length in the coding style.  So if you give your variables 
and functions descriptive names you cannot chain them so you needs variables 
inbetween. The type information is not that important in that case. Anyway we 
can provide the actual type for auto in creator. Like we will provide 
highlighting for output parameters. A good tool can provide all the 
informations so we don't need to overload the source code with that 
information. So we can make the intent of the code much more clear. 

> I really dislike hiding types behind a generic keyword.
>  
>> 
>> ___
>> 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
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 4, 2015 21:33:57 André Pönitz  wrote:

> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
>> > > You don't see any type.
>> > > 
>> > > This code that use auto is not less readable. Even if you don't know
>> > > what's the type of bar without looking it up.
>> > > 
>> > >   auto *bar = foo->bar();
>> > >   bar->setFaz(m_factory->createFaz(bar->type()));
>> > 
>> > Isn't this kind of a bad example, because there was no type 
>> > declared/visible
>> > in the first place?
>> 
>> Precisely my point!   
>> There is no type visible before and nobody complains.  So why should one 
>> suddenly complains there are no types in the second snippet
>
> Because they are different from a human reader's point of view.
>
> In the second snippet the scope of the 'bar' is larger than for an immediate
> use. This loses the context in which it is used, i.e. makes it harder to
> reason about whether the use is ok, and adds load on a human reader that
> needs to keep mental track of this 'untyped' item when reading the code until
> it goes out of scope in case there's another use of this item.
>
> Both alternatives help to reduce that load:
>
> - immediate consumption of the temporary makes it explicit that the item is
>   used exactly once and provides the consumer as additional context, helping
>   judging whether the use is ok,
>
> - using a separate line with a real type provides a stepping stone by
>   giving additional information about the intermediate item *to the
>   human reader*, helping him to split the task of verifying that
>   'the right thing is produced and consumed' into smaller subtasks.

For subtask you should write a new function with a descriptive name. Actually I 
don't buy they argument that explicit types improve readability so much as we 
allow long functions which do many subtasks. In python a never missed the types 
and python code in general is in my opinion much more readable. In my opinion 
is the culture and not so much the style guides. 

I think readable code is produced by programmers who care and not so much by 
style guides. It is easy to write unreadable code which complies to a style 
guide but much harder to write good readable code. And if I look at our code I 
must say I have seen much more readable code. So we have plenty space to 
improve. ;-)

I think we discuss the matter of types so much because we have not a good 
culture to give variables and functions descriptive names. And how to decompose 
larger functions in smaller thanks to describe the intention. It's not only Qt 
but C++ in general.

My argument for auto is quite simple that it is makes dependency  breaking 
easier which is very important for Test Driven Development. And if you have 
good tests you can refactore your code much easier because you know the 
probability to introduce new bugs by code changes is much lower. This 
refactorings leads to much better readable code. So my argument is that should 
be used if it leads to more readable code. Our style guide can only gives hints 
about it.  So developing rigid rules which stop the code to envolve in a more 
readable state is maybe not that smart.

In the end you have always trust in the developers that they cares about the 
readability of what they produce. 

So I would like to add the advise to use auto if it makes unit testing easier.

And with the clang code model we could add refactorings which change auto to 
the actual type too. But I  prefer to visulize it in a other way. We could 
provide some kind of overlay.

>> > I really dislike hiding types behind a generic keyword.
>> 
>> Because the type is redundent
>
> It might be redundant for the compiler, but it is not for human
> readers of the code.
>
>> and it's one reason less to make errors:
>> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
>> QByteArray 
>> is way to frequent. (and the compiler won't complain)
>
> ["QString instead of QByteArray" does not happen with proper
> QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
> replacement of explicit types by 'auto' doesn't produce identical results.]
>
>> It is also refactoring-proof.  Because you might want to change the name of
>> the type from "FazManager" to "FazHolder", and then you need to touch less
>> code in your refactoring
>
> Code is typically read more often than changed. Targeting at making
> specific refactorings easier is optimizing the wrong utility function.
>
> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 5, 2015 01:43:40 André Pönitz  wrote:

> On Fri, Dec 04, 2015 at 06:10:45PM -0500, Matthew Woehlke wrote:
>> On 2015-12-04 17:43, André Pönitz wrote:
>> > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
>> >> Which of these is easier to read? (More importantly, which is easier to
>> >> *verify* that it is correct?)
>> >>
>> >>   for (int i = 0; i < list.size(); ++i)
>> >> foo(list[i]);
>> > 
>> > Whether the access is correct depends on the type of list, which you don't
>> > disclose.
>> 
>> That's sort of *the point*. I can't tell if the above is correct or not.
>> If it used 'auto', I'd know.
>
> You don't know whether operator[] or .at() is the best way to access
> by index until you know the type of list. Once you know the type of
> list, you also know what the type of i should be. There's no point
> in being fuzzy about it unless there is a *significant* advantage
> to it (like using 'auto' for iterator types which are mostly line
> noise).
>
>> (And it's sort of implied that it *is* wrong. Because, y'know, I see
>> loops like the above quite often where, indeed, they do in fact use the
>> wrong type. Actually, QList/QVector are about the *only* times the above
>> is written correctly without using 'auto'. More often than not, a loop
>> like that written against a non-Qt container uses the wrong index type.)
>
> The context of this discussion is the development of Qt. Thank you for
> confirming that 'int' is the right thing to use.
>
>> > In any case, this loop follows a well-known pattern.
>> 
>> It also follows a really *bad* pattern. The count is reevaluated every
>> time (well, you hope the compiler will hoist it, but the code says that
>> it is). Using type deduction... well, sucks:
>> 
>>   for (auto i = decltype(list.size()){0}; i < list.size(); ++i)
>
> [
> If you care about size() re-evaluation:
>
> for (int i = 0, n = list.size(); i < n; ++i)
> ... 
> ]
>
>>   for (auto i : qtIndexRange(list.size())
>> >> foo(list[i]);
>> > 
>> > In any case, this is an uncommon pattern, using some unknown qtIndexRange()
>> > function.
>> 
>> Really?
>> 
>>   (Python)
>
> Please stay on topic. The topic was whether to be more 'liberal' with
> the use of auto in Qt, written mostly in C++, not Python.
>  
>> > 
>> > The extra level of parantheses makes it harder to parse for
>> > humans,introducing an aditional source of errors, which you nicely
>> > demonstrated by making the example non-compilable.
>> 
>> Bah. A decent IDE would have flagged that as soon as I stopped typing.
>
> You are basically assuming that there's no need for you to write sane
> code to start with because during your development work you have a
> decent IDE to help you out. This assumption is wrong, independent
> of the existence of such an IDE.
>
> Since the discussion here is about what to use in Qt, the whole Qt
> development workflow matters. A lot of Qt code reading happens on Gerrit
> without IDE features at hand. The context there usually just a few lines.
> The appropriateness of an expression 'list[x]' is impossible to judge
> on Gerrit after applying an 'Almost always auto' policy.

Oswald and I spoke about using the clang code model to provide the information 
to gerrit too. It should be not that hard.

But you have to import the code in the IDE anyway because of the missing 
context.  For non trivial change review the calling context is far to important 
to be ignored. A html code browser could change that but we don't have one in 
gerrit. 

> This argument is not restricted to 'auto'. In general, code patterns
> that rely completely on IDE support are not beneficial for Qt
> development.
>
>> [...]
>> >> Which is *really* more meaningful?
>> > 
>> > The first one.
>> 
>> Sorry, but I must strongly disagree.
>
> So we agree to disagree. This was a call for comments. We've now 
> established the fact that there's no consensus on this matter.
>
>> In fact, you are missing the whole point of 'auto'.
>
> I don't think so.
>
>> By using 'auto' correctly, it's possible to know that the
>> type *is correct*, even if you don't know what the type actually *is*.
>
> You are missing the fact that Qt development is not an IDE-only workflow
> and does in general not operate on complete translation unit. You also
> do not seem to believe that at least some humans need a bit more explicit
> context than compilers to efficiently read code.
>
> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

I think the discussion is getting in an antagonistic direction and we should 
get back to our normal agonistic way or maybe being cooperative. ;-)

I have seen big systems in dynamically languages like small talk or python and 
except that they were slower they look actually much more readable. So I think 
history have shown that type declaration is not the key to readable code. In my 
opinion it is the excuse to find good names. ;-)

And what we should not forget is that tools getting better. So old rules can 
getting unproductive in a changing context. In my opinion we have to adapt to a 
changing context all the time and old wisdom can  loose it's usefulness fast.

So what about reviewing our style guides from time to time.  With tools like 
clang format and clang tidy it should be not that hard to adapt code to a 
changed style guide. 

On December 5, 2015 00:11:14 Matthew Woehlke  wrote:

> On 2015-12-04 17:43, André Pönitz wrote:
>> On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
>>> Which of these is easier to read? (More importantly, which is easier to
>>> *verify* that it is correct?)
>>>
>>>   for (int i = 0; i < list.size(); ++i)
>>> foo(list[i]);
>> 
>> Whether the access is correct depends on the type of list, which you don't
>> disclose.
>
> That's sort of *the point*. I can't tell if the above is correct or not.
> If it used 'auto', I'd know.
>
> (And it's sort of implied that it *is* wrong. Because, y'know, I see
> loops like the above quite often where, indeed, they do in fact use the
> wrong type. Actually, QList/QVector are about the *only* times the above
> is written correctly without using 'auto'. More often than not, a loop
> like that written against a non-Qt container uses the wrong index type.)
>
>> In any case, this loop follows a well-known pattern.
>
> It also follows a really *bad* pattern. The count is reevaluated every
> time (well, you hope the compiler will hoist it, but the code says that
> it is). Using type deduction... well, sucks:
>
>   for (auto i = decltype(list.size()){0}; i < list.size(); ++i)
>
>>>   for (auto i : qtIndexRange(list.size())
>>> foo(list[i]);
>> 
>> In any case, this is an uncommon pattern, using some unknown qtIndexRange()
>> function.
>
> Really?
>
>   (Python)
>   for i in range(len(list))

for index,  value in enumerate(iteratable):
print(index,  value) 

would be much better because index accesses are quite slow. But it shows nicely 
why types can reduce readability. 

for (auto {index,  value} : enumerate(iteratable)) 

Is so far I understand the new syntax in C++. Actually I  want to use that 
because it makes code much more readable. 

Think about 

auto {value ,  isConvertable}  = variant.toDouble();

In that case auto would enforce the test much more and the code is very 
readable too. 

> Just because it isn't standardized (or in Qt) yet doesn't mean it's
> "unheard of". It's just that C++ users have been suffering with the
> difficult to use form while programmers in other languages have had the
> much more sensible form for a long time.
>
> Really, it's not hard... nasty glorified while loop vs. 'I want to
> iterate over the indices [starting at zero] up to list.size()'.
>
> There's a reason I strongly prefer the latter form and use it whenever I
> can (usually subject to compiler compatibility limitations).
>
>> Moreover it is more to type.
>
> Really?
>
>   for (auto i : qtInlist.si))
>  - vs. -
>   for (int i = 0; i < list.si; ++i)
>
> Hey, look... mine's *fewer* keystrokes. And much more importantly, it's
> *correct*. Yours... may or may not be... as you pointed out, I don't
> know without knowing decltype(list). (Or I could use the much longer,
> *much* uglier old-style for loop with decltype that is correct, but then
> mine wins hands-down.)
>
>> The extra level of parantheses makes it harder to parse for
>> humans,introducing an aditional source of errors, which you nicely
>> demonstrated by making the example non-compilable.
>
> Bah. A decent IDE would have flagged that as soon as I stopped typing.
> (Actually, a decent *text editor* would have shown me () matches, so I
> would have noticed *as* I was typing. I challenge you to write bug-free
> code the first time in a text editor whose most advanced feature is cut
> and paste.)
>
>>> Which is *really* more meaningful?
>> 
>> The first one.
>
> Sorry, but I must strongly disagree.
>
>>> "The type of 'i' is 'int', and I
>>> really, really hope that 'list' is actually indexed by 'int'", or "the
>>> type of 'i' is the index type of 'list'¹"?
>>>
>>> Do you really *care* what is the type of 'i'?
>> 
>> Yes, I do care about types, almost always.
>
> Why? As long as it's the *correct* type, what difference did it make?
>
> Let's say that the correct type is my_list::index_t. Let's say I used that:
>
>   for (my_list::index_t i = 0; i < list.size(); ++i)
>
> How is that better? Do you know now what is the actual type of 'i'?

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 4, 2015 17:49:08 Thiago Macieira <thiago.macie...@intel.com> wrote:

> On Friday 04 December 2015 16:20:44 Bubke Marco wrote:
>> The clang code model completes auto so it should be not that hard.  Actually
>> I would call an ordered map or unordered map a dictionary. 
>
> Does Creator have a way to reveal the deduced type of an auto? That would go 
> a 
> long way to alleviating the pain of using it.

In the clang code model we use the clang AST. So if the compiler knows it, we 
can show it. It's on the roadmap for 3.7.

> -- 
> 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
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 3, 2015 19:06:17 Thiago Macieira  wrote:

> On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
>> The remainder of the C++ world is moving towards an "always auto" scheme. We
>> don't need to go there, but I'd at least like to propose, for new code and
>> as a drive-by, the *required* use of auto for:
>
> The remainder of the C++ world is no indication for us.

Actually I think it is. If Qt is to different we loosing mind share. 

> Also remember that, for us, the source code is a product. We need to have 
> readable source code, so we have two ground rules that must be respected:
>
>  1) the use of auto must make the code more readable, not less
>  2) Qt Creator must be able to parse and deduce the correct type

They Clang code model is doing it already and we working hard on building up a 
infrastructure on țop of clang to exchange the old code model with the new 
clang version completely. 

> #2 is, of course, a transient issue, because Creator will get better over 
> time.
>
> As for #1, it's subjective. "More readable" does not mean "fewer characters". 
> If someone reading the code cannot understand what that variable is doing, 
> then it's less readable. Thankfully, Qt API is well designed so you can 
> usually tell from the function name what it does, without having to know the 
> class it is defined in. But it follows that if you're interfacing with non-Qt 
> API, then their API may be worse and this less readable. For example, the 
> "is" 
> prefix for boolean properties helps a lot, since you won't have to decide 
> whether a plain word in English is a state or a an action, as in "empty".
>
>> - template code (esp., but not necessarily only, when the type name would
>>   require the use of 'typename')
>
> Agreed, except when in violation of the ground rules.
>
>> - all loop variables (both index and iterators)
>
> Except for primitives, because "int" is shorter than "auto".
>
>>   the reason being that spelling out the name is usually wrong:
>>   size_t i = stdVector.size() // wrong, should be std::vector::size_type...
>>   also helps when porting from Qt containers to STL ones
>
> I disagree. We'll use int, thank you. You know I disagree about porting from 
> Qt containers to Standard Library ones. Therefore, that is not an argument to 
> convince me to write uglier code with auto.
>
>> - all references to elements in a collection (same problem - way too easy to
>> misspell std::pair for std::pair...)
>
> Example?
>
>> Optional use of auto: whereever it makes sense. Use your own judgement, but
>> remember: fear is a bad advisor.
>> 
>> For range-for, I'd suggest the following patterns:
>> 
>> - loop variable: singular name of collection name (foo : foos)
>>   - otherwise: 'e' (for element) or first letter (r : rects)
>> - for (auto e : collection) // (for pass-by-value types, or if you modify)
>> - for (const auto  : collection) // for pass-by-reference types
>> - for (auto  : collection) // mutating (also: pointer variables/no auto
>> *) 
>
> Agreed.
>
>> - for (const auto *e : collection) // const pointers
>> - for (auto *e : collection) // non-const pointer
>
> Why? Why not allow "auto e" and e is a pointer?
>
>> - explicit type name should be the exception
>
> Agreed.
>
>> This is covering a large part of the usefulness of auto.
>> 
>> I don't really like to add anything more detailed to the "rules". Scott
>> Meyers' books do a much better job at explaining than we ever could.
>
> Qt has never and will never build without warnings from -Weffc++. Some of 
> Scott's rules are good, but we do not have to adopt them all.
>
> -- 
> 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
Sent from cellphone 
___
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 20, 2015 08:43:26 Thiago Macieira  wrote:

> On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote:
>> So if deep copies loose their ineffciency myth, what reason remains to not
>> use  QSV in all functions taking QString?
>
> Complicating the API.
>
> You cannot possibly prove that doing something O(n) is as efficient as doing 
> something O(1), therefore there's no way that deep copies would be a myth.

We both know that depends on the size. The minimal size of what the CPU gets 
from the memory is a cache line. The size of a cache line today is typically 64 
bytes. So as a minimum you always push that much data around. So if you use a 
atomic pointer on more than one cpu this cache lines has to be copied all the 
time. If you change something everything which depends on it has to be wait or 
recompute. So if  you accidentally have data on the some cache line it is  
shared too. This is not very intuitive. Your application can be much slower 
because you accidentally share data. 

Okay that is simplified but we get the picture. And the worst part is that 
memory is so much slower in relation to cache access as it was for the 
difference between memory and hard disks in the paste.  Today the difference 
between caches and memories resemble more that I learned about databases 20 
years ago. And there you learned to be careful about the complexity notations 
which doesn't reason about different memory speeds. 

COW with strings can lead to more coping than simply coping the string because 
most strings are small. Sharing writeable cache lines between different cpu is 
asking for trouble but I  think you know Amdahl's law 
https://en.wikipedia.org/wiki/Amdahl%27s_law. 

So why we don't measure it? Lets compile some applications with different 
implementation. Not simple ones. Maybe qtcreator would be a good idea. 

> COW may have comparable performance to deep copies if you consider the whole 
> picture and code written properly. Our code was written for COW, so I doubt 
> that you would get the same performance by suddenly making deep copies.
>
> To summarise:
>
> 1) I'm ok with adding QStringView
> 2) I'm ok with using QStringView in applications, no restraints
> 3) I'm ok with exploring the use in API, in parameters
> 4) I'm ok with exploring it in return values, in very limited conditions that 
> are being studied very well, ahead of time
>
> Exploring does not mean you can go and start adding overloads everywhere.

I think that's a very good approach. 

> -- 
> 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
Sent from cellphone 
___
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 20, 2015 10:10:36 Knoll Lars <lars.kn...@theqtcompany.com> wrote:

> On 20/10/15 09:59, "Bubke Marco" <marco.bu...@theqtcompany.com> wrote:
>
>>On October 20, 2015 08:43:26 Thiago Macieira <thiago.macie...@intel.com>
>>wrote:
>>
>>> On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote:
>>>> So if deep copies loose their ineffciency myth, what reason remains to
>>>>not
>>>> use  QSV in all functions taking QString?
>>>
>>> Complicating the API.
>>>
>>> You cannot possibly prove that doing something O(n) is as efficient as
>>>doing 
>>> something O(1), therefore there's no way that deep copies would be a
>>>myth.
>>
>>We both know that depends on the size. The minimal size of what the CPU
>>gets from the memory is a cache line. The size of a cache line today is
>>typically 64 bytes. So as a minimum you always push that much data
>>around. So if you use a atomic pointer on more than one cpu this cache
>>lines has to be copied all the time. If you change something everything
>>which depends on it has to be wait or recompute. So if  you accidentally
>>have data on the some cache line it is  shared too. This is not very
>>intuitive. Your application can be much slower because you accidentally
>>share data. 
>>
>>Okay that is simplified but we get the picture. And the worst part is
>>that memory is so much slower in relation to cache access as it was for
>>the difference between memory and hard disks in the paste.  Today the
>>difference between caches and memories resemble more that I learned about
>>databases 20 years ago. And there you learned to be careful about the
>>complexity notations which doesn't reason about different memory speeds.
>>
>>COW with strings can lead to more coping than simply coping the string
>>because most strings are small. Sharing writeable cache lines between
>>different cpu is asking for trouble but I  think you know Amdahl's law
>>https://en.wikipedia.org/wiki/Amdahl%27s_law.
>>
>>So why we don't measure it? Lets compile some applications with different
>>implementation. Not simple ones. Maybe qtcreator would be a good idea.
>
> Experimenting with that is probably a good idea, but we certainly can’t
> change away from COW any time soon. Maybe not ever because of
> compatibility concerns.

We should be careful not to get the new motif too. ;-) I think we have to find 
a middle ground again and again. It's  a question of how much pain our actions 
are producing and how much our inactions.  ;-) 

>> 
>>
>>> COW may have comparable performance to deep copies if you consider the
>>>whole 
>>> picture and code written properly. Our code was written for COW, so I
>>>doubt 
>>> that you would get the same performance by suddenly making deep copies.
>>>
>>> To summarise:
>>>
>>> 1) I'm ok with adding QStringView
>>> 2) I'm ok with using QStringView in applications, no restraints
>>> 3) I'm ok with exploring the use in API, in parameters
>>> 4) I'm ok with exploring it in return values, in very limited
>>>conditions that 
>>> are being studied very well, ahead of time
>>>
>>> Exploring does not mean you can go and start adding overloads
>>>everywhere.
>>
>>I think that's a very good approach.
>
> +1.
>
> Cheers,
> Lars
Sent from cellphone 
___
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 19, 2015 21:38:51 Thiago Macieira  wrote:

> On Monday 19 October 2015 18:38:52 Smith Martin wrote:
>> >Again, please try writing this method:
>> Doesn't that example just mean there are some classes that can't have a
>> QStringView API? A class should have a QStringView API if it can be used
>> safely.
>
> Right. I'm simply saying that "if it can be used safely" is very, very 
> restricted.
>
> Suppose you have in v1:
>
> class Foo
> {
>   QString m_data;
> public:
>   QStringView data() const;
> };
>
> Which looks fine and works without dangling references. Then in v2, you need 
> to 
> do this:
>
> class Foo
> {
>   QByteArray m_data;
> public:
>   QStringView data() const;
> };

How can you make a QStringView from a byte array? I know we abuse byte array as 
utf8 class but if you convert it you have no ownership of the created QString. 
Do you do a reinterpret cast? ;-) 

I see QStringView as const QString & but much more explicit and portable. So 
maybe you want to show that people can return a string view of a temporary? We 
can add a error in the clang code model so it should be a non issue. 

I think we should develop and use better tools which warn you about mistakes 
like that. That makes C++ much easier. ;-) 

Today I spoke with Ossi about the integration in gerrit too. So if you have 
enough firewalls we can be much more liberal in what we can use. 

For example the highlighting can show that the parameter is an in or in/out 
parameter so you don't need to use pointers anymore for in/out parameters etc. 
But it is getting off topic. 

> This API here simply cannot exist because the returned value would be a 
> dangling reference.
>
> Therefore, QStringView returns must be treated like references: only in 
> exceptional cases.
>
> -- 
> 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
Sent from cellphone 
___
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]

Hi Martin 

After watching https://youtu.be/H9gAaNRoon4 I got a much better picture of 
string view. I really recommend to watch it. My understanding is that 
qstringview would be a qt implementation of string view and the conversation 
cost would be zero. 

I find that very promising because it sould be very easy to use every string 
manipulation which is written for utf16 string view or qstringview with no cost 
and quite conveniently. So it really improves interoperability. :-) 

There are other advantages of string view.  For example instead to a pointer of 
characters and size in a function signature it could be better statically 
analyzed. 

I really think we should embrace it more openly. 

Sent from cellphone 
___
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]

Hi Marc

They thread mostly concentrated on performance but what about statical 
analysis? string_view and array_view are specifically designed for that. Maybe 
you mention it already but how is QStringView working for it. 

Sent from cellphone 
___
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 17, 2015 19:22:55 Thiago Macieira  wrote:

> On Saturday 17 October 2015 08:06:33 Marc Mutz wrote:
>> > The word 'fanboys' disturbs me (I know you don't mean it that way) because
>> > there are no 'hard' numbers on how 'bad' the current situation really is.
>> > It would really be 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".
>
> On the other hand, note how real world numbers show that QtGui and QtWidgets 
> consume a lot more CPU time than the combined time spent in malloc and 
> QString 
> operations.
>
> Last time I profiled Qt Creator startup and parsing of projects, the two most 
> expensive calls in QtCore were qHash and the SHA1 calculator. The former I've 
> already fixed. The latter I was hoping that some colleagues would fix by 
> creating an optimised library[1] we'd use but they refused to add SHA1 
> support 
> to it.

Thiago, we will be using clang as the new code model and in my experiences it 
is quite slow so we have to hide the latency. This is not only clang but same 
parsing of the results too where we heavily use a QByteArray wrapper. If I have 
time I will try out QValArray but it is not so urgent. I think QtCreator is an 
example that string operations matter because every latency as you type is 
quite unpleasant. 
___
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 17, 2015 21:05:29 Marc Mutz  wrote:

> On Saturday 17 October 2015 15:51:35 Smith Martin wrote:
>> >Please understand my POV: I am of the firm belief that Qt has no business
>> >creating inefficiencies for its users by sloppy implementation. Anywhere.
>> 
>> I think you are overreacting here, way too much. You have discovered a more
>> efficient way to handle strings, but that doesn't mean Trolltech created
>> inefficiency by a sloppy implementation of QString. QString has been used
>> productively by many users for a long time. The fact that a moere
>> efficient implementation exists doesn't mean the current implementation is
>> inefficient.
>
> I have not discovered anything. I merely use the existing tools and found 
> that 
> APIs outside the core Qt string classes largely ignore them, and probably 
> rightfully so, since there's a combinatorical explosion when you combine 
> QLatin1String, QString, QStringRef, QChar, const char*, QByteArray, etc.
>
> QStringView is not more efficient than any of those. It is an abstraction 
> over 
> them, so that you can use, say, QStringRef in more places.
>
>> >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().
>> 
>> But that is because we don't explain in the documentation the most
>> efficient ways to use these classes together. And the reason it isn't in
>> the documentation is we who write the documentation don't know what you
>> know.
>
> Then documenters should ask. There's a class QStringRef. If you/they don't 
> understand what the difference is to QString and why it exists, just ask.
>
>> >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.
>> 
>> But the fact is, it usually IS tolerable, because the applications you are
>> talking about mostly work in human time.
>
> Again, if it _were_ tolerable, we would all be using Java by now.
>
>> Your efforts to improve Qt are most appreciated, but you make it sound like
>> we should publicly name and shame all the engineers who ever worked on
>> QString but who failed to find the holy grail of the most efficient
>> implementation.
>
> Erm, no, that's not what I'm saying. I'm said we shouldn't use sloppy 
> implementation because people here claimed it was ok until proven otherwise. 
> I 
> merely pointed out (with many words) that that is not how C++ libraries are 
> supposed to work. You can profile an application and you can profile a 
> function. 
> You cannot profile a library.
>
> What TT created is magnificient. It greatly eased my learning of C++. But it 
> needs to evolve to stay relevant, because hardware doesn't stay the same.
>
> In the 2000s C++ was seen as a dying language by many. It is understandable 
> that TT picked concepts from Java, the then-favourite language. But now C++ 
> developers have gained back their self-esteem, because the industry has 
> realised that they absolutely _need_ the efficiency of C++. Java doesn't cut 
> it. 
> We no longer look up to Java and C#.
>
> When Qt was created, and for a long time afterwards, CoW was a good 
> optimisation. When multithreading came along, it ceased to be. That is now 
> universally understood, except in Qt where things are sometimes done because 
> they have been done that way since Qt 1 or 2. I try to shake thing up here 
> and 
> there, because I'm a C++ fanboy and want Qt to stay relevant.

Yes but you cannot change everything in one day. You are referencing to 
something like http://www.gotw.ca/publications/optimizations.htm? I still 
believe sharing mutable data between threads is not a good idea. In most cases 
you start to sterilize your threads. Working on the same cache line is not an 
good idea. I think coping or slicing data between different threads is much 
smarter. In that sense functional programming is much easier to program as you 
write your own loop. So I am not sure that our current CoW story is the answer. 
Not because it is inefficient but because it can lead to inefficient systems 
because it makes sharing so easy.

But before we add new concepts we should agree in which direction we want to 
go. I have the feeling that we build an airplan but some want a jumbo jet, some 
a jet fighter and some, lets describe it so,  they want to fly to the moon 
because earth will maybe burning down and build something completely different 
which doesn't looks like an airplane anymore which we built over many years. I 
don't think we will be succed before we find a common context. So it would be 
good to describe what is our story. 

>> I had no idea my heap was in such pain.
>
> Play around with heaptrack. And watch Milian's talks at QtWS once they become 
> available.
>
> Thanks,
> Marc

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

[Bubke Marco]

On October 17, 2015 15:52:08 Smith Martin  wrote:

>>Please understand my POV: I am of the firm belief that Qt has no business
>>creating inefficiencies for its users by sloppy implementation. Anywhere.
>
> I think you are overreacting here, way too much. You have discovered a more 
> efficient way to handle strings, but that doesn't mean Trolltech created 
> inefficiency by a sloppy implementation of QString. QString has been used 
> productively by many users for a long time. The fact that a moere efficient 
> implementation exists doesn't mean the current implementation is inefficient. 

QString makes heap allocation and has atomic pointers. I think it was designed 
for convenience and  not for maximum speed. That's okay because Qt is mostly a 
GUI and not text processing library.

>>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.
>
> But the fact is, it usually IS tolerable, because the applications you are 
> talking about mostly work in human time.
>
> Your efforts to improve Qt are most appreciated, but you make it sound like 
> we should publicly name and shame all the engineers who ever worked on 
> QString but who failed to find the holy grail of the most efficient 
> implementation.

Like I wrote they were very understandable design decisions. Anyway I think a 
professional developer knows that he should has distance to his code so that he 
get criticism about it not personal. Understanding criticism and argumentation 
as a process to write code is, I think, the key to get a good developer. So why 
they should be feel ashamed if something better comes up. This is called 
progress und it happens all the time.  I think I would be feel ashamed if I 
would fight other code because of personal reason. Sometimes I feel that way 
but I hopefully not stick to it. ;-) 

After reading some proposals about string view it has to my understanding this 
properties:
1. Makes string usage between different implementation more efficient 
2. Improve static analysis - makes ownership clear
3. Gives the different string implementation a common ground

You can use easily use a Qt function without creating a QString which can be a 
big advantage if performance matters.
___
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 <marc.m...@kdab.com> wrote:

> On Friday 16 October 2015 01:32:26 Bubke Marco wrote:
>> On October 16, 2015 00:20:22 Marc Mutz <marc.m...@kdab.com> 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

[Bubke Marco]

On October 15, 2015 08:45:30 Knoll Lars <lars.kn...@theqtcompany.com> wrote:

> On 14/10/15 23:51, "Bubke Marco" <marco.bu...@theqtcompany.com> wrote:
>
>>On October 14, 2015 23:10:26 Thiago Macieira <thiago.macie...@intel.com>
>>wrote:
>>
>>> On Wednesday 14 October 2015 20:52:12 Bubke Marco wrote:
>>>> On October 14, 2015 22:13:11 Thiago Macieira
>>>><thiago.macie...@intel.com>
>>> wrote:
>>>> And I don't want an utf 8 baked
>>>> QString. For my use cases implicit sharing is overkill.  Move semantics
>>>> would be enough. I want localAwareCompare(const char *s1, const char
>>>>*s2).
>>>
>>> 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?
>
> No, we wanted to do this at some point, but it turns out that it’s not
> possible to rely on it on all platforms.

Is there an other utf 8 backend on Windows? I heard that Microsoft is using it 
now on some plattforms too. 

>> 
>>
>>> Qt does not have to provide a comparator that operates on something
>>>other than 
>>> its native string type.
>>
>>Isn't Qt a framework to help developers? Sorry your argumentation is
>>sounds not very empirical.
>
> Of course our aim should be to help developers. But there will always be
> some use cases which we will not cover. The question is whether this is
> one of them or not.

Most file and network content is in utf 8, databases too. It has simply a size 
and performance advantage for most cases. You have not so many cases where you 
have pure Chinese signs in an text. Mostly it is an mixture. In Linux,  which 
is very important in embedded, utf 8 dominates ťhe APIs. Ask your self if we 
don't want support that. We could start simply and expand slowly. If the 
standard library would support utf 8 collations on all platforms very well we 
could skip it but today you have to do your own solutions again and again. 

>> 
>>
>>>
>>>> Maybe windows and mac os will bring support to the standard library so
>>>>we
>>>> don't need it but in the mean time it would be very helpful.
>>>> 
>>>> A utf 8 based QTextDocument would be maybe nice too.
>>>
>>> What for? It needs to keep a lot of extra structures, so the cost of
>>> conversion and extra memory is minimal. And besides, QTextDocument
>>>really 
>>> needs a seekable string, not UTF-8.
>>
>>Is UTF 16 seekable? You still have surrogates and you can merge merge
>>code points.
>
> For the most parts. When it comes to positioning cursors inside the text,
> you’ll always need to take care of complex text layouting, diacritics and
> (in the case of utf16) surrogates. Still, a lot of the seeking is probably
> easier with utf16 than with utf8.

Actually I would like to see measurements. Does anybody have seen anything 
about it. What is Chrome and Mozilla doing?

>> 
>>
>>Lets describe an example. I send the QTextDocument content to an library
>>which expect utf8 content and gives me back positions. This gets
>>interesting if you use non
>>ASCII signs. Actually the new clang code model works that way.
>
> We also have the opposite case, where we need to send utf16 to a 3rd party
> or system library, and get back positions. Unfortunately, not all APIs
> take the same encoding.

Yes, but in my experience C APIs are using UTF 8 or all UTF standards. There 
some older which use wchar but that is different anyway. It may be different 
for Java etc. but I don't think that people who use Qt use that much java APIs. 
 ;-) 

>> 
>>>
>>> Even if we provide UTF-8 support classes, those will not propagate to
>>>the GUI. 
>>> Forget it.
>>
>>What about compressing UTF 16 like python is doing it for UTF 32. If you
>>are only using ascii you set a flag and you can remove all that useless
>>zeros. It would be have implications for data() but maybe we should not
>>provide access to the internal representation. If you use UTF 32 as a
>>base you don't need anymore surrogates.
>
> That’s back to a mixed representation in QString. I personally think that
> combines the worst of both worlds.
>
I am not so sure eighter but I  like to have an open discussion about it with 
examples of other use cases. How other programs like mozilla,  chrome handling 
it, what does other languages support. Especially Internet centric solutions 
handle it would be interesting. 
___
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 15, 2015 14:53:29 Konstantin Ritt <ritt...@gmail.com> wrote:

> 2015-10-15 11:00 GMT+03:00 Bubke Marco 
> <marco.bu...@theqtcompany.com<mailto:marco.bu...@theqtcompany.com>>:
> On October 15, 2015 08:45:30 Knoll Lars 
> <lars.kn...@theqtcompany.com<mailto:lars.kn...@theqtcompany.com>> wrote:
>
>> On 14/10/15 23:51, "Bubke Marco" 
>> <marco.bu...@theqtcompany.com<mailto:marco.bu...@theqtcompany.com>> wrote:
>>
>>>On October 14, 2015 23:10:26 Thiago Macieira 
>>><thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>>
>>>wrote:
>>>> Qt does not have to provide a comparator that operates on something
>>>>other than
>>>> its native string type.
>>>
>>>Isn't Qt a framework to help developers? Sorry your argumentation is
>>>sounds not very empirical.
>>
>> Of course our aim should be to help developers. But there will always be
>> some use cases which we will not cover. The question is whether this is
>> one of them or not.
>
> Most file and network content is in utf 8, databases too. It has simply a 
> size and performance advantage for most cases. You have not so many cases 
> where you have pure Chinese signs in an text. Mostly it is an mixture. In 
> Linux,  which is very important in embedded, utf 8 dominates ?he APIs. Ask 
> your self if we don't want support that. We could start simply and expand 
> slowly. If the standard library would support utf 8 collations on all 
> platforms very well we could skip it but today you have to do your own 
> solutions again and again.
>
> For everything but US-ASCII / Latin-1, UTF-8 isn't faster than UTF-16 (feel 
> free to compare their complexity against UTF-32).

Do you have mesured it? Please no  theoretical discussions. If you have larger 
texts you have annotations in ascii like XML.

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

Okay,  again. Most text today is embedded in meta information and this 
information are very often ascii. Why do you think utf8 is used so widely?
___
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 15, 2015 15:56:35 Matthew Woehlke  wrote:

> On 2015-10-15 02:38, Ziller Eike wrote:
>> So from where does 's.indexOf(‘c’, i-2)' search?
>>
>> This is similar to integer overflow, and I think utilizing that in an
>> API leads to less readable and potentially unexpectedly behaving
>> code.
>
> It depends on the value of i, of course. And you're not going to get any
> better results with an unsigned offset.

You could get an assert or warning because you are out of range. 

>> Anyhow this seems to be only vaguely related to the things that are 
>> discussed in this thread.
>
> There was a question whether to use signed or unsigned as the size type,
> that somewhere turned into Qt's use of signed for string sizes/offsets
> being inconsistent with STL/CSL. I suppose it has wandered off a bit on
> a tangent, though.
>
 I would prefer we would be more in line with the standard library. All the 
casts to silence warnings are not very beautiful. 
___
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 00:20:22 Marc Mutz <marc.m...@kdab.com> 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 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. 

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? 

>
> On Thursday 15 October 2015 23:02:09 Bubke Marco wrote:
>> On October 15, 2015 00:27:45 Thiago Macieira <thiago.macie...@intel.com> 
> wrote:
>> > On Wednesday 14 October 2015 21:51:23 Bubke Marco wrote:
>> >> On October 14, 2015 23:10:26 Thiago Macieira <thiago.macie...@intel.com>
>> > 
>> > 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 Windows. On OS X there's no point since it's part
>> > of the system. On Linux, if you disable it, you're going to have some
>> > other features reduced, so don't disable it.
>> > 
>> >> > Qt does not have to provide a comparator that operates on something
>> >> > other than its native string type.
>> >> 
>> >> Isn't Qt a framework to help developers? Sorry your argumentation is
>> >> sounds not very empirical.
>> > 
>> > Yes, it is. But Qt's goal is not to support every single use-case and
>> > corner- case out there. Qt should make 90% easy and 9% possible. That
>> > means there's a 1% of the realm of possibilities that Qt does not
>> > address. If your use-case calls into this group, use the fact that Qt is
>> > native code and just call other libraries.
>> 
>> 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. 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 know binary compatibility is important for you but is it really
>> that important outside of the special linux distribution cocoon. 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.
>> 
>> > 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?
>> 
>> > Providing extra support for a character encoding that is not what QString
>> > uses falls in that 1%. Just use ICU.
>> 
>> You arguments sounds very tautological. Because it is unimportant we don't
>> have it a string class for it. It is unimportant because QString is not
>> supporting it.
>> 
>> I know you love plationian argumentation but it would be much more
>> effective if you would try to get in the context of other and understand
>> their arguments in their context.  Showing in your own context that their
>> arguments &quo

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

[Bubke Marco]

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

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 think the feature is to young to tell what "makes sense or not". We still 
have to find best practice. 
___
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]

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 we’re on, we won’t avoid some conversions.

With native do you mean the OS API's? There are many other API's which 
are preferring UTF-8 for performance and/or size reason like databases. 
Most text from the web is in UTF-8 because the overhead of Chinese signs 
is still lower than the savings for the embedded tags around them. 
I don't think we should orientate on the OS API's but more on the most 
performance 
demanding ones. So why do we not provide a QUtf8String and use it for 
example in networking. We don't need to change everything at once but
we should provide UTF-8 support so that our users do not have to invent 
the wheel again and again like we do in Creator.

___
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 14, 2015 22:13:11 Thiago Macieira <thiago.macie...@intel.com> 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
>> shor* in this cases It would be nice if your interface would support UTF-8
>> and not only UTF-16.
>
> Three of the four implementations of QString::localeAwareCompare operate on 
> UTF-16 (Win32 CompareStringW, CoreFoundation's CFStringCompare and ICU 
> ucol_strcoll). That's another reason for keeping QString as UTF-16.
>

Thiago, to my understanding ICU is supporting UTF 8 too. I don't ask for UTF 8 
support because I like it but I need it. And I don't want an utf 8 baked 
QString. For my use cases implicit sharing is overkill.  Move semantics would 
be enough. I want localAwareCompare(const char *s1, const char *s2). Maybe 
windows and mac os will bring support to the standard library so we don't need 
it but in the mean time it would be very helpful. 

A utf 8 based QTextDocument would be maybe nice too. 


___
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 14, 2015 23:10:26 Thiago Macieira <thiago.macie...@intel.com> wrote:

> On Wednesday 14 October 2015 20:52:12 Bubke Marco wrote:
>> On October 14, 2015 22:13:11 Thiago Macieira <thiago.macie...@intel.com> 
> wrote:
>> And I don't want an utf 8 baked
>> QString. For my use cases implicit sharing is overkill.  Move semantics
>> would be enough. I want localAwareCompare(const char *s1, const char *s2).
>
> 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? 

> Qt does not have to provide a comparator that operates on something other 
> than 
> its native string type.

Isn't Qt a framework to help developers? Sorry your argumentation is sounds not 
very empirical. 

>
>> Maybe windows and mac os will bring support to the standard library so we
>> don't need it but in the mean time it would be very helpful.
>> 
>> A utf 8 based QTextDocument would be maybe nice too.
>
> What for? It needs to keep a lot of extra structures, so the cost of 
> conversion and extra memory is minimal. And besides, QTextDocument really 
> needs a seekable string, not UTF-8.

Is UTF 16 seekable? You still have surrogates and you can merge merge code 
points. 

Lets describe an example. I send the QTextDocument content to an library which 
expect utf8 content and gives me back positions. This gets interesting if you 
use non 
ASCII signs. Actually the new clang code model works that way. 
>
> Even if we provide UTF-8 support classes, those will not propagate to the 
> GUI. 
> Forget it.

What about compressing UTF 16 like python is doing it for UTF 32. If you are 
only using ascii you set a flag and you can remove all that useless zeros. It 
would be have implications for data() but maybe we should not provide access to 
the internal representation. If you use UTF 32 as a base you don't need anymore 
surrogates. 
___
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]

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 QString. That is
> important when you need to interface with 3rd-party libraries.

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 only UTF-16.

Incorporating ideas of http://utfcpp.sourceforge.net/ could be useful.
___
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]

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 provide for 
performance reasons utf8 so we  should definitely support it. How do you want 
handle ownership. I think it should no be included in the type. What about move 
semantics. If the data is moved around it don't need to be copied before it can 
be manipulated. 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Bubke Marco]

Thiago Macieira thiago.macie...@intel.com
   Or like QString and QByteArray will be in Qt 6.
 
  Are these still implicitly shared?

 Yes, in large mode. In small string/array mode, they wouldn't share, of
 course.

What about the conversion of std::vector to QVector and back. Do we get zero 
copy conversion?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Bubke Marco]

Thiago Macieira thiago.macie...@intel.com
 On Tuesday 21 July 2015 16:14:18 Bubke Marco wrote:
  Thiago Macieira thiago.macie...@intel.com
 
 Or like QString and QByteArray will be in Qt 6.
   
Are these still implicitly shared?
  
   Yes, in large mode. In small string/array mode, they wouldn't share, of
   course.
 
  What about the conversion of std::vector to QVector and back. Do we get zero
  copy conversion?
 
 Can't be done.

What about wrapping QVector around std::vector. In that case std::vector could 
be
used in the internal implementation and application code. Interface would be 
still
using QVector. Many developers I met who rejected Qt cited the argument what Qt 
is a 
closed island and not very operable with code which is using the standard 
library.
What have made Qt productive 20 years ago is maybe not a good advice for the
future.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QVector now has rvalue push_back (was: Re: HEADS UP: potential trouble from a recent QVector change)

[Bubke Marco]

Gunnar Roth gunnar.r...@gmx.de
 
   void push_back(T t) {
   ensureCapacity(size() + 1);
   new (m_end) T(std::move(t));// move-construct from 
  t
   ++m_end;
 why is std::move needed here? Afaik std::move(t) converts t into a rvalue 
 ref, but t is already an r-value ref.

If T would be not a template t is binding to a rvalue reference but it is not 
itself a rvalue reference but an lvalue.
If T is a template like in this case it is more complicated because it is a 
universal or forward reference. For a 
forward reference it could be an lvalue reference like (T) or a lvalue(T) 
depending as the argument is a rvalue,
lvalue or lvalue reference. 
T - T
T - T
T - T

std::forward would be of better use than std::move: 
http://en.cppreference.com/w/cpp/utility/forward

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

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Bubke Marco]

From: development-bounces+marco.bubke=theqtcompany@qt-project.org 
development-bounces+marco.bubke=theqtcompany@qt-project.org on behalf of 
Kevin Kofler kevin.kof...@chello.at
 If you have large objects, and insert or remove items within the list,
 QVector will have to move (or even copydelete, if they're not movable)
 large amounts of data. Unless you use a QVectorT*, but that loses the
 value semantics in several places. And a QLinkedList is not an option if you
 also need O(1) (or anything faster than O(n), even) item retrieval. Pointer
 arrays have their advantages.

It depends if you care about the order of the container. If you don't and my 
experience you don't care in many cases you can simply use std::remove_if + 
erase 
and being very efficient.  
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans

[Bubke Marco]

Wrapping Qt container around standard container is quite a good idea to 
interact with other code. So Qt Container would be standard container + COW. 
One of the complains I hear very often is that Qt is an island and sadly in 
many cases I must agree. I think we should discuss the integration of the new 
library features too.

Cheers, Marco


From: development-bounces+marco.bubke=theqtcompany@qt-project.org 
development-bounces+marco.bubke=theqtcompany@qt-project.org on behalf of 
Cristian Adam cristian.a...@gmail.com
Sent: Thursday, June 25, 2015 1:18 PM
To: Knoll Lars
Cc: development@qt-project.org
Subject: Re: [Development] Qt LTS  C++11 plans

On Thu, Jun 25, 2015 at 1:04 PM, Knoll Lars 
lars.kn...@theqtcompany.commailto:lars.kn...@theqtcompany.com wrote:


Well, please tell me where this is such a big problem that we *have to
have* VS2013 when it comes to our APIs. For our implementation inside Qt,
we can work with slightly older compilers. It's not the end of the world
and our users wouldn't even notice.

Cheers,
Lars


There is always CopperSpicehttp://www.copperspice.com/ the Qt fork which uses 
C++11.

They've got rid of moc and plan to replace Qt containers with std ones. 
Afterwards maybe
they will add support for namespaces to their peppermill source convertor 
utility.

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

Re: [Development] QtCS: Notes from Modern C++ session

[Bubke Marco]

 -Original Message-
 From: development-bounces+kai.koehne=theqtcompany.com@qt-
 [..]
 Depends whether or not we make the choice to break the no stl in abi rule.

As I am looking at the advantages versus the the disadvantages in using the 
standard library I opting for using it. For example  converting the qt 
container to standard container and the other way around without a cost would 
quite good for interoperabilty. I hope not that Qt likes to be stay on their 
own island as the rest is moving on.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Utf8 local aware compare

[Bubke Marco]

Hi

Okay, first the context. I want to write locale aware compare collations for a 
local database which is saving the text in UTF-8. So converting the text always 
with QString::fromUtf8 is a little bit expensive. Under Unix strcoll would work 
but for windows there is no UTF-8 collation. One idea around that problem is to 
convert per character to UTF-16 and than compare it. Is there some internal API 
where I could do the conversion per character(not per byte)?

Anyway, best would be:

QCollatorhttp://qt-project.org/doc/qt-5/qcollator.html#QCollator::comparehttp://qt-project.org/doc/qt-5/qcollator.html#compare(const
 char *utf8String1, const char *utf8String2, size_t size1=-1, size_t size2=-1) 
const

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

Re: [Development] Utf8 local aware compare

[Bubke Marco]

What about  icu::Collator::compareUTF8() in ICU?

http://userguide.icu-project.org/strings/utf-8:
ICU has some APIs dedicated for UTF-8. They tend to have been added for 
worker functions like comparing strings, to avoid the string conversion 
overhead, rather than for builder functions like factory methods and 
attribute setters.

For example, icu::Collator::compareUTF8() compares two UTF-8 strings 
incrementally, without converting all of the two strings to UTF-16 if there is 
an early base letter difference.

My understanding is that if your UTF-8 charakters are precomposed you can do it.

From: Knoll Lars
Sent: Thursday, September 11, 2014 2:09 PM
To: Bubke Marco; development@qt-project.org
Subject: Re: [Development] Utf8 local aware compare

Hi Marco,

On 11/09/14 13:23, Bubke Marco marco.bu...@digia.com wrote:
Okay, first the context. I want to write locale aware compare collations
for a local database which is saving the text in UTF-8. So converting the
text always with QString::fromUtf8 is a little bit expensive. Under Unix
strcoll would work but for windows there
 is no UTF-8 collation. One idea around that problem is to convert per
character to UTF-16 and than compare it. Is there some internal API where
I could do the conversion per character(not per byte)?

There’s no real way to do this. Collation needs to work on whole strings,
and can’t compare byte by byte. And the platform APIs on Windows, Mac and
ICU are all utf16 based. So the API below wouldn’t help as we’d still have
to convert the string to utf16 before passing it into the platform APIs.

Lars



Anyway, best would be:

QCollator
http://qt-project.org/doc/qt-5/qcollator.html#QCollator::compare
http://qt-project.org/doc/qt-5/qcollator.html#compare(const char
*utf8String1, const char *utf8String2,
 size_t size1=-1, size_t size2=-1) const

Thank you, Marco





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

Re: [Development] Converting types in Qt

[Bubke Marco]

Hi

In the qml designer we are using comparisons of variants quite extensive and 
run in smaller problems like wrong conversions. E.g. color is broken because 
the alpha value is not used in the comparison. We would like to extent existing 
comparisons too because we get the variants from different sources, so the 
value is equal but because the conversion is not working it is not the 
same. Thomas Hartmann was running in more problems like that and if he is 
back in two weeks you should ask him.

Best, Marco

From: development-bounces+marco.bubke=digia@qt-project.org 
[development-bounces+marco.bubke=digia@qt-project.org] on behalf of Jędrzej 
Nowacki [jedrzej.nowa...@digia.com]
Sent: Tuesday, July 15, 2014 8:55 AM
To: development@qt-project.org
Subject: [Development] Converting types in Qt

Hi,

I would like to discuss type conversions in Qt. As you may know, Qt has
the ability to convert a known type to another known type. This works for
trivial cases like, for example, int to long, but also for more complex
ones like QByteArray to QString or CustomType to OtherCustomType. Type
conversion in Qt happens mostly without user interaction, for example in
QObject introspection or in QML, but it also can be used through public API:
  - QVariant::convert - converts wrapped value to target type
  - QVariant::canConvert - fast check if it may be possible to convert
wrapped type to a given target, which is, in my opinion, pretty useless,
unless the real conversion is really heavy
  - QMetaType::registerConverter - allows to register a custom converter
function for a user defined type
  - QMetaType::convert - perform conversion between two types

I would like to agree on some rules, regarding conversions, as the current
approach is chaotic:

  1. Are we allowed to add new conversions?

 The question is tricky because adding a new conversion is a behavior
change, as this code:
 if (variant.canConvert(QMetaType::int)) ...
 may work differently. If we add custom types into the mix, everything is
even more complex.

 1.1 Patch release or minor release only?

 I would say that new conversions may appear only in minor releases,
obvious fixes to existing conversions may appear in patch releases, where by
obvious I mean crash fixes and cases in which the returned value is definitely
bogus.

 1.2 Should conversion be perfect or based on a best effort?

 Some of the conversion API returns a bool value which is a status
of conversion. What should it return if a conversion is not perfect, for
example int(-1) - uint or QVariantList{string, int, myobject} -
QStringList, should such a case be detected? How do we define the perfect
conversion? Sometimes only ideal, data lossless, conversions should be
allowed, for example QtTestLib is quite strict about it and it allows only
safe conversions. So, for example, int - long but not uint - int, but I
guess for normal use cases such strictness is not necessary.
 I think we should base conversions on the best effort and set the
status to false only if a conversion failed completely, that is mainly if a
conversion is unknown or if underlying implementation detected a failure, like
QByteArray - float which uses QByteArray::toFloat(bool *ok)

 1.3 Should we try to support a user's type conversions out of the box?

 Currently a user needs to manually register a conversion function so
Qt can know it and use it. For certain types we can do much better, because we
can automatically convert some types. For example:
 QVectorchar - QLinkedListint
 QListFoo - QVectorFoo
 QPointerFoo - QObject*
 QPointerFoo - void*
 QSharedDataPointerFoo - bool
 MyQObject* - QPointerMyQObject
 Currently we are not doing it for one reason which is behavior
compatibility. What if a user already defined a conversion that we want to add?
It could happen because the conversion was not available in a previous Qt
version. The problem is that the new conversion function may behave in a
different way, especially in edge cases and because of the lack of perfection
mentioned in 1.2. We need to pick only one function. That could be the Qt
version, but then we risk that an existing code will not work anymore. Are we
willing to accept that?
 I believe that we should document the problem, and allow the
conversions.

 1.4 Should a user be able to add Qt types conversion on his own?

 Some conversions are missing, some we consider as not safe. A user,
assuming that he knows what he is doing, could register a conversion; for
example, QString - QChar, how bad is it? Currently, such usage is blocked,
because we are afraid that in the future we may add a conversion that
overrides it.
 In my opinion it is not needed; it is a corner case, because we a)
should have the conversion and then it will appear in a future version b) the
conversion is 

Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)

[Bubke Marco]

Actually the different the difference between qtdeclarative and qtbase is 
already producing enough overhead. For example bisect is hard to impossible 
which I need to do often to find out smart changes. 

What about to break the 1:1 relationship between CI modules and repositories. 
Why not have more than one CI module for qtbase? 

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

Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)

[Bubke Marco]

From: Knoll Lars
On 13/05/14 11:49, Bubke Marco marco.bu...@digia.com wrote:
Actually the different the difference between qtdeclarative and qtbase is
already producing enough overhead. For example bisect is hard to
impossible which I need to do often to find out smart changes.

I very much disagree. The changes and refactorings we did to declarative
over the last year would IMO have been a lot harder to do with a
monolithic repository.

I don't say that it is easier if you work in the modules. I do say that it is 
harder 
if you work outside. For example we use now in the designer Qml and the 
controls heavily and many bugs popping up. Normally I would use bisect
to find out the change but because it is so time consuming I simply ignore
them.

Bisecting qtdeclarative works usually well on the latest qtbase, and
bisecting qtbase can be done independent of qtdeclarative. It’s only in
the relatively rare case that a qtbase change caused a break in
declarative that this is an issue. I believe that’s worth the trade off.

You see from your perspective it is easier from my it is harder.

What about to break the 1:1 relationship between CI modules and
repositories. Why not have more than one CI module for qtbase?

How do you imagine that should that work in practice?

If you change a file in a module you get through that CI system. You should add
other CI modules if you think your change could triggering bugs there.

E.g. you change network code. Then the network CI should run, maybe the CI for
declarative-network and web-network too. So the CI modules should be smaller
so less unaffected code would be tested.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Bubke Marco]

Alan Alpert:
 That said, part of the path from becoming a trailblazer to being the
 dominant force ruling the world is IDE and tooling support. We want to
 improve tooling capabilities wherever we can do so (without
 compromising the 'untooled' developer experience - I know they

Hmm, again a hard code programmer who is writing his code in CLAY 
with his own fingertips. Sometimes he thinks about using this new tool 
Stick but that would be uncool. ;-)

 frequently clash, and the direct dev exp. takes precedence IMHO). This
 may require fresh new trailblazing tools, but that's just the nature
 of progress.

So we waiting that you writing this fresh new trailblazing tools! But maybe
you like more to stick with your fingers in CLAY. ;-)

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

Re: [Development] New JIRA type 'Feature'? (was RE: FW: Proposal for RFC like feature process)

[Bubke Marco]

From: Alan Alpert [4163654...@gmail.com]:
On Wed, Aug 14, 2013 at 12:03 AM, Koehne Kai kai.koe...@digia.com wrote:
 Alright, discussion about a new JIRA type 'Feature' went on at

 https://bugreports.qt-project.org/browse/QTJIRA-233

 with two different ideas:

 1) That we already have too many issue types in JIRA, and adding another one 
 makes things just worse, since the line between different types is blurry 
 anyway

 2) that a separate 'Feature' type that's can only be created by approvers, 
 and follows stricter standards, is a good thing to let roadmap / important 
 features stand out


 I personally think it's useful, but also think it only makes sense if the 
 type is really used by at least the majority of maintainers ...


 So, I'd like to ask specifically you, the maintainers: Would you use a 
 separate 'Feature' type? This is meant to describe things that typically 
 would show up on a roadmap  release blog, or that you'd want to discuss with 
 stakeholders ...

 Regards

 Kai


 -Original Message-
 From: Blasche Alexander
 Sent: Tuesday, August 13, 2013 1:32 PM
 To: Koehne Kai; Koehne Kai; Alan Alpert; Bubke Marco
 Cc: development@qt-project.org
 Subject: RE: [Development] FW: Proposal for RFC like feature process

 Creating an issue type is very easy. What's not easy is to commonly agree on
 what each type means and to consistently apply them. That's something
 where no admin can help as the community has to agree upon it.

 For what is is worth I am very much in favor of such a feature type.

 --
 Alex

 rant
 Unless a benevolent dictator comes around my experience tells me that
 there won't be an agreement any time soon(10 years of issue tracking inside
 Qt seem to have gotten the better of me).
 /rant


Alex's argument is entirely correct here (rant esp.). So I'm only in
favor of a new feature type if we can agree on the meaning and then
have a realistic expectation that we'll apply it consistently.

Specific questions I have about the feature type are

A) Do we have a clear distinction between Feature and Suggestion (also
Feature and Task)?

Yes, we had a discussion about it. It is like a RFC. So we have a way to 
describe a standard.


I would also not expect stakeholder discussions to be easier or more
fruitful if they could happen in JIRA instead. Which some possibly
should already have done, so my ability to consistently communicate
through JIRA may not be high enough to handle a new issue type ;) .

It is not about discussion only, it is about visibility. For example 
ApplicationWindow is a bad design for the Qml Designer. We only have seen it to 
late. There should be a way that we can argument before programmers start code 
a new feature.

For example we would like to have a guideline feature too but it is hard to get 
all people on board.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] AplicationWindow, QQuickWindow, contentRotation and setting width and height of contentItem

[Bubke Marco]

What about making ApplicationWindow a Item? We could skip the contentItem and 
there would be designer support.



From: development-bounces+marco.bubke=digia@qt-project.org 
[development-bounces+marco.bubke=digia@qt-project.org] on behalf of Tomasz 
Olszak [olszak.tom...@gmail.com]
Sent: Friday, August 02, 2013 8:49 PM
To: Alan Alpert; Bache-Wiig Jens
Cc: development
Subject: Re: [Development] AplicationWindow, QQuickWindow, contentRotation and 
setting width and height of contentItem

You should also be able to work around it inside your
ApplicationWindow by hiding the parent property on your content item.
Something like property Item parent: null should make it look like
the root of the tree. It's not great, but you actually want to pretend
to be the root of the tree (it's not just a ModalPopupBehavior hack).

Right it solves more issues, but modals are most common. Unfortunately i will 
not work. When I declared such property I got:
Cannot override FINAL property

The other workaround that comes to mind is to define your
ApplicationWindow in C++ by subclassing QQuickWindow.h and
implementing your own contentItem which does include the rotation
behavior.

I very would like to use ApplicationWindow from QtQuick.Controls module so I 
would rather not to do that.

Would either approach be sufficient for your needs?

Because of above, either ApplicationWindow will be moved to C++ or another 
solution will be found or idea of reusing ApplicationWindow dropped.
Didn't you consider such case that certain Item could be declared as quasi root 
of the tree?
Jens correct me if I am wrong but it can be necessary when support of 
ApplicationWindow styling will be added.

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

[Development] FW: Proposal for RFC like feature process

[Bubke Marco]

Hi

There are now many new feature proposals popping up on the mailing list. 
Sometime there is a link to a wiki page, JIRA etc.. You can easily get lost. 
The result are more hard designable (we working on the qml designer) features 
and Qml has more than enough already. So I propose something like the PEPs of 
Python: http://www.python.org/dev/peps/pep-0001/ It is working very well for 
them.

Lets call it Qt Enhancement Proposal(QEP).

In short you publish a  QEP on the wiki and add it to the QEP list so everybody 
can find it. There will be a discussion about it on the mailing list. The 
arguments will be compressed in the QEP and then there will be a decision. The 
QEP will stay so if somebody come up again he can be pointed to the QEP.

This worked very well for Python and so far I know most other languages(and 
many projects) have simular process.

Yes it sound like more work but I think in the end it is less.

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

Re: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders

[Bubke Marco]

Hi Gunnar


Gunnar Sletta:
The ApplicationWindow encapsulates a completely different concept compared to 
normal items and trying to treat them as the same in the design tool makes very 
little sense.

Is sense, logic not very context depend? I think our argument network, which is 
designer centric, is different from yours, which is run time centric. Like I 
have written ApplicationWindow is a hybrid of a window and a item but it is not 
a item in the sense of duck typing. It is different and that is hurting us. And 
for the menus you don't need a WYSIWYG editor.

The ApplicationWindow floats stand alone in the windowing system, it may have 
menu bar, status bar and toolbar, all of which require dedicated support from 
the designer to be designable. And the code generated does not go into a 
QQuickView, but needs to be created as via QQmlComponent::create() as it 
creates the window itself.

Actually what is the advantage to have the menu bar, status bar and toolbar 
designable? And we do not create the items from text because we need more 
control over them. I don't want to argument about that again and
again. ;-)

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

Re: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders

[Bubke Marco]

Alan Alpert:
The items-in-a-scene is an implementation detail (albeit one of the
biggest ones), but if you can provide a better implementation for the
existing APIs then that would be ideal. If not, we need to start
considering trade-offs instead, and maybe these other use-cases are
not as important as the application running with high performance
on-device. The initial usecases were not MDI, and were not even
multi-window. We aren't going to throw in extra abstraction layers for
a potential future. It's much better to maintain flexibility to be
able to add abstractions later on, even though abstractions are
easiest to implement at the start. One of the hopes for the QML-only
API of QtQuick is that we are only restricted by QML versioning
(separate from Qt versioning), and this gives us more flexibility.

If we implement it new I would opt for a approach where a item would have 
something like a property isApplicationWindow. This item would be than wrapped 
in a Window. I think MDI would be possible too with this approach.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders

[Bubke Marco]

Hi

We have some implicit design decisions in Qml/Quick/FxItems but there is not 
really a documentation for it
so changes are happen which are really hurting. Let give me a example:

Every graphical item should be derived from QQuickItem. So for graphical 
content in a Qml file there should be a item as root object. But now there is 
ApplicationWindow which looks a little bit like a bastard. It is actually a 
QuickView aka a Window with the special property contentItem. So we break a 
design decisions which is really hurting the qml designer. Thomas  has written 
some magic code after he has seen the wizard of Oz with his daughter but you 
know he hasn't still not seen all this Harry Potter movies so it is working 
somewhat but not very well. To get it working very well we had to rewrite our 
adaption code around the existing C++ interface of Qml. And how Alan stated it, 
it is not a clean interface. It would take much time and would generate new 
bugs. You see this is generating work. Work which would be not existing if we 
would had sticked to the design decision that every graphical item is a quick 
item.

So my proposal is to write all this informal decisions down in a wiki. If 
anybody wants to change that he should ask every stakeholder if it is ok etc..

Maybe something like the PEPs in Python.

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

Re: [Development] Toolability of mixing QML and JS

[Bubke Marco]

Rutledge Shawn:
On 26 Jun 2013, at 3:00 PM, Bubke Marco wrote:
 The approach with the different process has additional advantage that a crash 
 is not that bad, we can link with different Qt versions and can restart the 
 process because there was a problem which we call componentComplete lazy 
 programming.

Can you describe more of what goes wrong? I've run into problems with what 
componentComplete actually means several times too.
componentComplete is called only one time after the component creation. This is 
fine for the viewer because Qml is designed that its tree is only build one 
time. For the editor it's a big problem because we change this tree all the 
time.
We had the idee, that the signal at component creation time will compressed and 
executed at the end of the component
creation. So the performance use case for componentComplete would be gone.


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

Re: [Development] QML engine changes

[Bubke Marco]

Alan Alpert:
That is correct. I would argue that this design choice is also
correct, because text is the best common format for human editing.
Everyone will already have a fully feature text editor that they are
comfortable with, and then they can use all of the features
immediately. In contrast, building a specific tool requires that tool
to be built, then people to get it, learn it, and adapt to it. The
specific tool is better in the long run (for most usage) but we can't
wait for it to finish.
Like a said in a other mail Qml is not that much declarative anymore. Actually I
think it burned to many man years here in the tooling team that it was not 
worth it.
If you want help the designer than make Qml more declarative again.

Better yet, join the discussion if you're interested. As an open
project we do need to get better about having the design discussions
in the open, and joining those discussions from the tooling side is
encouraged. Then you aren't relying on other developers to be 'unsure'
about something.

Good to hear. So what is the plan for the PropertyCache?
What about a new better list interface(we have prototype here?
Maybe add signal compression instead of componentComplete.
Always think about that you need a reverse transformation for direct 
manipulation(visual to text).
Refactor the item code base.
  Why do we have parent and parentItem?
  Why do we mix the setParent and child list pattern?


This a short list of a much longer. ;-) I know many things are historical grown 
but if we not clean it up
we end in my opinion in a mess.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development