|
Boost : |
From: Matthias Troyer (troyer_at_[hidden])
Date: 2003-04-16 10:57:34
On Wednesday, April 16, 2003, at 04:25 PM, Thorsten Ottosen wrote:
> ----- Original Message -----
> From: "Matthias Troyer" <troyer_at_[hidden]>
>> On Tuesday, April 15, 2003, at 05:39 PM, Thorsten Ottosen wrote:
> [snip]
>>> 2) After all, a client don't care what random number he gets, only
>>> that he
>>> gets one. The right result of a call to rand() is not that it is a
>>> particular random number, but that it's a random number. If the order
>>> of the
>>> sequence is important, that is still achievable if operator() is
>>> const, it
>>> is just not enforced by the compiler.
>>
>> Here I disagree. I actually do care very much about what number I get.
>> There are several application where it is of essential importance to
>> get the identical sequence again. I thus want to have control over
>> where the internal state of the generator is changed - and that's
>> where
>> const comes in.
>
> you still have control, but the compiler doesn't. The compiler cannot
> warn
> you if you
> use the random number generator somewhere else. But the same situation
> arises if I declare
> my variable mutable. Thus the only effect I get from a non-const
> operator is
> that I need to prefix my member variable
> with mutable. (This issue would disappear if I make a local variable
> instead
> of a member variable, though)
The compiler can warn me. If I pass a const generator to some function
then the function can only make a local copy of the generator and use
that, but leaves the original one intact. That way I can make sure that
the state of the generator is not changed.
>>> 3) so (as seen from the client in 99% of the time) what is really the
>>> benefit of having a non-const operator() .?
>>
>> et me ask differently: what is the benefit of making it const?
>
> no mutable.
I never not needed mutable yet in any code of mine using random number
generators. Could you give an example that shows where it is needed?
Matthias
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk