Re: Pre-information on Unicode in Delphi 2008

Just as is the case with different types of integers....

Well IMO this is one case where Delphi isn't doing strong typing, there should be a warning there (just like there can be in C++) and a requirement for an explicit cast.

If you don't code for it, then you don't care (or at least can't complain if you get caught out).

Actually I can complain, because the compiler didn't provide me with any warning. Some of those conversions happen not because you didn't care, but because you made mistake.

you better believe that you _might_ experience some data loss. But maybe that's OK. If it's not OK then you code for it:

sA := ANSIEncode(sU);

Most of the time, no, that's not ok.
The first form should trigger a compiler warning, otherwise you're just setting yourself up for zillions of mistakes... just like currently happens between AnsiString and WideString, *whichever* way you're converting.
Converting from Ansi to Wide while assuming the Ansi is using the system_locale is just an assumption, and in the Delphi IDE itself, that can results in string corruption when editing DFMs, and before you ask, yes there are QCs on the subject :)

> since ALL the "String"s in such applications will by definition have
> the same encoding UNLESS the application is ALREADY coding
> specifically for a variety of encodings

I'm not following you there. AnsiString have no particular encoding at all (neither the same, nor the system's), assuming *any* encoding for automagic conversion is going to result in hard-to-track cases of data corruption (since basicly any ":=" becomes suspect).

It only becomes an "issue" for NEW applications specifically mixing difference types of string encodings in their application and then not adequately allowing for those different encodings.

It becomes an issue whenever you're going to have some form of automagic conversion/comparison routine happen.
F.i. if you assume a particular Ansi encoding for a string, then you'll have to honour it for comparisons, and depending on the encoding assumed, the result of the string comparisons will be different.

Different sized/signed integers.
Different precision floats.

These are trouble actually.
Good thing we at least have errors when converting from floats to integers!

Just because it isn't perfectly bulletproof doesn't mean it isn't the best possible (and most practical) approach.

Automagic conversions are neither bulletproof nor practical IME, they're false time savers - just like using one-letter function names all over the place would be ;)

Eric
.

Relevant Pages

  • Re: Changing garbled text ("???? ??????") to readable text ("?? ???")
    ... should be converting from your original file's *binary* data into a ... string using an encoding. ... I'll be dealing with ID3 tags and the data returned from the ID3 tag ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Convert Encoding from Shift-JIS to UTF-8
    ... No. You're converting the string into UTF-8, ... > converting one encoding to another using .Net. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: TripleDES output size
    ... If you are using UTF-8 for converting string to binary (generally a good ... encoding, then you should always get two bytes per character. ... you can figure out how many bytes of cipher data you'll get by ...
    (microsoft.public.dotnet.security)
  • Re: TripleDES encryption problem
    ... ASCII is only a 7-bit encoding, and your key uses the full 8-bit space ... >> Somehow converting the output of DesEncrypt to a string and then ...
    (microsoft.public.dotnet.security)
  • Re: Why asci-only symbols?
    ... >> Perhaps string equivalence in keys will be treated like numeric equivalence? ... I know typewill be and in itself contain no encoding information now, ... >and a Unicode string, the system default encoding ...
    (comp.lang.python)
Loading