C++ Logo

sg14

Advanced search

Re: Colony/hive & unordered vs ordered == operator

From: Neil Horlock <nhorlock_at_[hidden]>
Date: Tue, 15 Mar 2022 01:52:18 +0000
As the collection itself is unordered, an equality operator that enforces
some notion of order seems counter-intuitive.
The use case for hive comparison seems niche (cache invalidation maybe?
"has this collection changed since the last frame/iteration"?), but if all
we're essentially saying is "I want to know if collection B has the same
contents as collection A", then the unordered equality seems to be the only
practical option; without this, we'd have to sort both, then compare. On
the other hand, an equality operator that expects order where there is none
implied seems, in my limited brainstorming at least, to have no useful
practical application (to pick your phrasing); moreover could this not lead
to different results on different platforms/implementations?

regards

Neil


On Tue, 15 Mar 2022 at 00:20, Matt Bentley via SG14 <sg14_at_[hidden]>
wrote:

> Hi Everyone,
> quick question:
> colony/hive is unordered in terms of insertion position (but sortable),
> should the ==/!= operator also be unordered ie.
> should hive<int> {1,2, 3} == hive<int> {3, 1, 2}?
>
> My main interest is not which is more 'correct' but which is more useful
> in practice?
> I don't use == operator for containers a lot so I don't know.
> Be aware this will affect >= < etc also.
>
> The unordered version of the operator is trivial, but slower -
> it allocates pointers to each of the elements in each of the containers,
> then sorts the pointers via the values they point to, then does a
> standard == left-hand/right-hand compare via the pointers.
> This means (a) == allocates, (b) == is slower due to jumping around in
> memory and not necessarily following element sequence.
>
> Opinions?
>
> BTW lewg hive discussion next week, for those who are a part of lewg
> already.
> m@
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>

Received on 2022-03-15 01:52:30