views:

98

answers:

4

Consider the task of writing an indexable class which automatically synchronizes its state with some external data-store (e.g. a file). In order to do this the class would need to be made aware of changes to the indexed value which might occur. Unfortunately the usual approach to overloading operator[] does not allow for this, for example...

Type& operator[](int index)
{
    assert(index >=0 && index < size);
    return state[index];
}

I there any way to distinguish between a value being accessed and a value being modified?

Type a = myIndexable[2]; //Access
myIndexable[3] = a;  //Modification

Both of these cases occur after the function has returned. Is there some other approach to overloading operator[] which would perhaps make more sense?

+1  A: 

in the access example you give you can get a distinction by using a const version:

const Type& operator [] ( int index ) const;

on a sidenote, using size_t as index gets rid of the need for checking if index >= 0

stijn
+7  A: 

You can have (the non-const) operator[] return a proxy object that keeps a reference or pointer to the container, and in which operator= signals the container of the update.

(The idea of using const vs non-const operator[] is a red herring... you may know that you've just given away non-const access to the object, but you don't know if that access is still being used for a read or a write, when that write completes, or have any mechanism for updating the container thereafter.)

Tony
Thank you, I had my doubts about relying on the const version of the operator.
DuncanACoulter
+3  A: 

From the operator[] you can only really tell access.
Even if the external entity uses the non cost version this does not mean that a write will take place rather that it could take place.

As such What you need to do is return an object that can detect modification.
The best way to do this is to wrap the object with a class that overrides the operator=. This wrapper can then inform the store when the object has been updated. You would also want to override the operator Type (cast) so that a const version of the object can be retrieved for read accesses.

Then we could do something like this:

class WriteCheck;
class Store
{
  public:
  Type const& operator[](int index) const
  {
    return state[index];
  } 
  WriteCheck operator[](int index);
  void stateUpdate(int index)
  {
        // Called when a particular index has been updated.
  }
  // Stuff
};

class WriteCheck
{ 
    Store&  store;
    Type&   object;
    int     index;

    public: WriteCheck(Store& s, Type& o, int i): store(s), object(o), index(i) {}

    // When assignment is done assign
    // Then inform the store.
    WriteCheck& operator=(Type const& rhs)
    {
        object = rhs;
        store.stateUpdate(index);
    }

    // Still allow the base object to be read
    // From within this wrapper.
    operator Type const&()
    {
        return object;
    }   
};      

WriteCheck Store::operator[](int index)
{   
    return WriteCheck(*this, state[index], index);
}

An simpler alternative is:
Rather than provide the operator[] you provide a specific set method on the store object and only provide read access through the operator[]

Martin York
Thank you to both you and Tony for excellent answers. I will need to explore your suggestion more fully but I like the idea. With regards to your simpler alternative... I agree however my goal was to provide a fully featured data type so forcing the client programmer to mix operator overloading and mutator member functions did not really appeal to me.
DuncanACoulter
A: 

Return a proxy object which will have:

  • operator=(Type const &) overloaded for writes
  • operator Type() for reads
Tomek