On Sunday 31 January 2016 00:38:41 Marc Mutz wrote:
> > I'd already be happy with those that were (are, actually) already there.
> > I'd rather have 10-20 common algorithms with a convenient API than 80+
> > obscure ones that force me to use iterators (especially the boilerplate
> > .begin() and .e
Marc Mutz wrote:
> It's funny, because having learned C++ mostly together with Qt, and having
> ported Qt code from Qt 2 to Qt 3 and Qt 4 and 5, I find solace in the API
> stability of the STL. So we seem to have the same background, but have
> drawn different conclusions. Interesting. Maybe I have
On Friday 22 January 2016 22:51:30 Kevin Kofler wrote:
> Marc Mutz wrote:
> > Judging from the comments on my blog post from 2010(!), when they hear
> > QList people first think std::list (ie. linked list). Then they see that
> > there's also a QLinkedList and start thinking that QList is something
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
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 wrote
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
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 ex
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
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
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 wrot
On Saturday 23 January 2016 19:22:34 Marc Mutz wrote:
> > template < class Container, class Compare >
> > void sort ( Container container, Compare compare)
> > {
> >
> > sort(begin(container), end(container), compare);
> >
> > };
> >
> >
> >
> > Something like that perhaps? Feel free to add a
On Saturday 23 January 2016 17:46:39 Andre Somers wrote:
> On 22-1-2016 22:51, Kevin Kofler wrote:
> > I'd already be happy with those that were (are, actually) already
> > there. I'd rather have 10-20 common algorithms with a convenient API
> > than 80+ obscure ones that force me to use iterators
On 23-1-2016 17:39, Milian Wolff wrote:
On Freitag, 22. Januar 2016 22:51:30 CET Kevin Kofler wrote:
Marc Mutz wrote:
And this is where I stop taking you seriously, sorry. You can demand such
nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+
algorithms from the STL for Qt
On 22-1-2016 22:51, Kevin Kofler wrote:
I'd already be happy with those that were (are, actually) already
there. I'd rather have 10-20 common algorithms with a convenient API
than 80+ obscure ones that force me to use iterators (especially the
boilerplate .begin() and .end() iterators that will
On Freitag, 22. Januar 2016 22:51:30 CET Kevin Kofler wrote:
> Marc Mutz wrote:
> > And this is where I stop taking you seriously, sorry. You can demand such
> > nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+
> > algorithms from the STL for Qt. Or play god deciding which a
On Friday 22 January 2016 22:51:30 Kevin Kofler wrote:
> Sure, Qt 3's QList was also a linked list, but I have internalized the Qt 4
> changes by now.
Nitpick: that's Qt 2's QList. In Qt 3, we had QValueList and QPtrList. Qt 3's
QValueList (which was a linked list) became Qt 4's QList whereas QP
Marc Mutz wrote:
> But again, CoW can be retrofitted onto any value type (e.g.
> shared_ptr), while CoW types will never be truly value types.
Again this nonsensical claim that shared_ptr is CoW. I already replied once
explaining that it is not. Or where do you see a copy on write being done?
sh
Giuseppe D'Angelo wrote:
> If you have QVector v; , and
>
> thread 1 does v[5] = ...;
> thread 2 does QVector copy = v;
>
> without synchronizations, then you have a data race since QVector is only
> reentrant.
Of course you would. You would have a data race there even without CoW.
Kevi
Иван Комиссаров wrote:
> Why? In case of QMap, we have no need to use operator= to change the map.
> We simply detach and insert new data in it.
Even operator= would actually be safe here.
Kevin Kofler
___
Development mailing list
Development@q
On Saturday 23 January 2016 00:11:27 Marc Mutz wrote:
> Running attached test program (4 cores + 2-fold HT), I get these numbers:
Same machine as described earlier. Linux 3.2, GCC 5.3, libc 2.13, 8GiB RAM.
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Com
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:
QVector;
1: 483
2: 492
4: 498
8: 503
16: 502
32: 513
64: 631
128
Marc Mutz wrote:
> Judging from the comments on my blog post from 2010(!), when they hear
> QList people first think std::list (ie. linked list). Then they see that
> there's also a QLinkedList and start thinking that QList is something like
> std::deque. And then, if they are lucky, they realise i
On Friday 22 January 2016 13:37:22 Matthew Woehlke wrote:
> If you really have *the same* vector... Don't do that :-). Note that
> this implies that you are either operating on the same variable, or one
> thread is operating on a reference. That's not very common, and it's
> just not thread safe, e
On Friday 22 January 2016 18:02:53 Bubke Marco wrote:
> Actually what is happen if I am in the middle of changing a qvector, and
> then copying the vector in an other thread?
s/qvector/int/ and that answers your question.
If you're mutating the same variable, then either use a mutex or use atom
On Friday 22 January 2016 19:37:22 Matthew Woehlke wrote:
> On 2016-01-22 13:02, Bubke Marco wrote:
> > Actually what is happen if I am in the middle of changing a qvector, and
> > then copying the vector in an other thread?
>
> Are you concurrently modifying and copying *the same* vector, or a
>
On Friday 22 January 2016 18:34:26 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
>
On 2016-01-22 13:02, Bubke Marco wrote:
> Actually what is happen if I am in the middle of changing a qvector, and
> then copying the vector in an other thread?
Are you concurrently modifying and copying *the same* vector, or a
shallow copy that, under the hood, happens to be shared? The latter
Il 22 gen 2016 6:03 PM, "Bubke Marco" ha
scritto:
>
> Actually what is happen if I am in the middle of changing a qvector, and
then copying the vector in an other thread?
>
If you have QVector v; , and
thread 1 does v[5] = ...;
thread 2 does QVector copy = v;
without synchronizations, then you
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
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
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. T
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();
On 2016-01-22 05:00, Marc Mutz wrote:
> On Friday 22 January 2016 09:43:17 Иван Комиссаров wrote:
>> Why? In case of QMap, we have no need to use operator= to change the map.
>> We simply detach and insert new data in it.
>> Of course, in case of multiple changes, the map can reach some "invalid
>>
On 2016-01-21 17:35, Milian Wolff wrote:
> On Donnerstag, 21. Januar 2016 22:44:02 CET Andre Somers wrote:
>> So, please, enlighten me. What would be a realistic way to recover from
>> such an exception?
>
> [...]
> - abort whole application in orderly fashion (i.e. not terminate but do a
> real
On Thursday, January 21, 2016 12:10:21 PM CET Matthew Woehlke wrote:
> On 2016-01-20 23:44, Kevin Kofler wrote:
> > Almost all my containers grow with allocations. How should I know in
> > advance how much memory to reserve? It'd just waste an arbitrary amount
> > of memory and then still end up re
Le vendredi 22 janvier 2016 à 01:13 +0100, Kevin Kofler a écrit :
>
> I think Qt should ignore the "wider C++ community", too. The STL is really a
> completely different beast, we only share the language-level parts.
That statement sounds very harsh. Please remember that your users are
part o
Of course, i should add mutex to the getter and setter.
2016-01-22 13:14 GMT+03:00 Marc Mutz :
> On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote:
> > What
> > i'm missing?
>
> You haven't done the exercise with the int first.
>
> --
> Marc Mutz | Senior Software Engineer
> KDAB (Deutsch
On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote:
> What
> i'm missing?
You haven't done the exercise with the int first.
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
But i don't have multiple writers (1 thread can change map, multiple can
read) and QMap actually uses atomics (so no memory ordering problems). What
i'm missing?
2016-01-22 13:00 GMT+03:00 Marc Mutz :
> On Friday 22 January 2016 09:43:17 Иван Комиссаров wrote:
> > Why? In case of QMap, we have no
On Friday 22 January 2016 09:43:17 Иван Комиссаров wrote:
> Why? In case of QMap, we have no need to use operator= to change the map.
> We simply detach and insert new data in it.
> Of course, in case of multiple changes, the map can reach some "invalid
> state" before changes are finished (i.e. in
Why? In case of QMap, we have no need to use operator= to change the map.
We simply detach and insert new data in it.
Of course, in case of multiple changes, the map can reach some "invalid
state" before changes are finished (i.e. in case we need transacted
changes, we have to use mutex anyway). Bu
On Friday 22 January 2016 01:31:20 Kevin Kofler wrote:
> Marc Mutz wrote:
> > Ivan was talking about thread-safe classes. You need to lock a mutex to
> > take the copy.
>
> Returning a QMap instead of a std::shared_ptr would be perfectly
> thread-safe there.
Wrong.
--
Marc Mutz | Senior Softw
On Friday 22 January 2016 01:13:06 Kevin Kofler wrote:
> > I don't like QList because only experts can tell which guarantees it
> > provides for any given type (can I keep references into the container
> > across appends?).
>
> Simply assume that you can't.
>
[...]
Judging from the comments on m
Marc Mutz wrote:
> Ivan was talking about thread-safe classes. You need to lock a mutex to
> take the copy.
Returning a QMap instead of a std::shared_ptr would be perfectly
thread-safe there. The atomic reference counting would ensure that any
thread that wants to write to the data that another
Marc Mutz wrote:
> But the discussions about move ctors that throw aren't even about
> bad_alloc. They are about assertion exceptions.
How is a move constructor an appropriate place for a sanity check? The only
way the moved object can be invalid is if the original object was already
invalid. So
Marc Mutz wrote:
> I was replying to Kevin. QModelIndex exactly fits his complaints about
> const-&:
>
> It's a reference used in interfaces. As soon as you store it, though, it
> may become stale at the next opportunity (like when calling a virtual
> function). You're supposed to store them in QP
On Thursday 21 January 2016 22:44:02 Andre Somers wrote:
> On 21-1-2016 21:09, Milian Wolff wrote:
> > On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote:
> >> Op 21/01/2016 om 05:35 schreef Thiago Macieira:
> >>> On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:
> Thiago Ma
On Donnerstag, 21. Januar 2016 22:44:02 CET Andre Somers wrote:
> On 21-1-2016 21:09, Milian Wolff wrote:
> > On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote:
> >> Op 21/01/2016 om 05:35 schreef Thiago Macieira:
> >>> On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:
> Th
On 21-1-2016 21:09, Milian Wolff wrote:
On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote:
Op 21/01/2016 om 05:35 schreef Thiago Macieira:
On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:
Thiago Macieira wrote:
The copy constructor is called once, then the move constructo
On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote:
> Op 21/01/2016 om 05:35 schreef Thiago Macieira:
> > On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:
> >> Thiago Macieira wrote:
> >>> The copy constructor is called once, then the move constructor. If
> >>> value_type's move
On 2016-01-20 23:44, Kevin Kofler wrote:
> Almost all my containers grow with allocations. How should I know in advance
> how much memory to reserve? It'd just waste an arbitrary amount of memory
> and then still end up reallocating because it'll inevitably be exceeded at
> some point. Variable-
On 2016-01-20 17:43, Giuseppe D'Angelo wrote:
> This poses further questions down the line, such as whether it's "ok"
> having an index API based on signed integers. (It is for convenience, it
> is not for correctness, but I guess that's all the topic here, isn't it?
> :))
As Thiago noted, C++ its
On 2016-01-20 23:27, Kevin Kofler wrote:
> Thiago Macieira wrote:
>> The copy constructor is called once, then the move constructor. If
>> value_type's move constructor is not noexcept, then it may throw after the
>> container resized.
>
> Throwing an exception in a move constructor is really, rea
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
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
On Donnerstag, 21. Januar 2016 05:44:05 CET Kevin Kofler wrote:
> Bubke Marco wrote:
> > 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
On Thursday 21 January 2016 05:49:55 Kevin Kofler wrote:
> Marc Mutz wrote:
> > best of three runs, core i7-2720QM, GCC 5.3
>
> What OS and C library are you running those benchmarks on? The performance
> of realloc is vastly different between operating systems, so this is
> important information.
On Thursday 21 January 2016 05:33:51 Kevin Kofler wrote:
> Marc Mutz wrote:
> > You can lock a mutex in the function and unlock it in the shared_ptr's
> > deleter.
>
> How can that possibly be faster than atomic reference counting? You have
> the same cross-thread dependence plus a potential wait
On Thursday 21 January 2016 07:59:18 Mathias Hasselmann wrote:
> Am 21.01.2016 um 08:00 schrieb Marc Mutz:
> > On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote:
> >> Marc Mutz wrote:
> >>> On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
> All these are horrible and error-prone
Am 21.01.2016 um 08:00 schrieb Marc Mutz:
On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote:
Marc Mutz wrote:
On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
All these are horrible and error-prone hacks that have obvious lifetime
issues. You are complaining about Qt containers
Op 21/01/2016 om 05:35 schreef Thiago Macieira:
On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:
Thiago Macieira wrote:
The copy constructor is called once, then the move constructor. If
value_type's move constructor is not noexcept, then it may throw after the
container resized.
Thr
Op 21/01/2016 om 08:00 schreef Marc Mutz:
On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote:
Marc Mutz wrote:
On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
All these are horrible and error-prone hacks that have obvious lifetime
issues. You are complaining about Qt container
On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote:
> Marc Mutz wrote:
> > On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
> >> All these are horrible and error-prone hacks that have obvious lifetime
> >> issues. You are complaining about Qt containers because the detaching
> >> can
On Thursday 21 January 2016 05:33:51 Kevin Kofler wrote:
> Marc Mutz wrote:
> > You can lock a mutex in the function and unlock it in the shared_ptr's
> > deleter.
>
> How can that possibly be faster than atomic reference counting? You have the
> same cross-thread dependence plus a potential wait
Marc Mutz wrote:
> best of three runs, core i7-2720QM, GCC 5.3
What OS and C library are you running those benchmarks on? The performance
of realloc is vastly different between operating systems, so this is
important information.
Kevin Kofler
___
Bubke Marco wrote:
> 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.
Almost all my containers grow with allocations. How should I k
On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > The copy constructor is called once, then the move constructor. If
> > value_type's move constructor is not noexcept, then it may throw after the
> > container resized.
>
> Throwing an exception in a move constru
Marc Mutz wrote:
> You can lock a mutex in the function and unlock it in the shared_ptr's
> deleter.
How can that possibly be faster than atomic reference counting? You have the
same cross-thread dependence plus a potential wait for the thread to
actually do its work. Not to mention that mutexes
Thiago Macieira wrote:
> The copy constructor is called once, then the move constructor. If
> value_type's move constructor is not noexcept, then it may throw after the
> container resized.
Throwing an exception in a move constructor is really, really horrible. I
can see why a copy constructor wo
Marc Mutz wrote:
> On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
>> All these are horrible and error-prone hacks that have obvious lifetime
>> issues. You are complaining about Qt containers because the detaching can
>> invalidate iterators. Well, the lifetime issues you introduce with
Marc Mutz wrote:
> He's standing at the front[1] of the queue
>
> This item has top priority.
>
> Get it?
The item has top priority, which makes is stand at the front of the priority
queue and be the head of the priority queue. :-)
Sure, I understand where "top" comes from. It still does not f
On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
> Marc Mutz wrote:
> > In those cases where it does matter, you'd return by const-&. Or an
> > array_view. And no, that doesn't restrict your freedom to implement the
> > function in any meaningful way, because you can always keep a caching
On Wednesday 20 January 2016 23:43:07 Giuseppe D'Angelo wrote:
> This poses further questions down the line, such as whether it's "ok"
> having an index API based on signed integers. (It is for convenience, it
> is not for correctness, but I guess that's all the topic here, isn't it? :))
Current
On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
> In the end, your real issue is not with the containers, but with the
> slowness of the malloc you use. Which means we need faster allocations, not
> containers that minimize allocations at all costs, including worse
> asymptotic algorith
Il 20/01/2016 22:25, Kevin Kofler ha scritto:
Marc Mutz wrote:
No-one, not even experts understand QList, really. So it may appear to be
easy to use, but is actually a container only absolute experst should use.
QList gives people who just don't care about the internals something closer
to opt
Marc Mutz wrote:
> QString foo() { return QStringLiteral("foo"); }
> QString bar() { return Q3DeepCopy(QStringLiteral("foo")); }
>
> You will _never_ have the plugin-unloading problem with 'bar', only with
> 'foo', and the reason is CoW: suggesting value semantics where there
> aren't any.
No, th
Marc Mutz wrote:
> In those cases where it does matter, you'd return by const-&. Or an
> array_view. And no, that doesn't restrict your freedom to implement the
> function in any meaningful way, because you can always keep a caching
> mutable member to hold the result for the next call to the funct
On Wednesday 20 January 2016 22:25:27 Kevin Kofler wrote:
> And Qt also has a real
> pop unlike the misleadingly-named STL one: takeLast/takeFirst.
In the Standard Library's defence: the pop() function does not return the
element due to exception-safety. Example:
value_type takeLast() { val
Marc Mutz wrote:
> I doubt many people actively use the fact that Qt containers are cheap to
> copy.
Count me as a person who does (and not only for the obvious return value
case, where compiler optimizations or move semantics might possibly help).
For example, I have written a parser where the
Marc Mutz wrote:
> No-one, not even experts understand QList, really. So it may appear to be
> easy to use, but is actually a container only absolute experst should use.
QList gives people who just don't care about the internals something closer
to optimal than any of the containers optimized for
On Wednesday 20 January 2016 13:17:35 Thiago Macieira wrote:
> return s; // move-construction
> "steals" buffer }
>
> QtTools::String s = foo(); // move-construction attempts to
> steal
And in case the consequence isn't clear from the comment: the *stealing*
On Wednesday 20 January 2016 20:48:42 Kevin Kofler wrote:
> (That said, for the
> particular case of QVector::prepend, that could easily be fixed with the
> same trick used in QList.)
In Qt 6. Due to the way QArrayData is currently designed, you cannot reserve
space at the beginning without mak
On Wednesday 20 January 2016 20:05:08 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > We can only do that efficiently if we drop CoW. Creating an adapting API
> > is easy; making sure we don't do unnecessary copies because we've lost CoW
> > is the hard part.
>
> Would it be possible to wrap a QS
On Wednesday 20 January 2016 20:48:42 Kevin Kofler wrote:
> I consider STL's inconsistent APIs from one container to the other to be a
> major annoyance. And it is not even always about efficiency: e.g.,
> std::queue and std::priority_queue are implemented in the SAME header
> , both are queues,
Marc Mutz wrote:
> And if API consistency makes QVector have a prepend(), and QHash::iterator
> have it + n, something got out of hand...
I appreciate that Qt makes those operations possible (without having to code
them by hand). I know that operations such as QVector::prepend are not
efficient.
Bo Thorsen wrote:
> Den 19-01-2016 kl. 15:00 skrev Marc Mutz:
>> In Qt 6:
>> 1. ... dropping CoW ...
>
> I'm against any change that does this.
>
> I know you hate and loathe them. I don't. I think this alone makes Qt
> containers worth while. And it doesn't matter what arguments you give, I
> al
Thiago Macieira wrote:
> We can only do that efficiently if we drop CoW. Creating an adapting API
> is easy; making sure we don't do unnecessary copies because we've lost CoW
> is the hard part.
Would it be possible to wrap a QSharedDataPointer >, where
class VectorData : public QSharedData, publ
On Wednesday 20 January 2016 16:03:00 Jędrzej Nowacki wrote:
> On Tuesday 19 of January 2016 13:51:56 Marc Mutz wrote:
> > On Tuesday 19 January 2016 11:15:43 Milian Wolff wrote:
> > > On Dienstag, 19. Januar 2016 11:51:42 CET Marc Mutz wrote:
> > > > I missed one:
> > > >
> > > > On Monday 18 Jan
On Tuesday 19 of January 2016 13:51:56 Marc Mutz wrote:
> On Tuesday 19 January 2016 11:15:43 Milian Wolff wrote:
> > On Dienstag, 19. Januar 2016 11:51:42 CET Marc Mutz wrote:
> > > I missed one:
> > >
> > > On Monday 18 January 2016 23:43:37 Marc Mutz wrote:
> > > > #include
> > > > #in
On Tuesday, January 19, 2016 9:37:39 AM CET Thiago Macieira wrote:
> On Tuesday 19 January 2016 17:48:48 Giuseppe D'Angelo wrote:
> > On Tue, Jan 19, 2016 at 5:07 PM, Thiago Macieira
> > >
> > wrote:
> > > std::string someString()
> > > {
> > >
> > > return constexpr_string("foo");
> > >
> On Jan 19, 2016, at 10:40 PM, Marc Mutz wrote:
>
> On Tuesday 19 January 2016 19:56:38 Mathias Hasselmann wrote:
>> Am 19.01.2016 um 15:21 schrieb Ziller Eike:
On Jan 19, 2016, at 16:09, Marc Mutz wrote:
I doubt many people actively use the fact that Qt containers are cheap
to
I’m confused about how it would even be possible to contemplate abandoning the
implicit sharing paradigm given how deeply embedded it is within *all* of Qt,
going well beyond the container classes:
http://doc.qt.io/qt-5/implicit-sharing.html
Seems like Qt has adopted a core design principle he
Marc Mutz wrote:
> On Saturday 16 January 2016 02:40:02 Bubke Marco wrote:
>> I would prefer it we had a CoW wrapper around std vector.
>> Best of both worlds.
>
> aka std::shared_ptr>
std::shared_ptr is NOT CoW = implicitly shared, it is explicitly shared.
There is no detaching, so where do y
On Tuesday 19 January 2016 23:43:40 Marc Mutz wrote:
> > > - equal_range on hashed containers
> >
> > No idea what that is.
>
> http://en.cppreference.com/w/cpp/container/unordered_map/equal_range
>
> It's the correct way to find all values matching a given key (as opposed to
> QHash::values(con
On Tuesday 19 January 2016 18:34:48 Thiago Macieira wrote:
> On Tuesday 19 January 2016 19:16:25 Marc Mutz wrote:
> > That may be so. But most of what is _missing_ is implementable in Qt 5:
> >
> > - equal_range on hashed containers
>
> No idea what that is.
http://en.cppreference.com/w/cpp/cont
On Tuesday 19 January 2016 19:56:38 Mathias Hasselmann wrote:
> Am 19.01.2016 um 15:21 schrieb Ziller Eike:
> >> On Jan 19, 2016, at 16:09, Marc Mutz wrote:
> >> I doubt many people actively use the fact that Qt containers are cheap
> >> to copy.
> >
> > Each and every developer that uses Qt uses
On Tuesday 19 January 2016 13:00:46 Matthew Woehlke wrote:
> >> - not requiring op= / default ctor in QVector
> >
> > Not interesting to me.
>
> What about immutable types? I think this is worthwhile...
I don't. It's possible, but I don't have an interest in supporting this.
> >> - move-only pa
Am 19.01.2016 um 15:21 schrieb Ziller Eike:
On Jan 19, 2016, at 16:09, Marc Mutz wrote:
I doubt many people actively use the fact that Qt containers are cheap to
copy.
Each and every developer that uses Qt uses the fact that Qt containers are cheap to
“copy"
class A
{
public:
QVector
On Tuesday 19 January 2016 17:43:59 Matthew Woehlke wrote:
> On 2016-01-19 05:51, Marc Mutz wrote:
> > So... is realloc actually the optimisation everyone (incl. me) expected
> > it to be?
>
> It really *ought* to be, at least in the right cases.
>
> Let's say I have a type that stores a buffer,
On 2016-01-19 12:34, Thiago Macieira wrote:
> On Tuesday 19 January 2016 19:16:25 Marc Mutz wrote:
>> - emplace (with Q_COMPILER_UNIFORM_INIT ifdef)
>
> Done in QGenericArray, but not really relevant since we don't support move-
> only types.
I'd somewhat disagree; it can still be more efficient.
1 - 100 of 192 matches
Mail list logo
