Const and non-const access resolves to different overloads?

Question

Let me say we have a simple programming task. But for the sake of clarity I start with few code samples. First of all we written a some kind of data container class but for the purposes of task no matter what the class is. We just need it to behave const-correct.

class DataComponent {
public:
    const std::string& getCaption() const {
        return caption;
    }

    void setCaption(const std::string& s) {
        caption = s;
    }

private:
    std::string caption;
};

Then let us assume we've got a generic class that behaves like facade over arbitrary incapsulated class instance. Say we overloaded member access operator (->).

template <typename T> class Component {
public:
    Component() { instance = new T(); }

    ...

    const T* operator-> () const {
        return instance;
    }

    T* operator-> () {
        // but there might be additional magic
        return instance;
    }

private:
    T *instance;
};

At this point I should say how I want this to work:

• if we're calling non-const member functions of underlying class through member access operator (component->setCaption("foo")) compilier treats non-const T* operator-> () as the best choice.
• otherwise if we are trying to call const member functions of underlying class same way (component->getCaption()) compiliers selects const T* operator-> () const on the other hand.

This code sample above won't work this way so I'm curious about possibility to give compiler a behavior like that I have mentioned. Any propositions.

---

EDIT: Let our member access operator overloaded this way:

    const T* operator-> () const { return instance; }

    T* operator-> () {
        cout << "something going change" << endl;
        return instance;
    }

And let us have a variable Component<DataComponent> c somewhere. Then on the call to c->getCaption() stdout should remain silent but on the call to c->setCaption("foo") stdout should warn us that something is going to change. VS 2010 compilier makes stdout warn us on each of these calls.

I understand that such semantics suppose that c behaves as const and non-const at the same time. But curiousity is still in my mind.

Answer 1

Whether a const or non-const member is invoked is determined purely by the constness of the object on which it is invoked, not by some subsequent operation. That determination is made before any consideration of the particular method you're invoking in DataComponent. You could still hack up the required functionality less directly using proxy object around DataComponent, with both const and non-const forwarding getCaption()s.

EDIT: details as requested (off the top of my head). You'll need to forward declare some of this stuff - I didn't bother as it makes it even more confusing. Do chip in with any concerns / feedback. Note that this basically assumes you can't / don't want to modify Component for some reason, but it's not a generic templated solution that can simply be wrapped around any arbitrary type - it's very heavily coupled and has a high maintenance burden.

// know they can't call a non-const operation on T, so this is ok...
const T* Component::operator->() const { return instance; }

// they might invoke a non-const operation on T, so...
DataComponent::Proxy Component::operator->() { return DataComponent.getProxy(*this); }

in class DataComponent:

struct Proxy
{
    Component& c_;
    DataComponent& d_;

    Proxy(Component& c, DataComponent& d) : c_(c), d_(d) { }

    const std::string& get_caption() const { return d_.get_caption(); }

    void set_caption(const std::string& s)
    {
        c_.on_pre_mutator(d_);
        d_.set_caption(s);
        c_.on_post_mutator(d_);
    }
};

then

DataComponent::Proxy DataComponent::getProxy(Component& c) { return Proxy(c, *this); }

So, this means somewhere you have to hand-code forwarding functions. It's a pain, but if you're doing this for debugging or testing it's not unreasonable. If you're doing this so you can add a lock or something, then there are probably better alternatives.