|
Boost : |
From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-09-01 12:57:40
Mat Marcus <mmarcus-boost_at_[hidden]> wrote in message
news:3616660.1062290079@[192.168.1.103]...
> In this post I will put forward a use-case or two to help see whether
> something a little different then the current version of optional
> might be useful. I also begin making a case that a Concept like
> PossiblyUninitializedVariable might be more generally useful than
> OptionalPointee.
>
> [snip use case]
>
FWIW, your use case of pretty common to me.
I've used optional<> precisely as you did many times.
In fact, I often found mayself adding optional<> to a local
variable just because the flow changed and now the variable
may reach a point being uninitialized.
> After reading the documentation more carefully I learned that optional
> models pointer behavior. I spelled out how the code might look:
>
> boost::tie(*begin, *end); file://sorry, ASSERT && looks too strange
>
> Wow, that looked strange to me. I don't think of begin and end as
> pointers at all here.
>
Right, they're not pointers and you shouldn't see them as such.
I think that your report is very important because it shows me
that while one may expect the need for special constructs in order
to 'access' an optional value, such need isn't there when one
wants to initialize or assign an optional.
It was very reasonable to expect optional<> to work with tie as
that is just assignment and assignment is always defined.
>I just want to model values that haven't been
> initialized, and I maintain that initialized/unintialized is the
> concept worth modeling (I'm not sure what its name ought to be, so for
> now I'll just refer to it as the PossiblyUninitialized Concept).
I agree here.
> Such
> a concept might perhpaps embody notions of initialization via
> construction or assignment, testing whether the model has been
> initialized, etc.
Right.
> It may (or may not) also be true that there is some
> use in thinking of pointer/NULL as model of PossiblyUnintialized
> variables, but seems to me that the current version of optional has it
> backwards: I don't want to model all cases of possibly unininitialized
> behavior as OptionalPointees.
>
I think that OptionalPointee's documentation failed its purpose.
That concept is intended to be exactly what you proposed,
except that I left initialization/assignment aside.
The concept just explains that the operator * and -> syntax
is used to access the a value that is possibly uninitialized,
WITHOUT implying that a model of this concept IS a pointer.
The concept was invented precisely to allow the same
syntax to be used with entities that are NOT pointers.
The particular choice of operators is to allow pointers to be
models of the concept.
Perhaps it is the name which is misleading. It can be renamed as
PossiblyUninitialized if that helps.
And it should incorporate initialization and assignment.
Anyway, both concepts are 'conceptually' the same.
Fernando Cacciola
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk