From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2003-09-02 21:01:52
Mat Marcus <mmarcus-boost_at_[hidden]> wrote in message news:firstname.lastname@example.org...
> Here's a question that tries to get to the crux of the pointer-like
> interface matter. Should T* and optional<T> both be models of a
> pointer-like syntactic concept?
pointers, iterators and optional<T> are indeed models of the OptionalPointee
syntatic concept, yes.
But this concept is not about pointer semantics such as
aliasing or shallow copy, it is about the possibly undefined behaviour
implied in expressions that take the form (*o) and o->.
> I imagine that those who would answer yes do so because they may want
> to write generic code that uniformly handles pointers and possibly
> uninitialized variables.
No, this is not the intention.
The purpose of the model is to leverage to syntatic aid that warns
about the implied possibly UB of the expressions covered by the concept.
> Those who answer no to the above question may
> prefer to write code that uniformly handles T and optional<T>.
I doubt such uniformity can be implemented smoothly.
> As you know, my (current) answer is no. There may be a third group who want
> both. The problem is that I find that the pointer-like interface is
> distracting, but that may be because I'm unfamiliar with the use-cases
> where you might want to handle T*'s and optional<T>'s uniformly or
> even replace raw pointers with optional<T>'s, since pointers also
> bring allocation issues with them. Instead I have been mainly focused
> on replacing T's with optional<T>'s.
Being able to replace T's with optional<T>'s is indeed a reasonable goal.
I did it myself quite a few times.
But I don't see how this can be made as smoothly as you wish though.
> This is why I gravitate towards
> having an optional that models a syntactic concept such as PU that
> makes no mention of pointer-like syntax.
> By the way, I would also like to thank you for your work on optional
> and your contributions to boost. I also appreciate your open
> discussion of the design of optional and optional-like classes.
> My posts are just those of a potential user who is interested in finding
> the right point in the design space for my needs. If my use cases or
> arguments prove useful to others or if optional is influenced to meet
> more of my needs, then of course I will be pleased. If not, I'm still
> learning about the design space from you and others on this list, so I
> benefit either way.
So do I.
I've already planned important fixes thanks to you, Joel and Dave G.!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk