[boost] Re: Formal Review request: Pointer Container Library

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2003-12-29 10:49:46

"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
news:bsoqf3$gdb$1_at_sea.gmane.org...
>
> "Jonathan Turkanis" <technews_at_[hidden]> wrote in message
> news:bsoika$7cs$1_at_sea.gmane.org...
> > "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
>
> >You could also
> > provide some tests demonstrating (2), perhaps by using allocators or
> cloning
> > functions which intentionally throw exceptions under certain
> circumstances.
>
> Well, the safety lies in the implementation. I'm not saying that you can't
> do it your-self, starting
> from eg. std::vector<T*>, but it is a considerable work to do so. And
many,
> even experienced people,
>  just forget those exception concerns. Did I understand correctly? Or do
you
> want to know how the wrong implementation
> looks like?
>

I'm not sure I follow you here. I was just suggesting that you could
demonstrate the exception safety of your implementation by arranging for
some exceptions to be thrown, as a test, and inspecting the state of the
containers afterward.  I am aware of the difficulty of writing
exception-safe code using containers of raw pointers.

> I have an idea which I have not thought through fully, but I will mention
it
> anyway. As long as you are going to the trouble of providing a new family
of
> containers, it should be possible to give the benefits of (3) to users who
> have independent reasons to use containers of smart pointers, while still
> allowing (1) and (2) for users who are willing to use containers of raw
> pointers. This could be done by providing an extra template parameter for
a
> smart pointer type meeting certain minimum requirements. If the parameter
is
> left unspecified, the resulting containers would behave exactly as you
have
> documented. If a smart pointer type is provided, the result will be a
> container of smart pointers which provides the convenient access you have
> described.
>
> What would the reason be for that? I'd like to see a motivating example.
>

Perhaps the benefits are not worth the costs of implementation or the cost
of explaining the interface. What I mean is this: sometimes you do not want
the container to manage the lifetime of your objects -- perhaps they occur
in several containers at once -- but you could still benefit from the
syntactic conveniences you describe, such as having built-in derefencing
iterators.

>
> I think we need to see some use for this. I cannot forsee how much it will
> complicate
> the implementation. There is also the concern about how the interface
should
> be changed
> to allow sharing of the pointers to work (I assume that is still wanted).
>

I expect that in some cases it might double the size of the implementation,
since there will be essentially two independent implementations under the
hood. So I can see why you would not find this appealing. And I am not sure
exactly what interface changes  would be requires (as I said I had not the
idea through fully.) The main idea is this: introducing a new family of
containers is a major undertaking, not just for the implementor, but for
users. The library should be as comprehensive as it reasonably can be. One
of the major rationales of the library is (3), which applies in a broader
range of situations than addressed by the library. So if the library can be
extended to cover the the other cases, other things being equal, it should
be.

It's just an idea. :)

Jonathan