Boost logo

Boost :

From: Miro Jurisic (macdev_at_[hidden])
Date: 2004-04-14 19:39:44

In article <87d66a4lsf.fsf_at_[hidden]>, Jeremy Maitin-Shepard <jbms_at_[hidden]>

> I do see the advantage of using an existing type, and I would agree that
> the run-time complexity issues can be avoided. However, I can also see
> how it would give a false sense of compatibility, because users would
> tend to view the basic_string type as something higher-level than it
> really is; for instance, basic_string defines many low-level operations
> such as find (even find for a single code unit), which when dealing
> with Unicode text should probably be avoided in most cases, and so the
> additional verbosity of using std::find and std::search would be
> beneficial.

I completely agree with this. std::basic_string is an abstraction that happens
share a part of the name of what we are discussing here (Unicode strings), and
parts of its implementation are suitable for our purpose, but its interface is
very much mismatched to what we are looking for.

Therefore, I firmly believe that using std::basic_string to represent Unicode
strings (as opposed to using it to implement Unicode strings) would provide both
a false sense of security (to those who would think that their knowledge of
basic_string directly carries over to Unicode strings) and an invitation to use
those parts of the basic_string interface that are simply wrong for Unicode
strings (such as basic_string::find*).

Just because it's a string abstraction, it doesn't mean it's the string
abstraction we want.


If this message helped you, consider buying an item
from my wish list: <>

Boost list run by bdawes at, gregod at, cpdaniel at, john at