Andrea Griffini <***@tin.it> writes:
|> On 6 Aug 2004 11:13:49 -0400, ***@gabi-soft.fr wrote:
|> >In sum, no reasonable person would expect a simple solution for an
|> >incomplete question.
|> Every question is incomplete; it all boils down where you want to
|> stop adding details. Common sense is trying to stop asking details
|> at least before who is talking to you is tempted to hit your nose
|> with a punch.
|> If someone asks you "where is north" now I wonder if you are going
|> to say "do you mean geographical north, magnetical north or
|> geomagnetical north ?". You can really go forever... even
|> establishing which of the three major north pole one is concerned
|> about the question is far from being "complete". For example
|> supposing the subject is the magnetical north a question could be
|> "Are you asking what direction would a compass be pointing to (hence
|> considering local magnetic field modifications), or what geodesic
|> line would pass from here and the north magnetic pole supposing the
|> earth being a sphere (so you're interested in where the pole is) ?".
|> But my guess is that your nose would be already bleeding by then.
It's not quite equivalent. Everywhere I've ever been, if someone speaks
of "north", they mean geographical north. In most of the places I've
actually worked, however, there really are ambiguïties concerning case
insensitive comparisons, and e.g. 'é' and 'E' are not considered equal
when comparing, say, filenames, but are when comparing other things.
For better or worse, just saying you want a case insensitive comparison
is NOT a sufficient specification to do anything about in French or
German. It is in English, and I think in Italian as well (although even
there, one might expect stricmp( "vertù", "VERTU" ) to return true).
And it is a real fact that a significant number of users of C++ are not
working in English speaking environments.
|> >Is it a lack of common sense to want to know what the function
|> >should do before trying to find it?
|> Lack of common sense is the missing of "s.upper()" or "upper(s)"
|> working on std::string by default. It would have been of course ok
|> being able to handle complexity needed for chinese ... but ONLY if
|> that wasn't going to annoy where it's not needed.
I would argue that something like s.upper() or toUpper(s) would be a
good idea. I would also argue, however, that the actual signature
should be something like:
std::string::upper( std::locale const& = std::locale() ) ;
I do agree that there are many contexts where it is clear. I have
nothing against reasonable defaults.
|> To me it's evident (and Francis confirmed) that the prolem is the
|> "committee effect" that required to avoid assuming that american
|> english should be the "default". Or that anything was going to be
|> the default because that would have been "unfair" for the others.
There is a political problem with a "default" of American English, at
least when the default can't be overridden. In this case, it would seem
to me that there is a good solution, which allows overriding, or even
setting the default to something else.
[...]
|> >The C++ standard DOES have a function for case insensitive
|> >comparison of strings: std::collate::compare.
|> But no s.upper() or upper(s) ... because that would be
|> - pointless
|> - not well defined
|> - locale dependent
|> - immoral
|> - uncool
|> - having it working for american english would be unfair
|> for languages where it's an unsolvable problem (IIUC
|> for german not even a dictionary could be enough... but
|> a syntax analysis or even an semantical analysis of the
|> meaning of the text is required).
More likely because despite the name, std::string really has very little
to do with text. It's just a glorified container for small integers. Or
whatever -- the standard says you can have std::basic_string<double>
(although it core dumps with g++ on Solaris).
I'll admit that I'd find even a limited toupper more use than
basic_string<double>. Precisely because of all the problems we've been
talking about -- you can't implement it using a character by character
translation, so it has to work on strings. IMHO, it must be locale
specific, but that's not really a problem.
On the other hand, it doesn't require any cool template
meta-programming, so I guess that's a good reason not to have it.
|> >And just as obviously, the user can supply additional versions for
|> >himself, since this is definitly a case where one size doesn't fit
|> >all.
|> I don't need it solved in the general case. I can solve it to any
|> extent I want if I have to. And I'm not forced to put my solution in
|> the frameset of the standard library.
|> Let me add that I probably wouldn't. Reading Herb Sutter's
|> exceptional C++ items 2 and 3 made clear for me that I'll stay as
|> far as possible from that. My job is solving problems using C++ as a
|> tool, not fighting with C++ for the fun of it.
Sounds like we have similar problems:-). My customers pay me for
working code, not for stress testing compilers.
Maybe the only difference is that I've really had to deal with "case
insensitive" look-ups involving "Maße":-). I'll admit that I'm very
sensitized to the problem. (And a quick glance at the thread shows that
almost all of the people asking for a more precise specification work or
have worked in German speaking areas. Probably not by chance.)
|> Lack of common sense is providing complex solutions (or complex
|> infrastructure where you should put your complex solution) for
|> complex cases, ignoring providing reasonable simple solutions for
|> simple cases.
Would you be talking about locale, by any chance?
|> >(Removing trailing spaces is a different issue -- it is locale
|> >dependant, but other than that, I don't see any real problems.)
|> But where are the trim functions in the standard library ?
Where is any support for text? Where is a true character type?
Where is networking? Where is a GUI?
|> Anyway I don't think that anything I may say would convince you that
|> there's lack of common sense in what C++ proposes.
If "convince" implies my changing my opinion, no. Because I'm already
convinced of it for a number of things: all of locale, or the
templatization of iostream or string, for example.
Still, it's the only standard we've got, and we can (and have to) live
with it. It could be worse.
|> If you can't see why the following is ludicrous
|> if ( std::use_facet< std::collate< char > >( std::locale() )
|> .compare( s1.data(), s1.data() + s1.size(),
|> s2.data(), s2.data() + s2.size() ) == 0 ) ...
|> probably no amount of explanation would be enough.
What's wrong with a simple wrapper?
And to tell the truth: we're complaining about a lack of proper support
for text in C++. Did you, or any one else, make a proposal? I know I
didn't, and the committee can't standardize something that hasn't even
been proposed.
--
James Kanze
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! ]