Re: Can't create list members if base type doesn't copy-construct?

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

2009/7/28 John Gilmore:
>
> I found that memory allocation was opaque to me when using C++ and
> libstdc++. ?Eventually I stumbled on -Weffc++ which helped a lot.
> Then I discovered making operator= and the copy-constructor private,
> which meant the compiler would tell me anytime a class got copied
> behind my back.
>
> I had just about eliminated all the copying from my code. ?Then I
> discovered that when my class had no public copy-constructor, I
> couldn't find any way to make an STL list out of it!

Yes, the standard containers are value-based by design, and container
parameters are generally required to be copyable and assignable.

The next version of C++ improves the standard containers with better
support for constructing elements in-place, as per
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf
Many operations now only require the parameters to be moveable rather
than copyable.  If you are only starting out with C++ recently, that
may not be of much much help today, or even make much sense. See
http://www.artima.com/cppsource/rvalue.html for an introduction.

> It's opaque (i.e. undocumented) that when you make a list of type X,

You might find the docs at http://www.sgi.com/tech/stl/ useful.  The
requirements on types are clearly specified, and the STL is very
intentionally designed around specific, well-defined concepts (such as
DefaultConstructible) and relies on the minimum set of operations
guaranteed to be valid for types that model those concepts.  It just
happens that copying is one of the fundamental operations needed in
many places.

> (yes, this is a Microsoft manual. ?Of course I wasn't reading the &%*@
> proprietary C++ standards document that isn't available online -- and
> of course I wasn't using the nonexistent GNU libstdc++
> user's-as-opposed-to-hacker's manual -- so I was scraping by with
> whatever random C++ standard library documentation exists on the Web.
> Microsoft's happened to be one of the ones I found.)

I use the SGI docs above and the ones at http://www.dinkumware.com/manuals.

Patches to improve the doxygen comments in the libstdc++ code are welcome :-)

Rather than hacking the standard library code you might be interested
in Boost.Intrusive
http://www.boost.org/doc/libs/1_39_0/doc/html/intrusive.html

The reason the standard containers are not designed that way is that
"copyable" is a more fundamental concept than "has exactly the right
members and interface required to be used with a specific intrusive
container" :-)

Bear in mind that the STL is really a set of rules and design idioms,
the standard containers are only examples of STL-compatible
containers, and are certainly not appropriate for all needs.  The STL
defines the interface and some example implementations, it doesn't
provide every conceivable implementation.

Boost.Intrusive is a set of STL-compatible containers that suit some
needs better, while still being compatible with the algorithms in the
standard library, and countless other STL-compatible algorithms
outside the STL.

Jonathan