[fpc-devel] Unicode proceedings

[Hans-Peter Diettrich]

Michael Schnell schrieb:
> On 11/16/2011 02:56 PM, Hans-Peter Diettrich wrote:
>> Delphi uses the native/generic AnsiString(0),
> A native /generic type is exactly what is _not_ available in the A) 
> suggestion of definitions. Here a type name stands for exactly one 
> encoding variant. No dynamic encoding (implemented by having a variable 
> hold a field that denotes which encoding is used) is possible.

Right, you continue to provide suggestions that only result in slow code 
at runtime :-(

Why not go the Delphi way, that is fully documented, easy and safe to 
use, and allows for fast applications?


> As with a system that provides Type names and additionally does dynamic 
> encoding such beasts _can_ occur (e.g. if you do a diabolic "move()"),

Such code indicates that the coder didn't understand the principles of 
Unicode string handling :-(

> So the implementation definition needs to state what has to be done if 
> such a case is detected (e.g. ignore or fire an exception).

Not all bogus code can be detected by the compiler. It may be helpful to 
have sanity checks in many places, but only with conditional 
compilation. Why bother the brave user with checks and consequently slow 
code, when these checks only are required to prevent the uneducated 
users from doing bad things?


>>>  - RAW variables that in fact have a dynamic encoding definition of 
>>> "NONE/RAW" and are to be converted into a strictly typed variable.
>>> Handling this might be considered an "implementation detail". So 
>>> Delphi compatibility is not necessary.
>>
>> Nobody wants that, except you.
> 
> RAW strings are exceptionally useful.
> 
> E.G.:
> You want to do a function that provides the first (ASCII-coded) number 
> in a string.
> 
> If you do this function with a RAW parameter you don't need multiple 
> overloaded variants of the function and the code in the function can 
> take care of the actual encoding of the content of the string without 
> doing any actual (time consuming) conversion, as the ASCII numerals to 
> be extracted never need a conversion.

Right, that's the *only* place where RawByteString makes sense.

But even then the coder is responsible for doing things right, because 
the compiler cannot assist in finding more or less obvious coding 
errors. See the Pos() example, that comes with an unsafe and unusable 
implementation in Delphi :-(


> Moreover, in fact, strings can be used for simply holding a sequence of 
> bytes, words or DWORDs, just to take advantage of the reference counting 
> provided by the string types. Here of course it does not make any sense 
> to define any encoding scheme.
> 
> In this case a "NONE" encoding-variant for the string type "RAW" is 
> valuable.

Abusing strings for binary data is a bad idea. Delphi provides an TBytes 
type for that purpose, and FPC could add more useful features to it.

DoDi