Need help with a container design

[Michael Klatt]

I need to design a container similar to a std::set, but where the
stored objects may be modified via a non-const iterator. In some
cases the modification will effect the sort order.

Here's an example:

class Object { // an object from the database };

class Sorter { // functor that determines sort order for Objects };

template <class Obj, class Sort> class Set {};

Set<Object, Sorter> query;
Set<Object, Sorter>::Iterator it(query.begin());
while (it != query.end())
{
it->modify(); // uh oh, Set<> may be invalid now
}

In addition to this basic concept, is there a way to design Set<> so
that it automagically knows when a contained object has been changed
in a way that requires the set to be resorted?

[Ron Natalie]

"Michael Klatt" <md*****@ou.edu> wrote in message news:2c**************************@posting.google.c om...

In addition to this basic concept, is there a way to design Set<> so
that it automagically knows when a contained object has been changed
in a way that requires the set to be resorted?

There's no way to tell. A container can't tell an arbitrary internal object has been
changed. There's nothing that says you can't get a reference or pointer to an
object from an iterator and release, increment, or otherwise destroy the interator.

[David Harmon]

On 18 Jan 2004 15:15:41 -0800 in comp.lang.c++, md*****@ou.edu (Michael
Klatt) was alleged to have written:

I need to design a container similar to a std::set, but where the
stored objects may be modified via a non-const iterator. In some
cases the modification will effect the sort order.

My approach would be to use a std::set, and whenever you modify a stored
object you obtain a copy, erase the stored object, modify the copy, and
insert it back in the set. Encapsulate in a suitable class wrapper.

[lilburne]

Michael Klatt wrote:

I need to design a container similar to a std::set, but where the
stored objects may be modified via a non-const iterator. In some
cases the modification will effect the sort order.

I wouldn't modify the values in a set without first removing
the old item. What if you modify the item to be the same as
some other item? What if the implementation locates items
based on the sort order?

[Jumbo]

"Michael Klatt" <md*****@ou.edu> wrote in message
news:2c**************************@posting.google.c om...

I need to design a container similar to a std::set, but where the
stored objects may be modified via a non-const iterator. In some
cases the modification will effect the sort order.

Here's an example:

class Object { // an object from the database };

class Sorter { // functor that determines sort order for Objects };

template <class Obj, class Sort> class Set {};

Set<Object, Sorter> query;
Set<Object, Sorter>::Iterator it(query.begin());
while (it != query.end())
{
it->modify(); // uh oh, Set<> may be invalid now
}
I'm not sure what you mean by invalidating it. You mean calling it's own
destructor or something drastic ? If so, well yes anything could happen. But
this is not down to bad class design as you can screw up a program anyplace
by deleting an object when your not supposed to.

In addition to this basic concept, is there a way to design Set<> so
that it automagically knows when a contained object has been changed
in a way that requires the set to be resorted?

Depends what you mean by contained object.
Perhaps you mean a Base class or a nested class. Or perhaps simply member
data?
But in general I believe your idea could work.