On 15/05/2020 06.39, Edward Welbourne wrote:
Thiago Macieira (15 May 2020 02:30) replied
On Thursday, 14 May 2020 12:34:54 PDT Matthew Woehlke wrote:
On 14/05/2020 14.58, Thiago Macieira wrote:
Which is:
b) misspelling "iteratable"
Be that as it may, that ship has sailed:
https://www.go
On 14/05/2020 14.58, Thiago Macieira wrote:
>>> Which is:
>>> b) misspelling "iteratable"
On Thursday, 14 May 2020 12:34:54 PDT Matthew Woehlke wrote:
>> Be that as it may, that ship has sailed:
>>
>>https://www.google.com/search?q=iteratable
>>
>> Even Google thinks so, and if you insist othe
On Thursday, 14 May 2020 12:34:54 PDT Matthew Woehlke wrote:
> On 14/05/2020 14.58, Thiago Macieira wrote:
> > Which is:
> > b) misspelling "iteratable"
>
> Be that as it may, that ship has sailed:
>
>https://www.google.com/search?q=iteratable
>
> Even Google thinks so, and if you insist oth
> To have type-erased containers, we need to go back to something like
java.lang.Collection.
C++20 offers coroutines which allows the same things without java-like type
hierarchies though
(and with much more flexibility as you don't even need to have an actual
container existing somewhere - your f
On 14/05/2020 14.58, Thiago Macieira wrote:
Which is:
b) misspelling "iteratable"
Be that as it may, that ship has sailed:
https://www.google.com/search?q=iteratable
Even Google thinks so, and if you insist otherwise, 12k results instead
of 2M.
--
Matthew
On Thursday, 14 May 2020 04:20:43 PDT Иван Комиссаров wrote:
> I don’t see the problem here. Ranges library operates on views only, so
> there *should be* (I am just not aware of it’s name) the type that
> corresponds to the «forward access iterator» (well, in case of QSet, that
> would be bidirect
On Thursday, 14 May 2020 02:33:43 PDT Marc Mutz via Development wrote:
> On 2020-05-14 02:15, Thiago Macieira wrote:
> > On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote:
> >> std::span Project::productsSpan() const & { return
> >> d->products; }
> >> std::span Project::produc
On Thu, May 14, 2020 at 11:46:29AM +0200, Marc Mutz via Development wrote:
> > Please stop with this crusade of yours to end all CoW, get rid of
> > QList, etc. It is misguided and harmful to the ecosystem at large.
>
> You are entitled to your opinions just as I am. The difference is that I put
>
I don’t see the problem here. Ranges library operates on views only, so there
*should be* (I am just not aware of it’s name) the type that corresponds to the
«forward access iterator» (well, in case of QSet, that would be bidirectional
but not random access iterator) range.
If there’s no such v
On 2020-05-13 17:27, Matthew Woehlke wrote:
On 12/05/2020 12.59, Marc Mutz via Development wrote:
AsidE: If you think that CoW is still a thing today: no. SSO is a
thing these days, and it seems that QString will not have it in Qt 6,
either. NOI favours SSO, QString-everywhere cements the naïve
On 2020-05-14 02:15, Thiago Macieira wrote:
On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote:
std::span Project::productsSpan() const & { return
d->products; }
std::span Project::productsSpan() const && = delete;
Now implement either or both of these functions if interna
On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote:
> std::span Project::productsSpan() const & { return d->products; }
> std::span Project::productsSpan() const && = delete;
Now implement either or both of these functions if internally you have a
QSet.
--
Thiago Macieira -
On 13/05/2020 03.04, Lars Knoll wrote:
I don’t see a need to take a QStringView in those cases. With the
exception of some low level APIs, Qt’s APIs should be safe to use. An
overload taking a QStringView would either need to copy the data (in
which case we could just as well only offer the QStri
On 12/05/2020 12.59, Marc Mutz via Development wrote:
AsidE: If you think that CoW is still a thing today: no. SSO is a thing
these days, and it seems that QString will not have it in Qt 6, either.
NOI favours SSO, QString-everywhere cements the naïve CoW world of the
1990s for yet another deca
On 2020-05-13 09:56, Philippe wrote:
On Tue, 12 May 2020 18:59:35 +0200
Marc Mutz via Development wrote:
QString-everywhere cements the naïve CoW world of the
1990s for yet another decade.
CoW naive? Really not, this method is at the heart of many strategic
technologies.
eg.:
* virtual memo
On Wed, 13 May 2020 at 12:46, Marc Mutz via Development
wrote:
> In the not so hypothetical case that Qt is used to visualize results of
> some business calculations, chances are that thrid-party libraries will
> use std::string or std::u16string, and not QString, requiring the use of
> QString::f
On 2020-05-13 11:31, Marco Bubke wrote:
auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is
destroyed
AFAIK you can say that a rvalue should not return a reference by using
ref-qualified member functions.
View getView() const & { return v;}
Qt is so many years behind the mains
Nope, that would not be C++ if it wasn’t broken:
class C1
{
public:
std::string_view getMember() const & { return member; }
std::string member;
};
std::string_view m = C1().getMember(); // compiles!
You have to delete the method explicitly:
std::string_view getMember() const && = delete
On Wed, 13 May 2020 at 12:37, Marco Bubke wrote:
> auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is destroyed
> AFAIK you can say that a rvalue should not return a reference by using
> ref-qualified member functions.
> View getView() const & { return v;}
However,
whatever_fu
On 2020-05-13 09:04, Lars Knoll wrote:
On 12 May 2020, at 18:59, Marc Mutz wrote:
[...]
Most other classes:
* Only take and return QString
This is wrong. By taking a QString in the API of non-string-related
APIs, you expose QString as an implementation detail of the class.
Think QRegion, w
auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is destroyed
AFAIK you can say that a rvalue should not return a reference by using
ref-qualified member functions.
View getView() const & { return v;}
___
Development mailing list
Devel
Btw, I actually have an argument for returning a view=)
The ongoing c++20 ranges have exactly the same problem with the lifetime
issues. For instance, this won’t compile:
auto results = std::vector{1, 2, 3, 4, 5, 6}
| std::views::filter([](int n){ return n % 2 == 0; })
| std::views::tr
> 13 мая 2020 г., в 09:04, Lars Knoll написал(а):
>
> The above example is rather weirdly constructed.
>
> But anyhow, those data lifetime issues when using views as return values
> extensively are a lot less obvious to spot when a human reads the code. APIs
> should be safe to use wherever
On Tue, 12 May 2020 18:59:35 +0200
Marc Mutz via Development wrote:
> QString-everywhere cements the naïve CoW world of the
> 1990s for yet another decade.
CoW naive? Really not, this method is at the heart of many strategic
technologies.
eg.:
* virtual memory used by most of operating system
> On 12 May 2020, at 18:59, Marc Mutz wrote:
>
> Hi Lars,
>
> Let me pick important points one per email here:
>
> On 2020-05-12 09:49, Lars Knoll wrote:
> [...]
>> For String related classes:
>> * All methods not taking ownership of the passed arguments take a
>> QStringView
>
> Almost (see
Hi Lars,
Let me pick important points one per email here:
On 2020-05-12 09:49, Lars Knoll wrote:
[...]
For String related classes:
* All methods not taking ownership of the passed arguments take a
QStringView
Almost (see below).
* If the method stores a pointer to the passed data it should
On 6/12/19 10:28 AM, Mutz, Marc via Development wrote:
> On 2019-06-12 09:20, Ulf Hermann wrote:
>>> I don't think that (non-)COW is a problem in the scenario under
>>> discussion.
>>
>> Having the thing COW makes the porting simpler at the cost of suboptimal
>> performance. If we wrote a C
On 2019-06-12 09:20, Ulf Hermann wrote:
I don't think that (non-)COW is a problem in the scenario under
discussion.
Having the thing COW makes the porting simpler at the cost of
suboptimal
performance. If we wrote a COW container as a drop-in replacement for
QMap or QHash with equival
> I don't think that (non-)COW is a problem in the scenario under
> discussion.
Having the thing COW makes the porting simpler at the cost of suboptimal
performance. If we wrote a COW container as a drop-in replacement for
QMap or QHash with equivalent behavior we could just s/QMap/QFlat
On Tue, Jun 11, 2019 at 4:04 PM Giuseppe D'Angelo
wrote:
> Well, one difference is that we don't _already_ have an implementation
> of flat (unordered) maps to be replaced by a 3rd party library, and we
> are finding lots of cases where this would be useful...
>
Fair point. We don't already have
On Tue, Jun 11, 2019 at 11:42:32AM +0300, Konstantin Shegunov wrote:
> On Tue, Jun 11, 2019 at 11:31 AM Ulf Hermann wrote:
>
> > I imagine that a vector which automatically sorts itself on the first
> > lookup after any changes if it's larger than X items could be a drop-in
> > replacement for mo
Il 11/06/19 13:49, Konstantin Shegunov ha scritto:
I find that unlikely to happen. Otherwise it'd raise a question in my
mind why this[1] couldn't go in.
[1]: https://codereview.qt-project.org/c/qt/qtbase/+/261715
Well, one difference is that we don't _already_ have an implementation
of flat
On Tue, Jun 11, 2019 at 12:03 PM Ulf Hermann wrote:
> 3) Also sort the data on copying. Then you can still share the result.
>
You mean at the point of the shallow-copy (i.e. ref-count increment)? If
so, yes, that could work too, I think.
On Tue, Jun 11, 2019 at 12:46 PM Giuseppe D'Angelo via D
On 11/06/2019 10:28, Ulf Hermann wrote:
So, not having read the discussion about the equivalent container in
std, I'll make a naive suggestion here:
What about finding a QSortedVector that works for 90% of our internal
cases and adding that as private API (for now). The remaining 10% will
need
> I though about this as well. There's one caveat though. It can't be
> (easily) made COW (if we require it). If your lookup is non-mutable
> (i.e. `constFind` or w/e it's named), it'd mean that you have to mutate
> the data in a const method. This implies doing it (thread-)safely is
> going to
On Tue, Jun 11, 2019 at 11:31 AM Ulf Hermann wrote:
> I imagine that a vector which automatically sorts itself on the first
> lookup after any changes if it's larger than X items could be a drop-in
> replacement for most of the places where I misuse QHash or QMap. X could
> be a template paramete
Maybe we should move this into a more constructive direction:
I guess everybody can see that QMap and QHash are inefficient for
containers with few items. Many of us also seem to agree that just
repeating the sort/lookup on a vector all over the place is ugly and
makes the code less readable.
On 2019-05-17 10:18, Giuseppe D'Angelo via Development wrote:
QHash ones are bidirectional
Nope.
(Go look yourself, it's too hilarious for spoilers)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/develop
Иван Комиссаров wrote:
> I think, your point is wrong. Despite the fact Qt is a GUI toolkit, it should
> perform well.
> Take a look at Qt Item Views. They really sucks in terms of performance.
> QAbstractItemModel can have any number of rows/columns (that fits in MAX_INT),
> but which view can r
On 2019-06-06 15:49, Lars Knoll wrote:
On 6 Jun 2019, at 15:36, Mutz, Marc via Development
wrote:
On 2019-06-06 15:14, Konstantin Tokarev wrote:
[...]
There is a principle of single level of abstraction [1], and inline
implementation
of flat map can be viewed of violation of such principle. I
> On 6 Jun 2019, at 15:36, Mutz, Marc via Development
> wrote:
>
> On 2019-06-06 15:14, Konstantin Tokarev wrote:
> [...]
>> There is a principle of single level of abstraction [1], and inline
>> implementation
>> of flat map can be viewed of violation of such principle. If flat map
>> implement
On 2019-06-06 15:14, Konstantin Tokarev wrote:
[...]
There is a principle of single level of abstraction [1], and inline
implementation
of flat map can be viewed of violation of such principle. If flat map
implementations
were kept speparately, it would indeed make code easier to read and
mainta
06.06.2019, 15:43, "Elvis Stansvik" :
> Den tors 6 juni 2019 kl 13:56 skrev Elvis Stansvik :
>> Den tors 6 juni 2019 kl 13:40 skrev Mutz, Marc via Development
>> :
>> >
>> > On 2019-06-06 12:24, Lars Knoll wrote:
>> > >> On 6 Jun 2019, at 11:08, Simon Hausmann
>> > >> wrote:
>> > >>
>> >
> On 6 Jun 2019, at 14:49, Mutz, Marc via Development
> wrote:
>
> On 2019-06-06 14:04, Lars Knoll wrote:
>>> On 6 Jun 2019, at 13:39, Mutz, Marc via Development
>>> wrote:
> [...]
>>> You are equating Qt users and Qt implementers. You can maintain the Qt API,
>>> but use more efficient data
On 2019-06-06 14:04, Lars Knoll wrote:
On 6 Jun 2019, at 13:39, Mutz, Marc via Development
wrote:
[...]
You are equating Qt users and Qt implementers. You can maintain the Qt
API, but use more efficient data structures in the implementation. You
seem to be implying that these two things canno
Den tors 6 juni 2019 kl 13:56 skrev Elvis Stansvik :
>
> Den tors 6 juni 2019 kl 13:40 skrev Mutz, Marc via Development
> :
> >
> > On 2019-06-06 12:24, Lars Knoll wrote:
> > >> On 6 Jun 2019, at 11:08, Simon Hausmann
> > >> wrote:
> > >>
> > >> Am 06.06.19 um 10:42 schrieb Mutz, Marc via Developm
On Thu, 06 Jun 2019 13:46:12 +0200
"Mutz, Marc via Development" wrote:
> On 2019-06-06 12:24, Ola Røer Thorsen wrote:
> > tor. 6. jun. 2019 kl. 10:21 skrev Vitaly Fanaskov
> > :
> >
> >> Qt is GUI framework. Not only, yes, but this is the main purpose.
> >> +/-
> >> 10MB is almost nothing for GU
> On 6 Jun 2019, at 13:39, Mutz, Marc via Development
> wrote:
>
> On 2019-06-06 12:24, Lars Knoll wrote:
>>> On 6 Jun 2019, at 11:08, Simon Hausmann
>>> wrote:
>>> Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
> [...]
I have the feeling that some participants of these discussio
Den tors 6 juni 2019 kl 13:40 skrev Mutz, Marc via Development
:
>
> On 2019-06-06 12:24, Lars Knoll wrote:
> >> On 6 Jun 2019, at 11:08, Simon Hausmann
> >> wrote:
> >>
> >> Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
> [...]
> >>> I have the feeling that some participants of these d
On 2019-06-06 12:24, Ola Røer Thorsen wrote:
tor. 6. jun. 2019 kl. 10:21 skrev Vitaly Fanaskov
:
Qt is GUI framework. Not only, yes, but this is the main purpose.
+/-
10MB is almost nothing for GUI apps. Slightly faster
lookup/insertions,
cache line, proper alignment... Well, nice to have, but
On 2019-06-06 12:24, Lars Knoll wrote:
On 6 Jun 2019, at 11:08, Simon Hausmann
wrote:
Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
[...]
I have the feeling that some participants of these discussions
thought
they joined an adulation club for Qt API lovers instead.
I don't quite
tor. 6. jun. 2019 kl. 10:21 skrev Vitaly Fanaskov :
> Qt is GUI framework. Not only, yes, but this is the main purpose. +/-
> 10MB is almost nothing for GUI apps. Slightly faster lookup/insertions,
> cache line, proper alignment... Well, nice to have, but when an app
> spends most of the time on r
On 6 Jun 2019, at 11:08, Simon Hausmann
mailto:simon.hausm...@qt.io>> wrote:
Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
On 2019-06-06 09:47, Simon Hausmann wrote:
[...]
However I don't find your arguments that find_if/lower_bound is not
harder to read convincing. I continue to ag
On 6 Jun 2019, at 10:42, Mutz, Marc via Development
wrote:
>
> *But* it's not "hard to read" in the sense that you stare at it and can't
> figure out what the hell the code is doing.
You can insult my intelligence and CS credentials all you want, I’m still going
to claim that the STL-code in
On 2019-06-06 11:08, Simon Hausmann wrote:
Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
[...]
Do you guys _actually_ think that readability of Qt code trumps
_everything_?
For me the answer is "no". I believe that for the majority of Qt code
we
should strike for a compromise -
Well, my point was: there always should be a trade off. I've never wrote
that Qt should be slow. I just wanted to point out that understanding of
performance might be different for different sort of libraries (and for
different cases).
I hope, you filed a ticket or fixed this problem yourself.
Hi Marc,
I agree with a lot of your points. Performance is important to me. I won't get
bogged down in the specifics, because way too much energy has already been
wasted on this (and related) threads I think, so I'll just say a few things.
On Thu, Jun 6, 2019, at 10:45 AM, Mutz, Marc via Develo
I think, your point is wrong. Despite the fact Qt is a GUI toolkit, it should
perform well.
Take a look at Qt Item Views. They really sucks in terms of performance.
QAbstractItemModel can have any number of rows/columns (that fits in MAX_INT),
but which view can really handle that? None of them!
Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
> On 2019-06-06 09:47, Simon Hausmann wrote:
> [...]
>> However I don't find your arguments that find_if/lower_bound is not
>> harder to read convincing. I continue to agree with Joerg and Tor Arne
>> and feel that the API of the associative
On 2019-06-06 10:17, Vitaly Fanaskov wrote:
As a library implementer, you are simply not _allowed_ the freedom to
use a convenient tool over the most efficient one. That is, to put it
mildly, a disservice to users and a disgrace to the profession of
programmers.
Well, optimization is probably go
On 2019-06-06 09:47, Simon Hausmann wrote:
[...]
However I don't find your arguments that find_if/lower_bound is not
harder to read convincing. I continue to agree with Joerg and Tor Arne
and feel that the API of the associative containers results in code
that
is more compact, visually less noi
> As a library implementer, you are simply not _allowed_ the freedom to
> use a convenient tool over the most efficient one. That is, to put it
> mildly, a disservice to users and a disgrace to the profession of
> programmers.
Well, optimization is probably good, but not always, I would say. If
yo
I second your use of sorted vectors, especially for small ones.
However, a key to master code complexity is to be able to easily recognize
abstractions.
This reduces cognitive load when dealing with code. Generally Qt shines here.
A potential QDictionnary would speak to a reader more directly th
Am 06.06.19 um 09:05 schrieb Mutz, Marc via Development:
> On 2019-06-06 08:24, Joerg Bornemann wrote:
>> On 6/5/19 5:49 PM, Mutz, Marc via Development wrote:
>>
>>> As a library implementer, you are simply not _allowed_ the freedom to
>>> use a convenient tool over the most efficient one. That is
On 2019-06-06 08:24, Joerg Bornemann wrote:
On 6/5/19 5:49 PM, Mutz, Marc via Development wrote:
As a library implementer, you are simply not _allowed_ the freedom to
use a convenient tool over the most efficient one. That is, to put it
mildly, a disservice to users and a disgrace to the profes
On 6/5/19 5:49 PM, Mutz, Marc via Development wrote:
> As a library implementer, you are simply not _allowed_ the freedom to
> use a convenient tool over the most efficient one. That is, to put it
> mildly, a disservice to users and a disgrace to the profession of
> programmers. 8KiB just to lo
On 2019-05-16 20:18, Mutz, Marc wrote:
[...]
[1] Paraphrasing what Alex Stepanov teaches in his A9 courses: No C
programmer would _ever_ get the idea to use a self-rebalancing
red-black tree for something that holds a dozen elements. Because once
you understand what is required to implement one,
On Tue, May 21, 2019 at 04:41:42PM +0300, Danila Malyutin wrote:
> Exhibit C:
>
> foo().contains(x)
>
> https://godbolt.org/z/KlIcFc
-std=c++2a
But yes, I am aware of that, and I am perfectly happy with the tendency
to chose practically sensible approaches in Standard C++ for a while now.
Bu
On Tue, May 21, 2019 at 08:32:07AM +0200, Mutz, Marc via Development wrote:
>
> By that line of reasoning, the change from
>
>Q3Slider *sl = new Q3Slider(0, 100, 50, 10, 1, this);
>
> to
>
>Q4Slider *sl = new Q4Slider(this);
>sl->setRange(0, 100);
>sl->setValue(50);
>sl->set
Exhibit C:
foo().contains(x)
https://godbolt.org/z/KlIcFc
пн, 20 мая 2019 г. в 23:14, André Pönitz :
> On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote:
> > [...] There is no readability difference between the use of a Qt
> container and
> > that of an STL container.
>
> On 21. May 2019, at 08:32, Mutz, Marc via Development
> wrote:
>
> On 2019-05-20 23:43, André Pönitz wrote:
>> On Mon, May 20, 2019 at 11:23:13PM +0200, Mutz, Marc via Development wrote:
>>> On 2019-05-20 23:21, André Pönitz wrote:
>>> > > > Exhibit A:
>>> > > >
>>> > > > foo().contains
On 20/05/2019 23:11, André Pönitz wrote:
> On Mon, May 20, 2019 at 08:44:47PM +, Marco Bubke wrote:
>> On May 20, 2019 22:16:11 André Pönitz wrote:
>>
>>> On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote:
[...] There is no readability difference between the use
On Tue, May 21, 2019 at 9:34 AM Mutz, Marc via Development <
development@qt-project.org> wrote:
> [...]
> This does not make the API simple to use.
Actually it does. Simple, as "easily understood or done" and
self-explanatory, which isn't the case for the Q3Slider's constructor. Yes,
familiarity
On 2019-05-20 23:43, André Pönitz wrote:
On Mon, May 20, 2019 at 11:23:13PM +0200, Mutz, Marc via Development
wrote:
On 2019-05-20 23:21, André Pönitz wrote:
> > > Exhibit A:
> > >
> > > foo().contains(x)
> > >
> > >
> > > Exhibit B:
> > >
> > > {
> > > ... container = foo();
On 2019-05-20 23:14, Konstantin Shegunov wrote:
On Mon, May 20, 2019 at 11:32 PM Mutz, Marc via Development
wrote:
All I'm saying is that there are tons of examples (QGradient) where
the
use of an owning container in the API is just a very bad idea and
limits
the implementor's freedom and/or p
> There is no readability difference between the use of a Qt container and
> that of an STL container. Don't confuse familiarity with
> simplicity.
That is true. You can get familiar with both, STL and foot fungus over time.
But both will
remain disturbing forever ;-)
I used STL from time to
On Mon, May 20, 2019 at 11:23:13PM +0200, Mutz, Marc via Development wrote:
> On 2019-05-20 23:21, André Pönitz wrote:
> > > > Exhibit A:
> > > >
> > > > foo().contains(x)
> > > >
> > > >
> > > > Exhibit B:
> > > >
> > > > {
> > > > ... container = foo();
> > > > std::fi
On 2019-05-20 23:21, André Pönitz wrote:
On Mon, May 20, 2019 at 10:48:29PM +0200, Mutz, Marc via Development
wrote:
On 2019-05-20 22:18, André Pönitz wrote:
> On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development
> wrote:
> > [...] There is no readability difference between the u
On Mon, May 20, 2019 at 10:48:29PM +0200, Mutz, Marc via Development wrote:
> On 2019-05-20 22:18, André Pönitz wrote:
> > On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development
> > wrote:
> > > [...] There is no readability difference between the use of a Qt
> > > container and
> > >
On Mon, May 20, 2019 at 11:32 PM Mutz, Marc via Development <
development@qt-project.org> wrote:
> All I'm saying is that there are tons of examples (QGradient) where the
> use of an owning container in the API is just a very bad idea and limits
> the implementor's freedom and/or performance. E.g.
On Mon, May 20, 2019 at 08:44:47PM +, Marco Bubke wrote:
> On May 20, 2019 22:16:11 André Pönitz wrote:
>
> > On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote:
> >> [...] There is no readability difference between the use of a Qt container
> >> and
> >> that of an S
On 2019-05-20 22:18, André Pönitz wrote:
On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development
wrote:
[...] There is no readability difference between the use of a Qt
container and
that of an STL container.
Exhibit A:
foo().contains(x)
Exhibit B:
{
... co
On May 20, 2019 22:16:11 André Pönitz wrote:
> On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote:
>> [...] There is no readability difference between the use of a Qt container
>> and
>> that of an STL container.
>
> Exhibit A:
>
> foo().contains(x)
>
>
> Exhibit B:
>
On 2019-05-20 12:48, Lars Knoll wrote:
So you should give people the option to implement their 5% code that’s
performance critical in a fast way and make it as easy as possible for
them to implement the remaining 95%.
I fully agree. The problem is that Qt as a library doesn't know where
these
C++ standart is a software and like any software, it has bugs.
It’s good that «auto_ptr» bug was fixed among with auto a {42};
However, reading the dev list it seems that people claim that *everything* that
is done by the Committee is a bug and there’s only the «Qt way» of doing things
like it w
On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote:
> [...] There is no readability difference between the use of a Qt container and
> that of an STL container.
Exhibit A:
foo().contains(x)
Exhibit B:
{
... container = foo();
std::find(contai
On Fri, May 17, 2019 at 07:47:55AM +0200, Mutz, Marc via Development wrote:
> On 2019-05-16 23:41, Konstantin Shegunov wrote:
> > you end up where the STL is - so convoluted it's hardly worth making
> > anything with it.
>
> Qt is a C++ library. If you don't like C++, either stay in QML or use Jav
> On 17 May 2019, at 21:12, Giuseppe D'Angelo via Development
> wrote:
>
> Il 17/05/19 16:46, Bernhard Lindner ha scritto:
>>> I've done this experiment for QMap / QHash / QSet, where keeping COW at
>>> the cost of an extra indirection (dptr -> [refcount + std:: class] ->
>>> actual data) is mor
> On 17 May 2019, at 07:47, Mutz, Marc via Development
> wrote:
>
> On 2019-05-16 23:41, Konstantin Shegunov wrote:
>> you end up where the STL is - so convoluted it's hardly worth making
>> anything with it.
>
> Qt is a C++ library. If you don't like C++, either stay in QML or use Java.
> No-
On 2019-05-17 19:47, Scott Bloom wrote:
[...]
Im just going to throw out my 2 bits on this
Please don’t underestimate (and Im not hearing Thiago say this) the
pain, of breaking source compatibility. Even on Major (5->6) version
changes.
[...]QCanvas[...]QWebKit[...]
When the Qt team, de
Fair enough..
But I will say.. all too often.. theory becomes practice
--
Please note that nobody said «we are removing Qt containers in Qt6». At least,
I don’t have that information.
The discussion is mostly about a *theoretical* case when the implementation of
a *theoretical* me
Il 17/05/19 16:46, Bernhard Lindner ha scritto:
I've done this experiment for QMap / QHash / QSet, where keeping COW at
the cost of an extra indirection (dptr -> [refcount + std:: class] ->
actual data) is more acceptable since these classes jump all over the
memory anyhow. Basically "it worked",
Please note that nobody said «we are removing Qt containers in Qt6». At least,
I don’t have that information.
The discussion is mostly about a *theoretical* case when the implementation of
a *theoretical* method in a *theoretical* class may *theoretically* change and
how far we should go to sup
On Friday, 17 May 2019 09:38:05 PDT Marco Bubke wrote:
> Thiago, you partially implying that BC is still needed but with
> technologies like flatpak or snappy this will maybe not common use
> case anymore. They provide even behaviour compatibility if you stay with the
> same runtime.
> Something
On Friday, 17 May 2019 09:38:05 PDT Marco Bubke wrote:
> Thiago, you partially implying that BC is still needed but with technologies
> like flatpak or snappy this will maybe not common use case anymore. They
> provide even behaviour compatibility if you stay with the same runtime.
> Something whic
Thiago, you partially implying that BC is still needed but with technologies
like flatpak or snappy this will maybe not common use case anymore. They
provide even behaviour compatibility if you stay with the same runtime.
Something which is not provided by binary compability. I personally think
My not (that) complex mobile app (game) used almost entirely QML/Javascript -
but when I needed mutual exclusion/atomicity I have not figured out anything
but going back to good, old C++...
And as mentioned below, wide variety of containers/datatypes, algorithms, etc...
So yes, perforrmance is
On Thursday, 16 May 2019 11:18:08 PDT Mutz, Marc via Development wrote:
> > When you first design the class, sure. But 5 years later, you may have
> > the
> > data internally kept in a QMap or QHash, mapped to some other
> > information. So
> > your function that used to "return d->member;" now doe
> I've done this experiment for QMap / QHash / QSet, where keeping COW at
> the cost of an extra indirection (dptr -> [refcount + std:: class] ->
> actual data) is more acceptable since these classes jump all over the
> memory anyhow. Basically "it worked", still requiring a few changes
> thou
On 2019-05-17 11:36, Philippe wrote:
[...]
QVarLengthArray
While it is true that there's no such container, it's even more true
that there will never be one. Because C++ made the allocators, which
back in the 90s were just a way to handle near and far pointers on
older
architectures, fit for ac
1 - 100 of 123 matches
Mail list logo
