Re: Multimap/set with predicates of derived types.
Am 01.05.2011 01:23, schrieb Andy Champ:
It looks as though in the MS VS2010 implementation the stored function
object for the compare on a multimap is a copy of the supplied object,
rather than the object itself. This means that the supplied object to a
constructor taking a compare can???t be of a class derived from the
template, but must be of the same class. Is this correct behaviour? If
so, why?
The implementation is conforming. According to Table 102 ??? Associative
container requirements (from FDIS, but it is already true in C++03) the
c'tor signatures accepting the comparison object, like
X(c)
X a(c);
where c denotes a value of type X::key_compare are specified as follows:
Requires: key_compare is
CopyConstructible.
Effects: Constructs an empty
container. Uses a copy of c as
a comparison object.
This is intentional, because it reflects the usual value-semantics that
you will find in most of the library (e.g. think of algorithms,
std::unique_ptr, allocators of containers, etc.). If you want to realize
dynamic polymorphic behaviour of the comparison object, it should hold a
pointer to a polymorphic class type or a function pointer. See also
below for more reasons in your example.
Andy
#include <set>
#include <algorithm>
#include <iostream>
int main()
{
// compare class derives from less<int>,
// but behaves like greater
class KC: public std::less<int>
{
public:
bool operator()(const int& _Left, const int& _Right) const
{
// inverted from normal
return (_Left > _Right);
}
};
// This class has a compare _type_ of less<int>
// but a specific object similar to greater
auto M = std::set<int>(KC());
M.insert(1);
M.insert(3);
M.insert(2);
// Output shows sort is by less not greater
std::for_each(M.begin(), M.end(), [&](int i){std::cout << i;});
}
In this example KC does not even override any function from
std::less<int> (which is not a polymorphic class type), but instead you
are hiding the base class operator() overload. This looks not like a
reasonable design to me. Assume, std::set where required to use the
exact type of it's constructor argument, it would behave like
std::function and there would not be much reason to make the type of
std::set dependent on the complete predicate type, so why should an
implementation try to deduce the actual compare object type of the
argument, since you already described in as part of the set type?
HTH & Greetings from Bremen,
Daniel Kr??gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]