Anton Pevtsov wrote:
Martin, I suggest to move the common to all range overlodas for
different methods code to the 21.strings.h
I think we may have RangeBase class with begin methods and virtual
operator ().
Here are the changes to the tests which use this approach:
http://people.apache.org/~antonp/stdcxx06072006/
I agree, it's a good idea to move the base class to a common
header. The only thing that needs to change if we do that is
that we will either need #include <string> in that header to
bring in the declaration of basic_string, or replace it with
just String. I.e., change RangeBase to
template <class String>
struct RangeBase {
...
};
I think this would be an overall improvement to the class so
with the change above please go ahead and commit.
The rest of the code in classes which exrcise range methods look similar
too. So it is possible to join them and use the func_id to determine
which of the string methods should be called.
What do you think about this?
You mean make the derived class virtual operator() call append,
assign, insert, erase, or insert based on func_id and move the
whole thing to the header as well? My philosophy of where to
draw the line between how much code to move into the driver and
how much to leave in each test has been driven by the desire to
prevent failures across all or many tests caused by problems in
a library component that should not otherwise affect them. For
example, if basic_string::insert<InputIterator>() had a bug that
prevented it from compiling that bug should not cause compilation
errors in tests exercising other template members. Since merging
all the derived classes into one would cause the instantiation of
calls to all members referenced in the derived class operator()
this design would expose us to the problem I'm trying to prevent.
Martin
