是否可以仅为const操作指定一个私有成员变量public？

Question

I have a member variable, enabled_m , whose value is dependent on a number of variables. Since these invariants should be maintained by the class, I want it to be private :

class foo_t
{
public:
    void set_this(...); // may affect enabled_m
    void set_that(...); // may affect enabled_m
    void set_the_other_thing(...); // may affect enabled_m

    bool is_enabled() const { return enabled_m; }

private:
    bool enabled_m;
};

Which works, but really my intent is to require a user of foo_t to go through the class to modify enabled_m . If the user wants to just read enabled_m , that should be an allowable operation:

bool my_enabled = foo.enabled_m; // OK
foo.enabled_m = my_enabled; // Error: enabled_m is private

Is there a way to make enabled_m public for const operations and private for non- const operations, all without having to require a user go through accessor routines?

Answer 1

Most engineers will prefer that you use accessor methods, but if you really want a hack-around, you could do something like this:

class AccessControl
{
private:
    int dontModifyMeBro;
public:
    const int& rDontModifyMeBro;
    AccessControl(int theInt): dontModifyMeBro(theInt), rDontModifyMeBro(dontModifyMeBro)
    {}

    // The default copy constructor would give a reference to the wrong variable.
    // Either delete it, or provide a correct version.
    AccessControl(AccessControl const & other): 
        dontModifyMeBro(other.rDontModifyMeBro), 
        rDontModifyMeBro(dontModifyMeBro)
    {}

    // The reference member deletes the default assignment operator.
    // Either leave it deleted, or provide a correct version.
    AccessControl & operator=(AccessControl const & other) {
        dontModifyMeBro = other.dontModifyMeBro;
    }
};

Answer 2

No, there's no way to restrict modification only to members. private restricts all access to the name; const prevents modification everywhere.

There are some grotesque alternatives (like a const reference, or use of const_cast ), but the accessor function is the simplest and most idiomatic way to do this. If it's inline, as in your example, then its use should be as efficient as direct access.

Answer 3

A great deal here depends upon the intent behind exposing the enabled state, but my general advice would be to avoid exposing it at all .

The usual use of your is_enabled would be something like:

if (f.is_enabled())
    f.set_this(whatever);

In my opinion, it's nearly always better to just call the set_this , and (if the client cares) have it return a value to indicate whether that succeeded, so the client code becomes something like:

if (!f.set_this(whatever))
   // deal with error

Although this may seem like a trivial difference when you start to do multi-threaded programming (for one major example) the difference becomes absolutely critical. In particular, the first code that tests the enabled state, then attempts to set the value is subject to a race condition--the enabled state may change between the call to is_enabled and the call to set_this .

To make a long story short, this is usually a poor design. Just don't do it.