Re: Suggested Alternative Unicode Implementation (for Rudy+ miscothers)

In article <xn0fnhr4qv41iy4009newsgroups@xxxxxxxxxxxx>,
newsgroups@xxxxxxxxxxxx says...
Jolyon Smith wrote:

In article <47d2ab45$1@xxxxxxxxxxxxxxxxxxxxxx>,
chris.nospam@xxxxxxxxxxxxxx says...

There would need to be parallel versions of every single BPL.

ONLY if you accept the current proposed implementation.

The whole point of the alternative approach is

My big problem wit hthgat is that each time you interact with the RTL
or any odf the compiled BPLs, strings would haver to be converted.

Only if you were using strings other that UTF16 in your application.

The point is you would get the CHOICE, and crucially, for existing
applications you would have the peace of mind that in your application
"space", strings are as they have always been.



Add to that that if AnsiChar code is passed to Unicode APIs, via a PChar
cast, the compiler would have to create a converted copy of the string,

This is going to happen ANYWAY, even with the CodeGear approach, given
that most sane people with commercial contracts in place between
themselves and their useers will be taking CodeGear's own advice and
changing implicit String declarations to explicit ANSIString.

You want conversions?

CodeGear will be delivering them by the bucketload.


The correct approach w.r.t the WinAPI is of course to support both W and
A versions of function prototypes as appropriate to an applications
needs.

i.e. you have an ANSIString in your hand, you call the A API. You have
a UTF16 in your hand you call the W API.

If you have a UTF8 or UTF32 you will of course need to call the W API
having converted to UTF16, but them's the breaks. Whichever approach is
taken there is going to be SOME conversion required. That is simple
inescapable.

Now, making all this transparent could be tricksy, I grant you.

My own suggestion would be that existing "Windows" units would remain
ANSI, and new W versions of those units provided for specifically
Unicode applications to use.

Because, as stated previously, existing applications have only ever been
calling the A API's (unless specifically and deliberately circumventing
the Delphi units for those APIs).

.

Relevant Pages