Topic: What's the preferred manner of creating case-insensitive
Author: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
Date: 1996/09/25 Raw View
In article <3246e7c6.285159347@news.interlog.com> herbs@cntc.com (Herb
Sutter) writes:
|> On 23 Sep 1996 14:44:13 GMT, kanze@gabi-soft.fr (J. Kanze) wrote:
|> >herbs@cntc.com (Herb Sutter) writes:
|> >> 1. Case-sensitivity should be a property of the comparison function,
|> >> not of the string object. Sometimes you want to compare the same
|> >> strings case-sensitively and case-insensitively.
|> > [...]
|> >> It came up a month or two ago in this group, but my cursory reading of
|> >> the thread wasn't enough to get a good feel for what the committee
|> >> wanted. There was discussion about case comparisons being
|> >> locale-driven (which I submit is probably just as bad as (1.) above,
|> >> since you want case-sensitivity to be a property of the comparison
|> >> function and not the string object itself or the current locale).
|> >But case-sensitivity is bound to depend on the current locale. If the
|> >current locale is set for French, for example, accented characters
|> >compare equal, where for other locale's they might not.
|> I agree that case-insensitive comparisons depend on locale.
|> What I was driving at is that the same program will want to compare
|> the same strings case-sensitively one time and case-insensitively
|> another time. Hence the case sensitivity must not be a property of
|> the string object; it has to be a property of the comparison function.
To be frank, I can't quite see the use of this. Either the string
contains text (which requires case insensitivity) or it contains
something else (say C++ source code) which doesn't. However, I can see
no reason to forbid it.
[examples deleted...]
|> That's what I meant when I pointed out that making string s be of a
|> new string type (basic_string instantiated with a 'traits' that's
|> case-insensitive) doesn't help... in one place, s must be compared
|> case-sensitively, and in another, it must not. Hence:
|> >> 1. Case-sensitivity should be a property of the comparison function,
|> >> not of the string object. Sometimes you want to compare the same
|> >> strings case-sensitively and case-insensitively.
|> If anyone can show me a better recourse than 'stricmp(s1.c_str(),
|> s2.c_str()' I'd be overjoyed to hear about it. I can't think of a
|> better one, even assuming the liberty of making changes to the
|> language. :-(
Well, there is one that will work with most current implementations of
string:
use_facet< collate< char > >( loc ).compare(
s1.begin() , s1.end() ,
s2.begin() , s2.end() ) ;
According to the Jan. 96 draft, however, collate::compare takes charT*'s
as parameters, and not iterators, so this will only work if
basic_string::iterator is a charT*, which isn't guaranteed. I suspect
that this is just a question of the committee not yet having everything
synch'ed, however, and that in the final version, compare will be
defined to take basic_string< charT >::interator's as well (and maybe
even string's themselves).
There is also the function lexicographical_compare, in the algorithms,
but I cannot quite figure out what it is supposed to do from the draft.
Any lexicographical_compare is definitly locale dependant, and then
some. (There are two common collating sequences in use in Germany, for
example. The telephone books use one, and most biographical
dictionaries use the other.) There is no mention of the interactions
between the function and locale. In addition, there is a variant with a
user provided comparison function; presumably, this will be called to
compare characters, but you cannot do a lexicographical comparison on a
character by character basis. (In German, for example, the two
character sequence "ss" compares lexicographically equal to the single
character " " =0xdf in ISO 8859-1). Again, I suspect that this is a
result of the actual library stemming from two different sources (one of
which didn't support internationalization), and the committee not yet
having gotten them fully synchronized.
--
James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, tudes et r alisations en logiciel orient objet --
-- A la recherche d'une activit dans une region francophone
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]