Re: [boost] Re: Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-10 13:57:30

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Tuesday, December 10, 2002 3:21 PM
Subject: Re: [boost] Re: Formal review: Optional library

> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
> > I don't know of 'standard' examples, but in my code I do that a lot:
> >
> > class curve
> > {
> >   shared_ptr<polygon> acquire_approx() const { return m_approx ; }
> >   shared_ptr<polygon> m_approx ;
> > } ;
>
> But this is not a get(). It is an acquire_approx(). :-)
>
> I think that most programmers are familiar with get() and would expect the
> returned pointer to be invalidated by the first mutating operation. I
don't
> see what are you trying to achieve with peek().
>
I try to achieve the notion that the returned pointer is invalidated after
the first mutating operation :-)

Are you sure this is interpreted this way by most programmers familiar with
get()?

If you are, and others support your view, I have no problem changing peek()
for get().

I've seen so many people doing nasty things to pointers obtained via get()
that I figured that the name peek() would communicate more strongly that the
object is still leaving inside some other place.

But this is a minor point really, if most of you like get() better, let it
be get().

Fernando Cacciola