Boost logo

Boost :

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-12-21 15:31:23


----- Original Message -----
From: Ed Brey <edbrey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, December 21, 2001 4:17 PM
Subject: Re: [boost] BCB5, the pimpl idiom bug and the new Unit Test
Framework

> From: "Peter Dimov" <pdimov_at_[hidden]>
>
> > From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> > > On second thought, this conclusion leads me back to my original
proposal:
> > > use the technique of grin_ptr<> with
> > > scoped_ptr<>.
> > >
> > > It doesn't make sense to change scoped_ptr<> though,
> >
> > [...]
> >
> > On second thought, this actually makes sense to me. Scoped_ptr
requirements
> > will change slightly, in that it will require a complete type only when
its
> > constructor is instantiated.
> >
> > sizeof(scoped_ptr) will increase, but since scoped_ptr is noncopyable,
this
> > will not have much impact (it's not meant to be put in containers.)
>
> Not so fast. Containers don't directly contain scoped_ptrs, but they can
contain them indirectly (e.g. contain pointers to objects that house them).
It is not uncommon to have lots of a smallish, noncopyable class that would
use scoped_ptr. Even given heap overhead, increasing the size of scoped_ptr
can make a big difference in overall memory used.
>
> Consider a specific use case for scoped_ptr: When you have a class that
needs an object only during certain times in its life. That object is
created and destroyed as needed, managed by the class using a scoped_ptr.
The whole point here is to keep memory allocation low when the object does
not exist - a purpose that a big scoped_ptr would defeat.
>
Sure, but, +4 bytes is a "big" scoped_ptr?

> Scoped_ptr is a basic, foundational class. I can't think of a class for
which it is more important to only pay for what you need.
>

There is no doubt that you should only pay for what you get.

The proposed scoped_ptr<> is more flexible w.r.t incomplete types than the
current one.

This not only allows developers to use scoped_ptr<> for *portable* pimpl
implementations, but also allows
any other usage with incomplete types not to require a separate destructor.
In many cases you need to define the destructor of the holder class just to
be able to hide it from the compiler on certain translation units.

So the question is if the extra flexibility is worth the extra memory
footprint.

A different argument would be that a given application *relies* on
sizeof(scoped_ptr<T>)==sizeof(T*), but I don't think there's such
application.

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk