From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-02-13 05:34:10
David Abrahams wrote:
>>
>> That's not exactly true. States are _types_ only at compile-time. At
>> runtime, they are objects passed to correspondent call operator.
>> Objects may be stateful.
>>
>> struct Running { /* stateful */ };
>> struct Stopped { /* stateful */ };
>
> Even more confusing; now you need a dynamic allocation to represent
> and change the current state of the machine. I suppose you could use
> variant, but I never understood why people want to put state _inside_
> of states --
You very often encounter the situation that you need a variable that is
only used in a part of a state machine (i.e. only one state or a few
states need access to it). IMO, it is good design to confine the
lifetime of such a variable so that it will not even exist when the
machine does not happen to reside in the states that need access to the
variable. Even for a very tiny state machine like the StopWatch in my
tutorial it made sense to limit the lifetime of one variable. See
http://tinyurl.com/5q9hk (State-local storage) for details.
> it doesn't match up with the domain abstraction of state
> machines.
How do you come to that conclusion?
> The state's identity should be enough.
It is sometimes enough for small simple machines but not almost never
for large complex ones.
Regards,
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.