Re: Unicode Support

Chewy509@xxxxxxxxxxxxxxxx écrivait news:1113959758.742075.249480
@l41g2000cwc.googlegroups.com:

>> I must apologioze that i have no idea, at all,
>> about how this is usable or not usable for the real
>> "Unicode Users".
>
> Would you prefer:
> "Hello world"
> or
> 48h, 65h, 6ch, 6ch, 6fh, 020h, 77h, 6fh, 72h, 6ch, 64h
> within your source file.
>
> I would prefer the first form (as anyone would). Now take the view of
> the Hindi student in India who doesn't know english. Are you going to
> force the second option on him, so he can use your assembler?
>
> (I know this is a poor example, but think about other languages, eg
> hebrew, most asian, etc).

Of course. Evident. I would also like it to work
that way. What i am saying is that is simply
_DO NOT KNOW_, if it actually works that way or
not. I use an occidental KeyBoard, and i have no
idea, at all, of what is going on, when, say, an
oriental user inputs something directly in Unicode.

There is a Case, in the RosASm MainWindow Messages
holding for "&WM_IME_CHAR" actually, that is
effectively suposed to input Double-Bytes, into the
Source. But i do not know:

1) If it really works.

2) What goes on, in the life of the Source, with
the so many Edition and Compilation Functionalities,
and at what extend they could choke, on some Bytes
of the Double Bytes.

For example, RosAsm always parses the Strings
from Quotes to Quotes, on a _BYTE_ Basis scan.
Let us imagine, that, inside some Double Byte,
the same Byte as a Quote would be inserted from
a Unicode String... Can this happend? i simply
do not know (It would create an "Unpaired Quotes"
faultive error Message)...


>> As for writing, as you suggest, say, the labels
>> Names, in Unicode, directly in a RosAsm Source,
>> this will never be implemented. I do not see any
>> reason for doing so.
>
> So your source code will forever be ASCII?

The Assembly Source, Yes. Unicode will be (or are)
for Data Strings only, and possibly, maybe, for
Comments.

But, for naming the Labels, sure, not, and never.
That would be much no use complication, IMHO.

I Have read a long (as usaul...) Post, from Beth,
some long time ago, where she was, if i understood
well, promoting a kind of UTF something, that should
be the universal default. As i was not much interrested,
i did not read it carefully, but...

Beth... maybe.. a couple of words would help him...

:)

Betov.

< http://rosasm.org/ >


.

Relevant Pages

  • Re: Unicode Support
    ... assemblers, just the fact that you both actively develop assemblers. ... > There is no plan for implementing Unicode in RosAsm, ... > of the RosAsm Strings. ...
    (alt.lang.asm)
  • Re: How to check variables for uniqueness ?
    ... characters is the sequence SS. ... is simply capitalizing strings. ... The fact that case mapping in English /is/ simple is neither here not ... That is a fair criticism of the Unicode position. ...
    (comp.lang.java.programmer)
  • Re: Dangerous behavior of CString
    ... If I'm reading a data file or serial port or something, if the raw data are multibyte but the compilation is Unicode or vice-versa, then sometimes the converting constructors in CString are convenient. ... I did not actually write code like this; in fact I was pretty careful always to use the _T macro with any literal strings. ... But it does the conversion using the current 8-bit code page, which is not what I want. ...
    (microsoft.public.vc.mfc)
  • Re: Help please
    ... i would like to provide "CSimString" class code because the settings ... I agree with Tom that first step is project clean and rebuild all. ... with a Unicode string, ... Consider that VS2005 strings are Unicode by default, ...
    (microsoft.public.vc.mfc)
  • Re: passing a string to a dll
    ... bool DLLRect::PullWhisker ... The interface for the DLL exported function could be like so: ... based on _UNICODE flag, e.g. ... I think that in these days those ANSI strings are something from the ...
    (microsoft.public.vc.mfc)