Re: map vs. set (stl)
On May 24, 1:39 am, Markus Schoder <a3vr6dsg-use...@yahoo.de> wrote:
On Wed, 23 May 2007 15:29:54 -0700, Qwavel wrote:
On May 23, 4:59 pm, Markus Schoder <a3vr6dsg-use...@yahoo.de> wrote:
On Wed, 23 May 2007 12:41:18 -0700, Qwavel wrote:
Let's say I have something like this, where 'name' is a POD type, and
'value' is a class.
std::map< name, value >
But then I realize that 'name' should actually be one of the members
of 'value' class, so I have a redundancy. I then switch and start
using std::set< value >. To make 'value' suitable for this purpose,
I make it look like this...
class value {
const int name;
bool operator<( const value& rhs ) const
{ return name < rhs.name; }
void operator=( const value& rhs );
...
};
This now satisfies the requirements of a set, and it works. Great.
But I feel as though I have really strayed far from the idea of a
set. For example, the key part of my value is constant, but the
whole value is not.
Should I really be using a set like this?
The problem you might be facing is that you cannot (without casting)
modify the objects in the set through a set iterator. A set iterator is
basically always a const iterator to prevent breaking the ordering of
the set.
Yes, that is what you would expect.
However, in my STL, the set::find function returns a non-const iterator,
so I can modify the elements of the set. Of course, I must be careful
not to change the key value.
I'm using the STL that comes with MS VC8. I don't know if this behavior
conforms to the standard or not.
The current wording of the standard surprisingly _requires_ this behavior
but there is a defect report pending (103) that proposes to change this
and make keys in associative containers immutable.
The wording in the original standard required [multi]set::find()
on a non-const object to return a type [multi]set::iterator. It
did NOT require that you be able to modify the object through
the (non-const) iterator, and early implementations varied, some
using exactly the same type for iterator and const_iterator.
The discussions on this subjet were quite long, but the final
decision is that trying to modify the element through the
iterator, even if it was non-const, is undefined behavior. The
current draft has been modified to reflect this---I think it is
also in TC1 (and thuse the 2003 version of the standard).
--
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