inted 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 QCor
On January 24, 2016 17:45:36 Kevin Kofler 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 alread
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 Ko
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
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 th
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
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 QtConc
On January 20, 2016 21:08:50 Pau Garcia i Quiles wrote:
> On Wed, Jan 20, 2016 at 3:25 PM, Bo Thorsen
> mailto:b...@vikingsoft.eu>> 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 rea
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 excite
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
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
On January 18, 2016 19:57:48 Matthew Woehlke 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 d
2016 18:48:07 Matthew Woehlke 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
On January 16, 2016 06:08:14 Kevin Kofler 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 woul
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 QOptio
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 i
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 wrote:
> 22.12.2015, 14:50, "Bubke Marco" :
>> Clazy is nice but it's under GPL so it's not possible to integrat
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, 2
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
ni
I would like to bring up the a case from creator:
const TextEditor::FontSettings &fontSettings =
TextEditor::TextEditorSettings::instance()->fontS
ettings();
I really prefer in that case
const auto &fontSettings =
TextEditor::TextEditorSettings::instance()->fontSettings();
Should we recom
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, wh
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
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
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.
>> > >
>>
[Screenshot 2015-12-04 13.55.13.png]
>
Please do a suggestion in jira for it. It sounds nice.
> On Fri, Dec 4, 2015 at 1:49 PM Thiago Macieira
> mailto:thiago.macie...@intel.com>> wrote:
>
> On Friday 04 December 2015 16:20:44 Bubke Marco wrote:
>> The clang code mod
On December 4, 2015 17:49:08 Thiago Macieira 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 hav
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 lib
On December 4, 2015 16:10:56 Rafael Roquetto wrote:
> On Fri, Dec 04, 2015 at 02:25:14PM +0100, Olivier Goffart wrote:
>> 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 menti
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.
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
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 *requ
On October 20, 2015 10:10:36 Knoll Lars wrote:
> On 20/10/15 09:59, "Bubke Marco" wrote:
>
>>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
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
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
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 so
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
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 helpfu
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
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
___
Devel
On October 16, 2015 07:07:56 Thiago Macieira wrote:
> On Thursday 15 October 2015 21:02:09 Bubke Marco wrote:
>> Actually I think Qt is not main developing library people use. It is there
>> to make the boring stuff easy, to hide the different interfaces between
>> differe
On October 16, 2015 08:53:33 Marc Mutz wrote:
> On Friday 16 October 2015 01:32:26 Bubke Marco wrote:
>> On October 16, 2015 00:20:22 Marc Mutz wrote:
>> > Guys, this thread is for QStringView. Could we keep it on-topic, please?
>> > There are more than enough bit
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
> wrote:
>> > On Wednesday 14 October 2015 21:51:23 Bubke Marco wrote:
>> >> On October 14, 2015 23:10:26
On October 15, 2015 00:27:45 Thiago Macieira wrote:
> On Wednesday 14 October 2015 21:51:23 Bubke Marco wrote:
>> On October 14, 2015 23:10:26 Thiago Macieira
> wrote:
>> > Do it on your own. You just said that ICU has the function you want, so
>> > use
>> &
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 othe
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
On October 15, 2015 14:53:29 Konstantin Ritt wrote:
> 2015-10-15 11:00 GMT+03:00 Bubke Marco
> mailto:marco.bu...@theqtcompany.com>>:
> On October 15, 2015 08:45:30 Knoll Lars
> mailto:lars.kn...@theqtcompany.com>> wrote:
>
>> On 14/10/15 23:51,
On October 15, 2015 08:45:30 Knoll Lars wrote:
> On 14/10/15 23:51, "Bubke Marco" wrote:
>
>>On October 14, 2015 23:10:26 Thiago Macieira
>>wrote:
>>
>>> On Wednesday 14 October 2015 20:52:12 Bubke Marco wrote:
>>>> On October 14, 2015 22
On October 14, 2015 23:10:26 Thiago Macieira wrote:
> On Wednesday 14 October 2015 20:52:12 Bubke Marco wrote:
>> On October 14, 2015 22:13:11 Thiago Macieira
> wrote:
>> And I don't want an utf 8 baked
>> QString. For my use cases implicit sharing is overkill
On October 14, 2015 22:13:11 Thiago Macieira wrote:
> On Wednesday 14 October 2015 17:55:34 Bubke Marco wrote:
>> Think about a local aware compare which is called very very often. You don't
>> want malloc in between. In in most cases you get an const char* or const
>&
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
> importa
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
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 pro
Gunnar Roth
> >
> > 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 alrea
Thiago Macieira
> On Tuesday 21 July 2015 16:14:18 Bubke Marco wrote:
> > Thiago Macieira
> >
> > > > > Or like QString and QByteArray will be in Qt 6.
> > > >
> > > > Are these still implicitly shared?
> > >
> > >
Thiago Macieira
> > > 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?
___
From: development-bounces+marco.bubke=theqtcompany@qt-project.org
on behalf of
Kevin Kofler
> If you have large objects, and insert or remove items within the list,
> QVector will have to move (or even copy&delete, if they're not movable)
> large amounts of data. Unless you use a QVector
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 t
> -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 ex
akters 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" wrote:
&
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 ide
Actually I like the idea but not so much the bool conversion operator. A
explicit method would be better. What about adding it in Qt Creator and testing
how useful it is? Is it not better to do something and speak about experiences
as to theorize in long discussions about the value of something
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
We have the same problem here in Designer. The 4 MB restriction of System V
shared memory makes it really useless for cross platform use.
Maybe we could use a mmap version for Mac? Best would be a switchable version.
;-)
Best, Marco
From: development-boun
From: Knoll Lars
>On 13/05/14 11:49, "Bubke Marco" 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 change
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 m
Hi
The Unified field is open two extra windows. Not very convenient.
It would be nice to have the conflict feature of 2.9 too. ;-)
Otherwise the new gerrit it really nice.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.
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
Hi Alan
From: Alan Alpert [4163654...@gmail.com]
On Tue, Aug 20, 2013 at 2:42 AM, Bubke Marco wrote:
> What about making ApplicationWindow a Item? We could skip the contentItem
> and there would be designer support.
The other problem is that both Window and ApplicationWindow are
releas
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 [
rs: 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-
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 li
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
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 importa
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 i
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,
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 "com
Sorry for the formatting but the web email client is improvable.
Rutledge Shawn:
I see it as an issue if you had to write that parser. No wonder it's out of
sync with the actual language parser. The one in declarative should have all
the features that you need, with suitable (ideally even publi
77 matches
Mail list logo
