RE: [boost] Re: Proposal: statefull objects

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-29 12:59:25

----- Original Message -----
From: Rainer Deyke <root_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, August 29, 2001 2:24 PM
Subject: Re: [boost] Re: Proposal: statefull objects

> It seems to me that 'optional<T>' is in many ways similar to
> 'scoped_ptr<T>':
>
>  - Both are either null or contain a single object of type 'T'.
>  - Both are conceptually pointers to the contained object.
>
Actually, scoped_ptr<T> containes a pointer to an object of type T.
This difference is fundamentally important because the user of scoped_ptr<T>
is so much aware of this that it has to allocate the object himself before
wrapping.

In other words, optional<T> wraps values, while scoped_ptr<T> wraps
pointers.
Even though the usage of both is quite similar, because they both have
pointer semantics, they are intended for completely different problems.

> Differences:
>
>  - 'scoped_ptr<T>' can contain an object of a derived type; 'optional<T>'
> cannot.
This in inherent in the fact that scoped_ptr wraps a pointer but optional<>
wraps a value.
I'm not sure if downcasting a value (instead of downcasting a pointer) has
proper meaning.

>  - 'scoped_ptr<T>' keeps the contained object on the heap; 'optional<T>'
> keeps it stores it directly.
>  - 'scoped_ptr<T>' is initialized with an object that is already created
on
> the heap.  This does not make sense for 'optional<T>'.
>
> Given those similarities, I think it makes sense for the interface of
> 'optional<T>' to resemble the interface of 'scoped_ptr<T>' as closely as
> possible.
> If a user of 'optional<T>' later needs to be able to contain
> objects of derived types, switching to 'scoped_ptr<T>' should take a
minimal
> amount of effort.
> The same applies when a user of 'scoped_ptr<T>' who does
> not need to contain objects of derived types and wants the greater
> performance of 'optional<T>'.
>
I don't think this could actually be done.
You use scoped_ptr<> to manage the lifetime of objects that you create and
access by means of a pointer. You use optional<> to wrap values -not
pointers- which might be uninitialized. The pointer semantic of optional<>
is there only to allow the possibly uninitialized state to be properly
managed.

In other words, IMO, it would never make sense to switch from optional<> to
scoped_ptr<> (or any smart pointer).

Anyway, you presented an idea that I've never thought before, so I'll think
about it futher.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com