[boost] Re: Misc library documentation issues

From: Reid Sweatman (reids_at_[hidden])
Date: 1999-07-13 12:25:26

I definitely agree with this one.  I'm currently debugging a cache manager
that tracks objects via more than one lookup system, and that's precisely
why I'm *not* using smart_ptr or auto_ptr (don't have time to roll my own
right now, so I try to avoid the necessity of pointers altogether, although
that makes the API potentially unsafe for anyone using it who isn't aware of
the internals of the cache...and what was that about a new section on good
programming practices? <BG>).

> -----Original Message-----
> From: Kevlin Henney [mailto:Kevlin.Henney_at_[hidden]]
> Sent: Tuesday, July 13, 1999 12:02 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Misc library documentation issues
> 
> 
> 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
>    shared.
> 
> 
> 
> 
> 
> 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. http://clickhere.egroups.com/click/448
> 
> 
> eGroups.com home: http://www.egroups.com/group/boost
> http://www.egroups.com - Simplifying group communications
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Get in on the new revolution.  The only democratic web community.
> Free email.  Free webspace at FortuneCity.com.
> http://clickhere.egroups.com/click/365
> 
> 
> 
> eGroups.com home: http://www.egroups.com/group/boost
> http://www.egroups.com - Simplifying group communications
> 
> 
> 
> 

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications