Re: [Boost-users] [Unordered] [Multi-Index] Set lookup from something else than key_type

Subject: Re: [Boost-users] [Unordered] [Multi-Index] Set lookup from something else than key_type
From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2009-09-02 15:17:29

Dominique Devienne <ddevienne <at> gmail.com> writes:

> 
> FTR, I tend to lean on Joaquín's side of the argument. If the provided
> explicit Hash/Pred template parameters of unordered_set do provide overloads
> for compatible keys, then it's "by design" that find() should use them.
> 
> If previous code that was relying on an implicit conversion to key_type
> starts using added overload on Pred/Hash, this simply means that the
> container designer made this choice explicitly, and I don't see why that
> a bad thing. After all the overloads were added for avoiding the key
> creation, which is exactly what I was trying to do here.

The problem James points to is not the one you describe,
but the following: imagine Hash and Pred are not overloaded
and another_type is a type implicitly convertible to
key_type (in the example given by James, key_type=std::string,
another_type=const char*). Without compatible key extensions,
the code

  another_type x=...
  cont.find(x);

is equivalent to

  another_type x=...
  cont.find(key_type(x));

But if find is templatized to accept compatible keys, then

   cont.find(x);

will not trigger the implicit conversion to key_type,
instead, every internal expression involving invocations
to the Hash and Pred internal objects with x as argument
will trigger the conversion. The net effect is that
we pass from one implicit conversion when invoking
find() to multiple implicit conversions inside find()
code.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo