Re: [boost] Smart Pointers documentation/questions

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-09-16 10:44:22

From: "David Abrahams" <dave_at_[hidden]>
>
> It took some effort to come up with these comments/suggestions. How
> can we ensure that it wasn't wasted? Shall I make edits to the docs
> myself?

The effort is certainly not wasted. I keep all smart_ptr related messages.
If you want to make edits yourself, it will be appreciated, of course.

> > > - scoped_array::operator[] includes the clause ", or if i is less
> > > than 0", which is nonsense since i is std::size_t
> >
> > Documentation bug. i is std::ptrdiff_t to allow the implementation
> > to detect negative indices.
>
> I don't understand from your remarks above whether you intend to fix
> things like this or not.

Yes, I do intend to. I already made some changes, including this one.

> > The italicized/bracketed notes are mostly for my own use, although
> > they might be of interest to others as well. A dedicated "future
> > directions" section simply will not work.
>
> Why not?

Because to keep a separate section in sync requires more effort, and I know
that I'll unavoidably let it decay over time. Fact of life. The notes are
easy enough to maintain so they'll stay reasonably current and relevant.
Without them I tend to use flying pieces of paper that often mysteriously
disappear.

> > > - A parenthesized note mentions "A free function shared_from_this"
> > > which I don't see documented anywhere else. Why "from_this"? Is
> > > there something special about a this pointer in this case? And how
> > > is that different from shared_ptr<T>(x)?
> >
> > shared_from_this is not yet official. It is supposed to be called
> > only from within a member function
>
> Why? What's special about being within a member function?

Nothing in particular; this is simply the intent of shared_from_this, it
solves the specific "how do I obtain a shared_ptr from this" problem.

> > > - I think "use_count_is_zero" is an unintuitive name for that
> > > exception.  IMO it should be something like "no_shared_object" or
> > > "shared_object_deleted"... or something.
> >
> > I've never been good at intuitive naming.
>
> Can we have a discussion of what a good name might be before this gets
> too solid? Or is it already too solid?

I don't mind seeing use_count_is_zero renamed if this is what you ask;
whether the name is "too solid" depends on how many people are already using
it, of course. It's a relatively new feature; perhaps not much code depends
on it yet.

> > I strongly believe that every time the standard uses C++ code to
> > describe effects, someone somewhere misinterprets this as required
> > implementation. I _think_ that reference count updates are not
> > observable behavior even without the note so the implementation is
> > free to optimize, but I think that the note should stay.
>
> You could get the same effect by just adding an explicit "as-if".

Yes, perhaps. As I said, I'm not entirely sure whether an explicit "as-if"
covers the examples, hence the note. To reiterate, the intent is to
explicitly document the possible optimization, so the C++ code is not
misinterpreted as required implementation. I know that you are unlikely to
misinterpret it, but others may/will.

> > Pass by value should be safe. shared_ptr is supposed to be as
> > thread-safe as an int.
>
> I know that it's /supposed/ to be. The question has to do with the
> mechanism for starting threads. I have *no* idea how this stuff works
> in practice, so there may be no worry. However, imagine that it uses
> something like the way I remember fork() works. If I recall correctly,
> when you fork() you may get a second copy of your function using the
> same memory image. If the shared_ptr was passed by-value into the
> function calling fork, there would be a race condition because one
> copy of the function would be trying to destroy the shared_ptr on
> exit, while the other one would be trying to read it.

I think that the scenario you are describing isn't allowed, as threads must
share memory.