Re: [boost] Re: why is operator() not const in random number generators?

From: Jonathan Adamczewski (jadamcze_at_[hidden])
Date: 2003-04-14 20:16:19

> I guess my perception of "logically const" is different. I recall Coplin's
> book (Advanced C++ idioms, pretty old(1996)?)
> where he gives an example of a tree structure. I will use "function" to
> denote functions that compute a value and doesn't change the state of the
> object and "procedure" to denote state changing functions. Coplin mentions a
> function that actually has  a side-effect, it rearranges the internal
> tree structure somehow, but, he claims, the function should be const because
> it's logically const: the client cannot be affected by the
> internal state change.
>
> To me the important thing here is that
> the modification of the internal state will not change the result of *any
> subsequent call* to any function on the object. The next call will
> always be the same random number. Yes, there is a state-change, but it
> cannot be observed.Only procedures can make such changes. Thus the function
> is logically const.
>

In your tree example, the tree may be rearranged, but the results from
subsequent funcion calls (should) stay the same.  This plainly does not apply
to a random number generator - the state does change, the result changes and
the client expects this to be the case - the next result should not be the
same as the last.  This is, as you argue, expected behaviour, and also a
logical state change.  Even in your pregenerated array example - the index
into the array will change between calls.

If you want to use the function(const) and procedure(non-const) ideas of class
design, then an accurate representation of this model might be

struct Some_Random_Number_Generator {
    ...
    void next(); // generate next random number
    result_type operator()() const; // get the current random number
    ...
};

Where every call to operator() results in the same result until next() is
called.  (Actually, operators ++ and * would seem to make some kind of sense
in place of next() and operator() :)

jonathan.