|
Boost : |
From: Beman Dawes (beman_at_[hidden])
Date: 2000-01-12 21:06:00
At 07:45 PM 1/12/00 -0500, Dave Abrahams wrote:
>> * The smart pointer needs to support construction from a raw
pointer
>> when other smart pointers to the same object are known to exist,
but
>> are not available. This means there needs to be a constructor
which
>> increments the reference count rather than just setting it to 1.
>> (This need derives from a really nice cache design which holds raw
>> pointers rather than smart pointers. If smart pointers where
held,
>> the cached pages would never get released.)
>
>That doesn't force us to have an intrusive reference-count (unless I
>misunderstand the meaning of "not available"). What it forces is
some way of
>getting to the count for existing objects which are already being
counted.
>You could store that association in a hash table.
Yes, that would work although it would be a lot of machinery for such
a simple need. Hum. The object could also contain a pointer to the
count. That would be a lot more efficient than looking it up in a
hash table. That still leaves the other problems (smart pointer
size, allocation overhead, and using the wrong allocator) on the
table.
>I have already been in communication with Greg about that
possibility,
>because twice colleagues of mine have made the mistake of
initializing a
>smart_ptr with a raw pointer to an object which is already being
counted.
>One of the engineers was senior.
To avoid that you might design a smart pointer which allocated
objects itself rather than taking in raw pointers from the outside
world. That would eliminate that particular screw-up, although how
it would get the correct constructor arguments I haven't a clue.
Hum. The design I posted supplied two constructors. I had
considered another design that used a single constructor which
incremented (rather than set to one) the reference count. I rejected
that design as slightly less safe since it puts the responsibility
for initially zeroing the reference count on the counted object. But
that design would eliminate the raw pointer screw-up you describe
above. Failure to initialize could be eliminated by in other ways.
Interesting...
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk