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

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2003-12-29 01:55:28

"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
news:bsakt0$6r6$1_at_sea.gmane.org...
> "Jeff Flinn" <TriumphSprint2000_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. You could also
provide some tests demonstrating (2), perhaps by using allocators or cloning
functions which intentionally throw exceptions under certain circumstances.

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,
particularly becuase she will also be learning the interfaces for the
standard containers at the same time.

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.

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.

It might look like this (for vectors):

A. Most general template:

    template< typename Self,
              typename T,
              typename Alloc,
              typename SmartPtr = void_ >
    class basic_ptr_vector { };

B. Pointer container:

    template< typename T,
              typename Alloc = std::allocator<T*> >
    class ptr_vector
        : public basic_ptr_vector< ptr_vector<T, Alloc>, T, Alloc >
        { };

    // Same as current ptr_vector

C. Smart pointer container.

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

What do you think?

Jonathan