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.
and make keys in associative containers immutable.