Does internal state “leak” when it influences externally-visible behavior?

Question

I have a method (in C++) which generates a value based on a parameter and the parameters from previous calls. Calling it more than once with the same parameter may generate different values each time. For example:

public:

    int getValue(const int param)
    {
        int value = param ^ previousParam;
        previousParam = param;
        return value;
    }

private:

    int previousParam;

Does it make sense to allow this method to be called on const objects? Is previousParam part of the object's internal state, or does it "leak" since the internal state affects the object's external behavior?

I think of this method like a generator that just creates a series of values on subsequent calls, rather than a method which modifies the object. The caller is not supposed to depend on a particular parameter generating a specific value. Would it be sensible to change the declarations to the following?

int getValue(const int param) const;
mutable int previousParam;

Answer 1

Some good answers here already, but I think there is something more to say about your "mental model" of the object, since you wrote

I think of this method like a generator that just creates a series of values on subsequent calls, rather than a method which modifies the object.

But since previousParam is a member of your object, the method actually does modify the object. However, in your mental model, previousParam seems not to be part of the object. So I guess your real problem is that the whole getValue method including the previousParam member is misplaced - it should probably be part of a different class, which provides an abstraction for your generator, and where getValue is naturally a non-const method.

Answer 2

const only "guarantees" that an object's members don't change. Nothing stops you from making const methods that depend on mutable state outside of the object (e.g. a global variable). However, most people expect const to mean that the object's state won't change when you call const methods on it. Since you're not supposed to know about an object's members, and since you can cheat with the mutable keyword, its state is effectively what it returns from its methods. Thus a const method that changes what the object returns in future calls will definitely surprise people.

If you want a "generator" that returns a sequence of values, then return a different non-const object (preferably an iterator) that contains your original object's state.

Answer 3

There are three good reasons to not make getValue const.

1. Principle of least astonishment - I would find it very, very surprising to discover that a const method caused an externally visible change in the behavior of the object (even if I'm not supposed to depend on a particular parameter generating a specific value).
2. Logical versus physical const - There's some discussion as to whether const should indicate logically constant (no change in the visible state or behavior) or physically constant (bitwise identical). getValue is obviously not physically const, and since the visible behavior changes, it's hard to see how you could make a case for logical const (even if callers aren't supposed to depend on a particular parameter generating a specific value).
3. const in C++11 - C++11 has tightened the semantics of const to mean, approximately, "usable in a thread-safe fashion." (This is an oversimplification; see here, here, and here for details and discussion.) getValue isn't thread-safe and so isn't be const in the sense C++11 expects const to mean. (Whether you need to comply with this C++11 meaning of const depends on your application.)

Answer 4

I think that depends on the semantics of the object.

If it is a random number generator or similar, RandGen say, then what would it mean for a RandGen object to be const? Is the object usable at all if it were const?

For example, you might have a member method to set the seed, which I would consider should be non-const. Then it might make sense for getValue to be const:

void setSeed(long seed);

Another example might be a function which accepts a RandGen object and checks whether its internal param is "sufficiently random". We likely do not want isSufficientlyRandom to call getValue, and so getValue might be non-const here:

bool isSufficientlyRandom(const RandGen& randGen) {
    return randGen.getPreviousParam() > 17; 
}