Re: map parameters
On Mar 19, 1:37 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
On Mar 18, 6:16 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
pk_pk wrote:
why is it that i am allowed to use a class or a struct for
the "value" part in a map, but not for the "key" in the
pair?
You can, but not just any class will do. There are
requirements.
i can do this (where CMaterial is a struct) :
typedef std::map<std::string, CMaterial> MatAttr;
but i can't do:
typedef std::map<CMaterial, CMaterial> Stuff;
i realize i can do this:
typedef std::map<CMaterial*, CMaterial> Stuff;
i'm curious to know why the "key" has to be a fundamental
datatype like a pointer, float, etc.
It does not have to be a fundamental datatype. Note that
you already used std::string as a key.
The requirements for the type to be used as a key are (off the
top of my head):
a) KeyType has to be copy-constructible.
At least at present, it also has to be assignable. (I don't
think that any implementation actually requires the assignment,
except to fulfill a concept check, and I vaguely seem to
remember hearing that this requirement will be dropped in the
future.)
Since the value_type of map<S,T> is pair< const S, T >, I have
to wonder what assignability of the key-type would buy us in
_any_ possible implementation.
I never said that it would buy us anything. I can't imagine a
reasonable implementation which would use it. But at least
through C++03, it's formally a requirement.
If I've understood correctly (but it's something I've not really
paid too much attention to, so I could easily be wrong here),
assignment is not necessary for any reasonable implementation of
any of the node based types (all of the associative containers,
plus std::list---and the unordered containers as well, I think),
and the requirement for it will be dropped in the next version
of the standard. (But verify with a more reliable source before
counting on it.)
b) std::less<KeyType> has to be defined. The standard way of achieving
that
is to have KeyType provide an operator<.
I suspect that it's more idiomatic for the user to provide a
custom comparison operator to the map. (It really depends on
the class, of course. If an operator< makes sense in general,
then you provide it. If it doesn't, however, you don't provide
one just for std::map---you define some sort of comparison type
which you specify explicitly.)
Well, I don't know what is more idiomatic. I routinely define
operator< or specialize std::less<> just so that my type can
be used transparently in sets and maps. In fact, I think, the
compiler should just provide a default like lexicographic
ordering along members.
The problem with this, IMHO, is that < already has a more or
less established meaning in the minds of the reader. Long
before the STL, for example, my bit vector based set types
overloaded the relational operators for subsets: a < b meant
that a was a strict subset of b. And while I rather think that
one could qualify this as operator overloading abuse, I don't
think it's really cut and dried---my users found it natural, at
any rate. Of course, the subset relationship is *not* an
acceptable ordering for the STL. When the STL was adopted, I
provided a separate ordering relationship for it. At the other
end of the spectrum, the standard does (correctly, IMHO) not
provide relational operators for complex---I'm sure the idea of
applying < to complex numbers would shock a mathematician.
IMHO, the general rule should be that < corresponds to something
that a normal reader would call less that, and that if the type
doesn't have a natural, undisputed ordering, then < should not
be defined. And that except for strings and ordered numeric
types, the user will normally specify the ordering to be used
for std::set. I'm not opposed, however, to providing an
arbitrary ordering by means of a specialized type for this.
When I start using hash maps, I will also routinely provide a
hash function.
That's different. A hash function is, by definition, a hash
function. < is not an arbitrary strict ordering function, it
expresses a different relationship.
I don't think that std::less<T> has to be natural. That it is
useful is entirely sufficient for me.
I don't think I'd mind a specialization of std::less<T>, IF the
class doesn't define operator<. (And there's the precedence for
pointers.) Anytime the results of a < b are defined, however, I
rather think that that's what std::less should return, to avoid
confusion. Thus, it's not an option for my bitmapped sets.
More generally, what's the problem with having to specify the
ordering function? (I don't think I've ever used std::set
without specifying it. With std::map, I'd guess that 90% of the
time, the key is std::string, but if it's neither std::string or
a built-in numeric type, I tend to specify it as well.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34