Les principales caractéristiques du compilateur à venir, Delphi pour Linux


Embarcadero est sur le point de sortir un nouveau compilateur Delphi pour la plate-forme Linux. Voici quelques-uns des principaux éléments techniques de ce compilateur, et les quelques différences par rapport aux compilateurs Delphi pour les autres plates-formes.

Linux Intel 64-bit

Avant d'arriver aux fonctionnalités spécifiques du langage, permettez-moi de clarifier une fois de plus la plate-forme cible, Delphi pour Linux est un peu vague. Le compilateur produit des exécutables Intel 64 bits pour Linux. Il s'agit d'une différence notable par rapport à l'ancien compilateur du projet Kylix, qui était en 32 bits. Le nouveau compilateur n'inclut pas les plates-formes Linux ARM, que nous envisageons pour l'avenir.
img/Delphi_Spartan_penguin_Small.png
Un autre élément connexe est que le compilateur est basé sur l'architecture des compilateurs LLVM, comme tous les nouveaux compilateurs Delphi (iOS 32 bits, Android 32 bits et iOS 64 bits). L'avantage est qu'il fournira une certaine optimisation significative sur le code généré. L'inconvénient est que la compilation et la liaison d'une application prend beaucoup plus de temps que lors de l'utilisation des compilateurs Windows.

Dans les rares cas où vous aurez besoin d'un code spécifique à la plate-forme, comme l'appel aux API de la plate-forme, vous pourez utiliser {IFDEF LINUX64}.

Compatibilité du langage Pascal Objet


En ce qui concerne les spécificités du langage, le niveau de compatibilité va être très élevé. Presque toutes les fonctionnalités classiques de langage Pascal, les fonctionnalités OOP, les capacités de support RAD, les fonctionnalités Pascal modernes (génériques, méthodes anonymes, réflexion, attributs) vont fonctionner de la même manière. Certains bêta-testeurs ont été en mesure de porter des bibliothèques significativement complexes d'une manière assez transparente.

Ce que vous pourriez trouver un peu plus difficile serait le portage de certains codes «plus anciens», comme le code qui n'est pas Unicode ou qui s'appuie fortement sur la plate-forme Windows. Ci-dessous quelques-unes des différences spécifiques. La seule partie qui n'est pas supposée être entièrement compatible est la gestion de la mémoire, étant donné que le nouveau compilateur est basé sur le comptage automatique de référence, comme expliqué plus loin.

Le blues des types de base et des LongWord


Je ne vais pas énumérer tous les types de données de base qui restent les mêmes, car la liste est très longue, mais regardons ce qui est spécifique à ce compilateur. Étant un compilateur 64 bits, tous les pointeurs vont être 64 bits, tandis que Integer rester sur 32 bits - c'est le comportement de tous les autres compilateurs Delphi 64 bits (et la plupart des autres langages de programmation, au passage).

La seule mise en garde est pour le type LongWord. Il s'agit d'un type de données souvent utilisé lors des appels au système d'exploitation, donc la décision qui a été prise il y a quelque temps de le faire correspondre à l'OS sous-jacent. Ainsi, par exemple, sur iOS, la même déclaration API avec LongWord compile un type de données 32 bits ou 64 bits en fonction du compilateur que vous utilisez. Sous Windows, cependant, Microsoft a pris la décision non standard de garder la même taille pour LongWord. Cela implique que les plates-formes Windows 64 bits fonctionnent différemment de la plate-forme Linux 64 bits en ce qui concerne ce type de données. Pour référence, entre autres sources, voir le long type en langage C sur différentes plates-formes sur https://en.wikipedia.org/wiki/Integer_(computer_science)#Long_integer et la première réponse sur http://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows.

Vous devrez peut-être revoir votre code utilisant LongWord et décider de conserver ce type de données ou d'en utiliser un autre (Integer, UInt32, NativeUInt ...) en fonction de votre situation. Nous avons fait et nous faisons encore une révision importante de la RTL pour nous assurer que nous n'utilisons pas ce type. Cependant, nous allons garder le code qui se comporte différemment en fonction de la plate-forme, en particulier lorsque le changement de classes de base de la RTL ferait que beaucoup de code Windows légitime utilisé depuis 20 ans ne compilerait plus.

Chaînes et encodage


Depuis Delphi 2009, le type string du langage Pascal d'objet a par défaut un type de données Unicode UTF-16 et des caractères sur 2 octets. Inutile de dire que le compilateur Linux suit le même chemin. Depuis 10.1 Berlin, tous les compilateurs (y compris les mobiles) ont reçu un support complet pour le type UTF8String et aussi (pour le traitement de bas niveau direct) le type RawByteString. Le compilateur Linux inclut ce type de données, et en fait UTF8String a été ajouté au mobile principalement parce que nous l'avons anticipé comme une condition clé pour Linux. Une partie importante du trafic de base HTTP utilise UTF-8 et le support de cette représentation en tant que type natif - à côté de son encodage de support - a été considéré comme une exigence pour le projet Linux.

Il est vrai, toutefois, que certains autres types de chaînes comme AnsiString ne sont pas pris en charge. Il s'agit principalement d'un type de données "Windows-centric". Si vous utilisez encore des chaînes et PChar pour gérer des structures de données génériques, il est vraiment temps de passer à TBytes et PByte à la place - ou d'activer les mathématiques de pointeur pour toutes les structures de données. En outre, le support de l'ancien type Pascal ShortString est limité. La déclaration d'une variable string[20] sur Linux échouera. L'autre type de chaîne qui n'est pas pris en charge est WideString. Il s'agit de l'ancien type pre-unicode et non autoréférencé utilisé pour l'intégration de la plate-forme Windows COM. En fait, tout type et fonctionnalité spécifique à COM est manquant sur Linux, comme sur toutes les autres plates-formes Delphi non Windows.

Notez que le support de TEncoding est disponible, vous pouvez donc lire et écrire des fichiers texte dans le format que vous voulez. Ce que vous n'êtes pas directement capable de faire est de traiter un AnsiString en mémoire avec le support de langue standard. Mais vous pouvez avoir un tableau d'octets (TBytes) représentant du texte dans n'importe quel format en mémoire, lire et écrire sur le disque, ou recevoir et envoyer via une connexion socket, et vous pouvez utiliser TEncoding pour les conversions.

Linux a par défaut à des chaînes 1-basées


Qu'en est-il de l'accès aux chaînes via l'opérateur [] ? Comme vous le savez peut-être, il existe une valeur par défaut que vous pouvez modifier par projet, par unité ou même par fragment de code qui détermine si le compilateur traite l'opérateur d'accès aux chaînes avec une notation classique Pascal 1-basée ou 0-basée comme la plupart des autres langages de programmation. Alors que les compilateurs mobiles sont par défaut à 0-basé, pour Linux, nous avons décidé de rester avec le modèle Windows traditionnel, dans les faits, les développeurs sont plus susceptibles de migrer le code Windows existant côté serveur vers Linux. [*] Mais si vous préférez forcer un modèle d'accès de chaîne donné pour tout votre code Delphi, utilisez la directive $ZEROBASEDSTRINGS de vos projets. Juste pour rappel toutes les fonctions de chaîne de RTL et les nouvelles méthodes d'aide de chaîne restent les mêmes quelque soit la plate-forme et ce paramètre. Le premier groupe utilise une logique 1-basée, le second une logique 0-basée. Le choix vous appartient.

* Franchement, je ne sais pas comment traduire "The recommendation is to try to sue clean, agnostic code".

Voici l'ARC


L'autre changement notable par rapport au compilateur Windows est que sur la plate-forme Linux (comme dans toute nouvelle plate-forme), nous avons décidé d'utiliser le modèle Automatic Reference Counting (ARC) pour la gestion de la mémoire. C'est le modèle que Delphi utilise pour tous les compilateurs mobiles et le simulateur iOS. Les projets à long terme sont de déplacer l'écosystème entier de Delphi dans cette direction - gardant probablement le monde de VCL sur le modèle traditionnel de mémoire. C'est la raison pour laquelle le non-usage d'ARC pour Linux aurait été très déroutant, étant donné que vous avez besoin de tests lors de l'adoption d'une nouvelle plateforme, c'est le moment le moins perturbateur pour une telle transition.

Les commentaires des bêta-testeurs ont été assez positifs à ce sujet, et la migration du code existant et des bibliothèques n'a pas levé de gros lièvres. Maintenant, je n'ai pas de place dans ce billet de blog pour revoir les meilleures pratiques pour la migration ARC, mais je vais essayer d'avoir un peu plus de matériel sur ce sujet à l'avenir.

Note éhonté: Mon "Object Pascal Handbook" (et en particulier l'édition révisée de Berlin) est tout indiqué à ce sujet.

Plus d'information? Delphi Linux BootCamp est à venir!

Pour plus d'informations, inscrivez-vous au camp d'entraînement (qui est en fait un webinaire d'une heure) prévue pour le 1er mars en 3 zones. Pour plus d'informations et pour vous inscrire, consultez https://community.embarcadero.com/blogs/entry/delphi-linux-boot-camp.

traduction par Paul TOTH - aidé de Google - de l'article de Marco.
Date de dernière modification : 17/02/2017