Le Chaud Lapin wrote:
> On Jul 15, 11:28 am, ManicQin <Manic...@[EMAIL PROTECTED]
> wrote:
>> On Jul 8, 1:45 am, Le Chaud Lapin <jaibudu...@[EMAIL PROTECTED]
> wrote:
>>
>>> String<char> s1 "exasperation"; // English
>>> String<char> s2 "exasp?ration"; // fran?ais
>>
>>> In your opinion,
>>
>>> 1. Should [s1 == s2] be true?
>>
>> That would be great but as oters said a string should be a string
>> so I vote for !=
>>
>> What about languages such as Hebrew , Arabic , Chinese and other
>> none Latin or even none "left to right" languages?
>
> Hi All,
>
> I am responding to ManicQuin's post only because his is
> chronologically last.
>
> First, I have read everyone's replies, most several times. I would
> like to make a retraction regarding what I said about Unicode,
> related to what Albert wrote. There does seem to be much that has
> been solved, but there is still work to be done, IMHO, not with
> Unicode, but with the incor****ation of Unicode into a useable
> string class.
>
> Second, the example I used comparing French "exasperation" to
> English "exasperation" was poor. I was probably tired. I am again
> tired, so no good examples come to mind right now, but my gut
> feeling is that the class should have at least what I have been
> calling "locale", even though that might not be the correct term.
> All of you have warned against putting intelligence in the string
> class. I wonder if this bit of extra information would count as too
> much intelligence. While I have not read enough about Unicode to
> know the path I will follow, I will probably include this bit of
> information anyway. My motivation is the tedious misery that might
> result if not. I think about all my code, where operator == and
> operator !=, etc. are used in contexts where programmer fingers are
> not allowed, and would very much like to continue doing this.
>
> So my strategy is to find out exactly what extra elements should be
> included in a String<> class based on work of Unicode to allowed
> operator == () and its friends can remain as they are. If it happens
> that two strings meet each other on both sides of an operator as
> mutual foreigners:
>
> String<> s1 = "mein"; // German for English "mine"
> String<> s2 = "mein"; // English stolen from Chinese for type of
> noodle.
>
> s1 == s2;
>
> I can let operator == decide through consultation of external state.
> The comparison for same-locale strings should be fast enough, and if
> the locales difference, then they will differ no matter which scheme
> is used.
You will have to store a lot of external state to determine that
English "mine" can also mean "Mine" (noun) in German, or "verminen"
(verb) if it blows up. It can also mean "Grube", or "Mine"(!) if you
dig in the ground.
The still other English "mine", like in "belongs to me" needs even
more context.
http://www.dict.cc/englisch-deutsch/mine.html
So, there is a lot of difference between "It's mine" and "It's a
mine". :-)
>
> As for the multi-threading issue that will be encountered such state
> is consulted, I have solution for that.;)
>
That's the easy part! :-)
Bo Persson
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


|