Re: Caseless String
Le Chaud Lapin wrote:
James Kanze wrote:
Le Chaud Lapin wrote:
Le Chaud Lapin wrote:
I'm sceptical. In a caseless comparison, "SS" == "?", for
example (a two character sequence compares equal to a single
character).
Ich auch. This is why I do not enjoy writing a string class. A
computational linguist once told me that there are no easy answers.
That's because it deals with human issues, and humans are
complex.
But I thought the ess-tsett problem represents a different
class of problems altogether.
If you want to do caseless compare, you have to address it. You
also have to consider that 'i' == 'I' in most western European
locales, but not in Turkish. As your linguist said, there are
no easy answers.
Copy construction, no, because it doesn't make sense.
There are many cases where I have an ASCII string and want to convert
it to UNICODE and vice-versa.
There are many cases where I have a narrow character string in
one encoding, and want to convert it to either a wide character
string in UTF-16 or UTF-32, or a narrow character string in
UTF-8 (or vice versa). The non-Unicode encoding, however, is
almost never ASCII: it's usually ISO 8859-1 or ISO 8859-15,
where I live, but could be other things.
You don't think it is a good idea to
make a conversion constructor for this purpose?
I'm not sure. I'd at least offer the possibility of specifying
the locale (so as to specify the initial encoding). But I guess
if you defaulted to the current global locale, that's
reasonable, and you do then end up with a converting
constructor.
(Technically, it wouldn't be copy conversion anyway, but I think
it's clear that you mean a conversion constructor, taking a
single parameter.)
Basically, I think that the intent is that there be a single
encoding for wchar_t, with conversion on the fly during input
and output, and numerous different encodings for char, depending
on the locale. The problem with a conversion constructor is
that it must be told the encoding of the narrow string.
Perhaps something along the lines of:
std::string::string( std::wstring const&,
locale const& = std::locale() ) ;
I had a vague notion of putting string types in namespaces
corresponding to different languages, so for example:
English::String<>
Deutsch::String<>
Espa?ol::String<>
Fran?ais::String<>
But of course, this could get tedious:
Schweiz::Deutsch::String<>
Deutschland::Deutsch::String<>
And how.
And of course, in most programs, you'd only be using one of the
variants anyway. Say with a typedef:
typedef English::String<> MyString ;
Except, of course, that the typedef would have to be determined
at runtime:-).
Another possible solution would be to declare one class, with
many different implementations, each in its own DLL. Which gets
loaded dynamically, depending on some environment variable, so
one time the program runs, String acts like English::String, and
another time, like German::String.
I thought about defining a universal string to contain UNICODE
character with conversions to/from, but the problem is already
overwhelming and I am ready to abort.
It's the solution more or less adopted by the standard library.
Convert on I/O, and use wchar_t (hopefully Unicode) internally.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]