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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-12-29 04:00:07

"Jonathan Turkanis" <technews_at_[hidden]> wrote in message
news:bsoika$7cs$1_at_sea.gmane.org...
> "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message

> <snip>
>
> > Performance is not the only reason for using them (and as I said, it all
> > depends on your app). It's just more convenient
> > to read your program, it gives a clean feel of OO. I can image quite a
few
> > beginners strugling with C++ syntax and
> > having a bit funny syntax just adds to that. For me it matters to...I
> would
> > like to focus on the program, not the syntax.
>
> Broadly speaking, you seem to be offering three justifications for
> introducing ptr_containers:
>
>     (1) Performance (compared to containers of smart pointers)
>     (2) Safety (compared to containers of raw pointers)
>     (3) Simplicity/Elegance/Convenience
>
> (1) and (2) seem quite plausible. As others have mentioned, your case for
> (1) could be strengthened by including some empirical data.

The smart pointer timings page include that. So does NTL's bnchmarks. I've
added links for that in
the current docs.

>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 am slightly suspicious about (3), mostly because of the member functions
> relating to transfer of ownership, such as the constructors taking
> auto_ptrs, and the clone, release and transfer members. I don't mean to
> imply that these functions are not necessary or useful; I am just not
> convinced that the new interface will make a beginner's life any easier,

The transfer of ownership stuff is provided so the user need not fiddle with
naked pointers. IMO, it does make it easier to avoid a leak with these.
As for clone() and release() (of the entire container), it makes sense since
deep-copying can useful, but sometimes extreamely expensive.

Consider the alternative, that operator= deep-copies *or* shallow-copies
and then we need one other member function, either release() or clone().
(and we do really need one of those because sometimes cloning the whole lot
is too slow and sometimes it is necessary)
I find it better to be more explicit about you actions, so I have forced the
user to
choose between the two. An operator= is not self-documenting.

> particularly becuase she will also be learning the interfaces for the
> standard containers at the same time.

well, most of the interface will be the same and feel the same, so
hopefully, it
will be fairly familiar.

> For experienced users, however, the examples you give are very appealing.
I
> think I would probably use your containers in preference to containers of
> raw pointers.

Good :-)

> 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.

What would the reason be for that? I'd like to see a motivating example.

[snip]
>     template< typename T,
>               typename Alloc = std::allocator< shared_ptr<T> > >
>     class shared_ptr_vector
>         : public basic_ptr_vector< shared_ptr_vector<T, Alloc>, T, Alloc,
> shared_ptr<T> >
>         { };
>
> You could provided the ptr_ and shared_ptr_ version, and allow users to
> define their own container types using other smart pointers.
>
> Of course, the member functions dealing with transfer of ownership would
be
> unnecessary,

I certainly needed deep-copies in the past even though I have used
shared_ptrs.

> but I think they could still be given reasonable semantics.
> Alternatively, they could be disabled if a smart pointer type is provided.
> Also, in the smart pointer case,  ordinary copy constructors and
assignment
> operators could be provided.

with what semantics?

> What do you think?

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).

best regards

Thorsten