Il 20/12/19 16:05, Vitaly Fanaskov ha scritto:
I'm not totally sure I understand this point. What do you mean by
"memory management"?
Inside of containers you need to allocate and de-allocate memory. If
container is passed across a library boundary, there is a question what
version of new/delete
On Friday, 20 December 2019 07:05:15 PST Vitaly Fanaskov wrote:
> If
> container is passed across a library boundary, there is a question what
> version of new/delete should be used.
There's only one global operator new and delete. Anything else is a nightmare,
fragile, prone to mistakes and only
On Fri, Dec 20, 2019 at 02:47:06PM +0100, Giuseppe D'Angelo via Development
wrote:
> Il 20/12/19 12:20, Philippe ha scritto:
> > std::unordered_map is before all an interface and the implemenation varies
> > according to the library supplier.
> > And this, potentially much more eg. than std::vect
> I'm not totally sure I understand this point. What do you mean by
> "memory management"?
Inside of containers you need to allocate and de-allocate memory. If
container is passed across a library boundary, there is a question what
version of new/delete should be used. But this can be "easily"
> On 20 Dec 2019, at 15:14, Giuseppe D'Angelo via Development
> wrote:
>
> Il 20/12/19 13:54, Vitaly Fanaskov ha scritto:
>> This is not that easy to use std::* containers because at least the
>> following issues have to be addressed:
>> * Memory management
>> * Binary compatibility
>> *
Il 20/12/19 13:54, Vitaly Fanaskov ha scritto:
This is not that easy to use std::* containers because at least the
following issues have to be addressed:
* Memory management
* Binary compatibility
* Implementation consistency
You probably can provide, for example, some allocators, relax
On Fri, 20 Dec 2019 at 15:48, Giuseppe D'Angelo via Development
wrote:
>
> Il 20/12/19 12:20, Philippe ha scritto:
> > std::unordered_map is before all an interface and the implemenation varies
> > according to the library supplier.
> > And this, potentially much more eg. than std::vector.
> > An
On Fri, 20 Dec 2019 at 13:24, Philippe wrote:
>
> >> just using std::unordered_map would have minimal effort on our side
> >> ("someone else's problem", and it's not even a random 3rd party...)
>
> std::unordered_map is before all an interface and the implemenation varies
> according to the libra
Il 20/12/19 14:57, Ulf Hermann ha scritto:
The fun starts when the user works with Nice3rdPartyHash in their
application, then transforms it into QHash to use our public API, which
we then transform into QReallyGreatHash for internal usage.
Sure, but how often do we transfer containers ownershi
> And my point was that Qt shouldn't _really_ bother reinventing something
> already easily available elsewhere. Usage of a "fast hash" internally to
> Qt doesn't mean we provide that API to our user (hello, QFlatMap; or
> std::vector usages all over Qt internals.).
The fun starts when the user
Il 20/12/19 12:20, Philippe ha scritto:
std::unordered_map is before all an interface and the implemenation varies
according to the library supplier.
And this, potentially much more eg. than std::vector.
And X-Platorm Qt users would expect performance consistency I guess.
Devil's advocate, aga
This is not that easy to use std::* containers because at least the following
issues have to be addressed:
* Memory management
* Binary compatibility
* Implementation consistency
You probably can provide, for example, some allocators, relax compatibility
requirements and so on... T
>> just using std::unordered_map would have minimal effort on our side
>> ("someone else's problem", and it's not even a random 3rd party...)
std::unordered_map is before all an interface and the implemenation varies
according to the library supplier.
And this, potentially much more eg. than std:
+10
It's excellent because it behaves very well in multiple scenarios, which
is uncommon for a hash map.
And according to your design, it should perform equally well with very small
maps.
And all that under 1000 lines of code, this is brillant (BTW, you need to
#include in qthash.h)
Given the
On 20 Dec 2019, at 11:47, Giuseppe D'Angelo via Development
mailto:development@qt-project.org>> wrote:
Il 20/12/19 09:23, Lars Knoll ha scritto:
The result was that QHash has clear weaknesses compared to other
implementations. It uses too much memory and certainly isn’t the fastest
implementat
Il 20/12/19 09:23, Lars Knoll ha scritto:
The result was that QHash has clear weaknesses compared to other
implementations. It uses too much memory and certainly isn’t the fastest
implementation. But std::unordered_map is just as bad, so there’s no point in
using that to implement QHash.
Jus
On Fri, 20 Dec 2019 at 10:25, Lars Knoll wrote:
>
> Hi,
>
> I’ve been playing around with QHash during our recent Hackathon at The Qt
> Company. I started with measuring and comparing our implementation with
> various others that are out there using the benchmark that’s described here:
> https:
Hi all,
We released Qt Design Studio 1.4.0 today, see
https://www.qt.io/blog/qt-design-studio-1.4-released.
Big thanks to everyone involved!
Best Regards,
Thomas Hartmann
___
Development mailing list
Development@qt-project.org
https://lists.qt-projec
Hi,
I’ve been playing around with QHash during our recent Hackathon at The Qt
Company. I started with measuring and comparing our implementation with various
others that are out there using the benchmark that’s described here:
https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html.
19 matches
Mail list logo
