From: John Maddock (jm_at_[hidden])
Date: 2002-11-27 07:15:49
> > Looks like we're all thinking alike, a while ago I put together a
> > based substring class that could act as a universal wrapper for any
> > like object, along with a set of algorithms to act upon it: it's based
> > loosely on Darin Adler's original string algorithm code.
> I took a look at your classes, it really looks very similar to my sub
> string. Only big difference I can see now is you sub string looks like a
> basic_string and mine IS a basic_string. Practical advantage it gives is
> ability to use most of string algorithms and utilities for sub strings as
> well without changing anything on the utility side. I was looking at
> standard basic_string to be "universal wrapper for any string like
> which provides standard interface and can be "overriden" with all kinds of
> template specializations. This interface is not always very generic and
> flexible, but still suitable.
I hate to say it, but I *really* don't like the idea of abusing std::string
in this way: and IMO it is an abuse: a substring is not conceptually "an
instance of" std::string. It's not mutable, and it doesn't manage it's own
memory etc etc. From a practical point of view, it doesn't really work
either - your substring doesn't actually behave like a std::string in all
circumstances, so you can't guarantee that it can be used with all string
based algorithms; std lib algorithms are even entitled to access the private
implementation details of std::basic_string (if they're declared as
friends), so those need not work either :-(
The point of providing a string_traits class, was that it allows classes
that we haven't yet thought of, heard of, or invented yet(!), to be used as
string classes with the string algorithms. For example it would allow
Microsoft's CString or Borlands AnsiString classes to be used with these
algorithms. Even though we do have a standard string class, string classes
are none the less proliferating if anything, especially once you start
interoperating with COM, CORBRA or whatever.
Anyway just some thoughts...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk