RFC: testing container variants

[Benjamin Kosnik]

This patch finishes off the work started here:
http://gcc.gnu.org/ml/libstdc++/2009-05/msg00127.html

With this, all test logic is abstracted from the instantiating type and
available to be used by both std::list and ext::list. There is no
functional difference or change in reported test results.

The move from self-standing test files to combined header + source is
new for libstdc++, although certainly a lot of testsuite logic is in
testsuite/util already so I don't think this is a massive departure. If
there are objections or comments I'd like to hear them. 

This seems like a workable design. An alternate approach was more
meta-programming inspired and just slammed typelists of std::list
and variant-types into the 23_container/list harness and test cases. I
judged this approach lacking, as:

1) harder to separate out the deps for individual containers.
2) requires just as much modification.
3) added complexity of dispatch machinery. 

I'm certainly willing to entertain other proposals, and show how this
is used in a non-theoretical sense. 

The plan is to use this approach for the rest of the standard
container types. But to convert the containers to this approach such
that this is a full transition.

Then, ext/vstring could re-use large parts of std::string (Paolo, your
thoughts appreciated), the map/set optimizations that Janis/Michael
could be integrated and tested in a separate container type, an
alternate container implementations for C++0x or that use C++0x atomics
can be more prototyped and tested fully without duplication. In
addition, I'm hoping to use these kinds of techniques in C++0x atomics
testing for shared memory.

-benjamin





-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20090611-1.patch.bz2
Type: application/x-bzip
Size: 11590 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20090611/161b78da/attachment.bin>