[containers] Templated map::find?
Hi list. I was asked today why the std::map container didn't have templated versions of functions like find, lower_bound, and so on. I could not give a good answer on why there could not exist such a thing, assuming that the comparator had sufficient symmetric overloads for the real Key type and the FauxKey that the query would be performed with. Would something like this be possible to add to Boost.Containers, considering that going through the typical standard routes would have a latency of a couple years at best? I'm told that the Boost.Intrusive containers already supports this. Some use cases would be querying with a type that's convertible (in an expensive way) to the held key type, or querying with a key type that has only the fields that affect ordering in the case of a rich key type. -- Lars Viklund | zao@acc.umu.se
On 22/08/2011 13:37, Lars Viklund wrote:
Hi list.
I was asked today why the std::map container didn't have templated versions of functions like find, lower_bound, and so on. I could not give a good answer on why there could not exist such a thing, assuming that the comparator had sufficient symmetric overloads for the real Key type and the FauxKey that the query would be performed with.
Boost.Intrusive provides this feature, I believe.
Would something like this be possible to add to Boost.Containers, considering that going through the typical standard routes would have a latency of a couple years at best? I'm told that the Boost.Intrusive containers already supports this.
That would make Boost.Containers not standard-conforming, unless the function was given a different name.
On Mon, Aug 22, 2011 at 3:21 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Would something like this be possible to add to Boost.Containers, considering that going through the typical standard routes would have a latency of a couple years at best? I'm told that the Boost.Intrusive containers already supports this.
That would make Boost.Containers not standard-conforming, unless the function was given a different name.
Does the standard require exact function signatures? Olaf
On Mon, Aug 22, 2011 at 03:35:04PM +0200, Olaf van der Spek wrote:
On Mon, Aug 22, 2011 at 3:21 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Would something like this be possible to add to Boost.Containers, considering that going through the typical standard routes would have a latency of a couple years at best? I'm told that the Boost.Intrusive containers already supports this.
That would make Boost.Containers not standard-conforming, unless the function was given a different name.
Does the standard require exact function signatures?
Good question. On one hand, in the MS SC++L there's some variation in the set of insert overloads I believe. I could guess that one reason would be that code that relies on that there would be only one overload would suddenly cause unresolved-overload errors (use case: bind(&map<K,V>::find, this, ..) I was not quite aware that Containers was intended as a 1:1 implementation of the 11 containers, probably fooled by the set of non-standard containers bundled in the library. -- Lars Viklund | zao@acc.umu.se
El 22/08/2011 13:37, Lars Viklund escribió:
Hi list.
I was asked today why the std::map container didn't have templated versions of functions like find, lower_bound, and so on. I could not give a good answer on why there could not exist such a thing, assuming that the comparator had sufficient symmetric overloads for the real Key type and the FauxKey that the query would be performed with.
Because no-one has requested it ;-)
Would something like this be possible to add to Boost.Containers, considering that going through the typical standard routes would have a latency of a couple years at best? I'm told that the Boost.Intrusive containers already supports this.
I plan to implement extensions if they are useful. Boost.Container associative containers lie above Boost.Intrusive, which already supports this, so it wouldn't be difficult to implement. Best, Ion
participants (4)
-
Ion Gaztañaga -
Lars Viklund -
Mathias Gaunard -
Olaf van der Spek