From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-29 12:59:25
----- Original Message -----
From: Rainer Deyke <root_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
> - 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
In other words, optional<T> wraps values, while scoped_ptr<T> wraps
Even though the usage of both is quite similar, because they both have
pointer semantics, they are intended for completely different problems.
> - 'scoped_ptr<T>' can contain an object of a derived type; 'optional<T>'
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
> - '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
> 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
> 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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk