Re: map vs. set (stl)
On Thu, 24 May 2007 05:26:41 -0700, James Kanze wrote:
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 current wording in the standard says that X::iterator is an iterator
pointing to T and X::const_iterator is an iterator pointing to const T
where X is the container and T its value_type. This implies that
implementations where X::const_iterator and X::iterator are the same type
are non-conforming. Also modifications through X::iterator are possible
since the value_type T must also be assignable.
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).
It is not in the 2003 version.
--
Markus Schoder