Boost logo

Boost :

From: Alexei Novakov (alexei_novakov_at_[hidden])
Date: 2002-11-27 10:16:34


John,

You wrote:

> 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...
>
> John Maddock
> http://ourworld.compuserve.com/homepages/john_maddock/index.htm

Thank you for your thoughts. It might sound funny, but I tend to agree with
you on most of your points. basic_string as it is defined in the stadard is
not very suitable to be used in the way I do. The problem I was trying to
solve with it was the fact that the standard defines tools to work with
basic_string, but it doesn't have any good way to create new user defined
string like types compatible with basic_string so that they can reuse string
utils. In a practical sence I got pretty close to what I was trying to
achieve, but conceptually the proper solution for this would require some
standard revisions.

Best regards.

Alexei Novakov


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk