String et array sans {$H+}

Bonjour,


{$H+} => "forces the compiler to use ansi-strings when no length is specified". Donc, quand cette directive est absente, on n'utilise pas les ansi-strings.

Pourquoi, sous Windows, le code suivant produit-il l'erreur : fopen.pas(832,43) Error: Incompatible type for arg no. 2: Got "Array[0..8] Of ShortString", expected "Open Array Of AnsiString"

Code:

---

1 2 3 4 5 6

unit fOpen; {$mode objfpc} interface [...] var aRRayFilesName : array [0..8] of String;

---

...alors que celui ci-dessous passe sans problème...

Code:

---

1 2 3 4 5 6

unit fOpen; {$mode objfpc} interface [...] var aRRayFilesName : array [0..8] of UTF8String;

---

... puisque par défaut sans {H+} les strings sont en UTF8 ?

Cordialement. Gilles

A la base il existe 2 types de chaînes. Le premier ShortString correspond aux chaînes héritées du turbo pascal (256 caractère maxi) et le second AnsiString correspond aux chaînes longues. Ces 2 types ne changent jamais quelque soit la position du commutateur {$H}. En fonction de ce commutateur le type String est équivalent soit à ShortString ({$H-}) soit à AnsiString ({$H+}).

Le type UTF8String est déclaré comme suit :

Code:

---

UTF8String = type ansistring;

---

Donc le type UTF8String est toujours une chaîne longue quelque soit la position de {$H}.

Le plus simple c'est de toujours laisser {$H+}.En cas de besoin on peut toujours déclarer au cas par cas une chaîne courte. Exemples :

Code:

---

1 2 3

var S1 : ShortString; S2 : String[25];

---

Bonjour,

Merci pour votre réponse. Je me suis rappelé d'un lien que vous m'aviez fourni lors d'une interrogation sur la nature des int64, lien que je viens de relire pour la partie Character types ... et je n'en déduis pas grand chose de satisfaisant. Je pensais comprendre l'UTF8 avec Lazarus sous Windows et je m'aperçois que les fondements sont moins stables qu'ils ne le paraîssent.

Donc, à partir d'une seule commande (une directive de compilation), il n'y a pas de gestion des strings (UTF8) "nativement". Le nativement s'appliquant à la différenciation de gestion de l'encodage (et donc du nombre de bits utilisés comme le précise Michel CARRARE Codages ANSI et UTF-8 des caractères). Pourquoi ne pas avoir choisi cette solution alors qu'elle est partiellement implantée pour d'autres Character types...

.... donc sous Windows, FP gère les strings UTF8 au mieux (au moins mal) : "and on Windows, they are allocated with a special windows function which allows them to be used for OLE automation.". Pour l'unicode d'une manière générale "The compiler itself provides no support for any conversion from Unicode to ansistrings or vice versa. The system unit has a unicodestring manager record, which can be initialized with some OS-specific unicode handling routines. For more information, see the system unit reference."

Mais ce que je ne comprends pas, c'est que sous Linux, une UTF8String serait de type ansiString ? A moins que "type ansiString" signifie chaîne longue (par opposition à ShortString) et ne soit pas lié à l'encodage proprement dit... D'ailleurs, sans faire de rapprochement avec Turbo-Pascal, j'avais pensé que la ShortString était en effet UTF8 d'où sa limitation en nombre de caractères la constituant... les programmeurs de Free Pascal ayant été confrontés au même problème que les programmeurs de mySQL (comme on le rencontre sur certaines versions de mySQL) problème que j'évoquais hier également dans une discussion sur le forum Lazarus. Visiblement, il n'en est rien. Le rapprochement était trop facile.:oops:

Pour le reste, en effet, je laisse {H+} dans mes programmes mais je faisais un petit test sans {H+} pour savoir quelles différences cela engendrait. Je voulais savoir s'il était possible de coder uniquement et intégralement "en interne" en UFT8 sous Windows en utilisant donc des strings UTF8 et les objets de la LCL qui le sont normalement. C'est donc "pseudo" possible mais cela nécessite un code très différencié de celui qui fonctionnerait par défaut sous Linux ou Mac.

J'avais déjà rencontré le problème de l'absence de {H+} avec l'utilisation de dll externes qui contenaient des fonctions renvoyant des chaînes... Cela avait fait l'objet d'une discussion. A l'époque, j'avais noté sur mon "carnet" à approfondir. Comme je me remets à Lazarus après 2 mois de C# et donc que je n'ai pas de développement engagé en ce moment, je traite les "remis à plus tard". Je raye donc String UTF8 du carnet et continuerai à développer avec {H+}... en attendant que Windows choisisse le système d'encodage des autres ;).

Merci pour vos précisions.
Cordialement. Gilles

Le choix de la dénomination AnsiString a été fait il y a longtemps par borland. Cette dénomination n'est pas des plus heureuses à mon avis (pourquoi pas LongString tout simplement) et s'avère en plus trompeuse car Ansi désigne aussi un encodage de caractère (pas officiel en plus il me semble).

Donc pour fixer les choses. AnsiString désigne juste les chaînes longues sans rien dire sur l'encodage.

Ce qui est amusant c'est que UTF8String n'en dit pas beaucoup plus non plus. C'est juste un nom supplémentaire pour AnsiString. Juste un moyen de se souvenir qu'une chaîne est en UTF8. C'est à toi de savoir à tout moment comment sont encodées les chaînes que tu manipules.

Bonjour,

Oui, oui... Je rebranche mon "traducteur" lazarusien... Enfin, il y a tout ce qu'il faut dans FP, il faut simplement s'habituer à la terminologie et également à certains héritages "linguistiques"de Delphi ou TP qui n'étaient pas prévus à l'origine pour être portés sous Nux.

Encore merci pour vos explications. Je commençais à y perdre mon latin(1)...
Bonne journée.
Cordialement. Gilles