Just out of curiosity, and without even being sure, if a real use case for something like this ever exists

With the new strings, the encoding is part of the data, not the type. However most types force a specific encoding, therefore conversion occurs.

rawbytestring does not force a specific encoding. It keeps whatever encoding the data has. the encoding however is still present, so assigning to an type with enforced encoding will still do the converison if required.

Now my question.
Is there (or going to be) an encoding, that is "unknown" and will never be converted. but can be assigned to any of the types?

Of course I am aware, that this would have dangers. As it would bypass the "enforced" encodings....

Anyway just asking

In our previous episode, Martin said:

Now my question. Is there (or going to be) an encoding, that is "unknown" and will never be converted. but can be assigned to any of the types?

Afaik, there is no such thing in Delphi.

Slight change in topic:

What encoding does a pchar have? Or rather what does it get, when for example assigned to a rawbytestring?

what happens (or is intended to happen), if I cast a string to pchar, before handing it over as param?

procedure foo(a: Utf8String);
.....
var s: string;
foo(pchar(s));
or
foo(pchar(@s[2]));

In our previous episode, Martin said:

What encoding does a pchar have?

pchar and char match string.

what happens (or is intended to happen), if I cast a string to pchar, before handing it over as param?

Nothing. If you try to cast another type, it probably does a conversion and create a temp, but I didn't try.

IIRC it does give an error if the granularity doesn't match (e.g. string=unicodestring thus pchar=punicodechar and you typecast e.g. a utf8string)

I suppose there is a way to just set the encoding of a new string. This should not affect the stored bytes (or words or DWords).

-Michael

Michael Schnell wrote

I suppose there is a way to just set the encoding of a new string. This should not affect the stored bytes (or words or DWords).

Yes, there is SetCodePage() both for AnsiString types and UnicodeString type.

Also RTL has SetMultiByteConversionCodePage functions to set default codepage for AnsiString.

Best regards,
Paul Ishenin.

Now my question. Is there (or going to be) an encoding, that is "unknown" and will never be converted. but can be assigned to any of the types?

Delphi has no such encoding, it suggests to use TBytes for that purpose (or the like, dunno remember the name).

An "unknown" encoding would make such strings incompatible with all other strings, with assignments and other operations disallowed.

DoDi

Good question. Delphi claims that AnsiChar corresponds to the first 256 Unicode characters, but this may not always hold :-(

This will work only when "string" is UTF-16, since PChar is a pointer to Unicode. You can try figure out what copies and conversions the compiler may insert, in order to match the given casts and argument types.

or foo(pchar(@s[2]));

In all cases a temporary UTF8string will be used, matching the strong argument type of foo.

See also: ms-help://embarcadero.rs_xe/vcl/System.PAnsiChar.html

DoDi

You do know that currently PChar is still a PAnsiChar? Also there was no final decision whether "mode ObjFPC" will have String defined as UnicodeString or not. It only seems to be the case that there will be a mode "DelphiUnicode" where this is true (and maybe a modeswitch "unicodestrings" like was done for the JVM port).

Regards,
Sven

In our previous episode, Michael Schnell said:

I suppose there is a way to just set the encoding of a new string. This should not affect the stored bytes (or words or DWords).

Afaik it does, but only for ansistring. IIRC there is also a codepage that just means "system default" and assumes the system knows how to convert that from/to utf16 (or utf8 on *nix)

Marco van de Voort wrote

In our previous episode, Michael Schnell said: > I suppose there is a way to just set the encoding of a new string. This > should not affect the stored bytes (or words or DWords). Afaik it does, but only for ansistring.

What exactly is "ansistring" in this relation ? If there are multiple (names for the basic) dynamically typed ("new") string type(s). what advantage is this supposed to provide ?

IIRC there is also a codepage that just means "system default" and assumes the system knows how to convert that from/to utf16 (or utf8 on *nix)

I recon the "system default code page" is the encoding used when assigning a constant string to a string variable. It might/should be possible that same is different from the coding of the source file. It might/should be granted that a conversion is not necessary at run time, but the constant already is stored appropriately in the executable.

OTOH when "ANSI" is used for a constant it might/should or should not be possible that the current locale setting is used for doing a proper

Marco van de Voort wrote

IRC there is also a codepage that just means "system default" and assumes the system knows how to convert that from/to utf16 (or utf8 on *nix)

Why should it do a _conversion_ and not just use the appropriate coding (e.g. utf-16 on Windows and utf-8 on *nix) for the constants and thus provide that all strings are initialized with this coding when they get any content (of course the content originated by the OS/WidgetSet API comes in in this coding as well.

So - unless the user code forces it - no conversion ever is necessary.

-Michael