|
Boost : |
From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-04-14 18:50:51
"Powell, Gary" <powellg_at_[hidden]> wrote in message
news:07C3294415745F4D9BA4B06B89556FCA04A5AFCD_at_ex-mail-04.ant.amazon.com...
> Because it logically isn't const. You know that the engine is going to
modify its result the next time you call it. Mutable IMO is for things which
are at least
> logically const, if not actually so.
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.
For the client a random number generator is just a black box that returns
some numbers. The client doesn't care
if there is an internal state change or if all the random sumbers are
precalculated in some húge array (bad example :-), but then there wouldn't
be any state change). The client just uses it to get some numbers.
Now my question is what benefit does the client have of the random number
generator to be non-const? After all, it will only
mean he will often have to put mutable in front of his random number
generater object. Also note the difference from std::rand()
which can be called without problems from a function.
Are we not making it harder for clients of the library? I think so.
best regards
Thorsten
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk