Boost logo

Boost :

From: Kevlin Henney (Kevlin.Henney_at_[hidden])
Date: 1999-07-13 02:01:39

I was discussing this recently w/ someone, and the idea that failed count
automatically leads to deallocation of the given object may not always be
desirable (on failure the user may have other plans for the object). Lazy
failure may be more desirable and, for detached counts, may be achieved in
one of two ways:

   1. Use of a null count to indicate 0. I tend not to like this option as
   it leads to too much conditional code for a common case. It also uses up
   the null bandwidth, which I tend to reserve for "not counted", ie
   passing a non-counted object into a function that accepts only a counted
   ptr; w/ a null counter the smart pointer acts as an adaptor for its own
   type. Should we consider this for shared_ptr? Eg

     T t;
     shared_ptr<T> p(&t, nocount);

   2. Using a shared static count of 1, which primarily has the effect of
   reducing the cost of allocation where objects do not end up being

Reid Sweatman <reids_at_[hidden]> on 13/07/99 00:44:48

Please respond to boost_at_[hidden]

To: "'boost_at_[hidden]'" <boost_at_[hidden]>
cc: (bcc: Kevlin Henney/QA Training Ltd)
Subject: [boost] Re: Misc library documentation issues

> >Let me ask for a clarification here. When you say bad_alloc
> throws delete
> >the user's type, you mean the type that failed of
> allocation, don't you?
> No. If allocation fails, the type being allocated never
> exists, and so
> there is no need to delete it. What gets deleted is the user's type
> that is being reference counted, since if the reference count cannot
> be allocated, it essentially falls to 0.

Ah. I hadn't realized we were talking specifically about reference-counted
objects. I thought it was a statement about the behavior of bad_alloc in
general that I'd never heard of. Never mind.

Apply for a NextCard credit card: Save Money with a low intro rate and
no annual fee. Make Shopping Easy with Safe Shopping Guarantees, 1 Click
Shopping and Double Rewards. home: - Simplifying group communications

------------------------------------------------------------------------ home: - Simplifying group communications

Boost list run by bdawes at, gregod at, cpdaniel at, john at