Différences entre les compilateurs C++ améliorés par Clang et les compilateurs C++ de précédente génération

De RAD Studio
Aller à : navigation, rechercher

Remonter à Compilateurs C++ améliorés par Clang


Cette rubrique présente les différences entre les compilateurs C++ améliorés par Clang et leur prédécesseur immédiat, BCC32.

Options de ligne de commande

Les compilateurs C++ améliorés par Clang utilisent un ensemble totalement différent options de ligne de commande, et une façon différente d'exprimer des valeurs multiples pour la même option.

Compilateur C++ plus strict

Les compilateurs C++ améliorés par Clang présentent une plus grande compatibilité que BCC32 avec les standards du langage C++.Ils prennent en charge C++11, mais ils sont également plus stricts. Voir Compilateurs C++ plus stricts (compilateurs C++ améliorés par Clang).

Avertissements et messages d'erreur

En plus de leurs avertissements et messages d'erreur, nouveaux, plus spécifiques et détaillés, les compilateurs C++ améliorés par Clang formulent différemment les messages relatifs aux conditions détectées par BCC32.

Pour plus d'informations, voir Erreurs et avertissements des compilateurs C++ améliorés par Clang.

Macros prédéfinies

Les compilateurs C++ amélioré par Clang vous permettent d'obtenir toutes les macros prédéfinies directement depuis le préprocesseur.

Macro RTLVersion

La RTLVersion n'est pas prise en charge par les compilateurs C++ améliorés par Clang. Vous pouvez utiliser à la place RTLVersionC.

Macro NO_STRICT

Le schéma de vérification de type NO_STRICT n'est pas pris en charge dans les compilateurs C++ améliorés par Clang. Si certains de vos projets existants utilisent la définition conditionnelle NO_STRICT, vous devez la retirer.

Pour de plus amples informations et instructions sur le retrait de NO_STRICT, voir : Les applications C++ utilisent le contrôle STRICT des types.

Recherches et chemins #include

Avec les compilateurs C++ améliorés par Clang, les en-têtes doivent être inclus (#include) différemment.

Par exemple, les compilateurs C++ améliorés par Clang ne trouvent pas les en-têtes spécifiés avec des chemins semi-absolus comme cela est le cas pour BCC32. Sachant que 'myOtherFile' est situé dans C/myProjectsDir/myOtherApp, les références suivantes dans un fichier .CPP sont acceptées par les compilateurs C++ améliorés par Clang et BCC32 : 

#include "c:/myProjectsDir/myApp/mySource.h" // Absolute path.
#include "../myApp/mySource.h" // Relative path.

Toutefois, le code suivant génère une erreur avec les compilateurs C++ améliorés par Clang mais est accepté par BCC32 : 

#include "/myProjectsDir/myApp/mySource.h" // Semi-absolute path.

Les compilateurs C++ améliorés par Clang émettent l'erreur suivante : 

[<compiler> Fatal Error] myOtherFile.cpp(27): '/myProject/myApp/mySource.h' file not found

Pour plus d'informations, voir Compilateurs C++ améliorés par Clang, Recherche et chemins #include.

En-têtes précompilés

Comparativement à BCC32, les en-têtes précompilés fonctionnent différemment avec les compilateurs C++ améliorés par Clang. Chaque projet C++ peut avoir un seul en-tête précompilé ; un en-tête précompilé par défaut (nommé projetPCHn.h) est généré pour chaque nouveau projet C++.

Pour plus d'informations, voir les rubriques suivantes :

Format des fichiers objet et bibliothèque

  • BCC32 et ses outils associés utilisent OMF dans les fichiers .obj et .lib.
  • Les compilateurs C++ basés sur Clang utilisent ELF dans les fichiers .o et .a.

Cette différence signifie, par exemple, que lorsque vous migrez des applications Windows 32 bits, vous devez changer les références aux fichiers .lib et .obj par respectivement .a et .o.

__property : Assignation chaînée et composée

Les compilateurs C++ améliorés par Clang prennent en charge l'assignation composée de __property, alors que BCC32 ne la prend pas en charge.

Les objets du mot clé __property ne ressemblent pas aux champs et aux membres. Ils doivent être utilisés dans les assignations simples.

Bien que BCC32 et les compilateurs C++ améliorés par Clang de RAD Studio permettent l'utilisation de __property dans les assignations composées telles que : 

Form1->Caption += DateToStr(Now());

BCC32 invoque uniquement l'accesseur en lecture, et pas l'accesseur en écriture. Par conséquent, nous vous recommandons d'éviter de telles constructions lors du ciblage de plates-formes multiples.

Aucun de ces compilateurs ne prend en charge l'usage de __property dans une assignation chaînée, comme dans : 

Button2->Caption = Button1->Caption = DateToStr(Now()); // Error

Extensions et mots clé BCC32 obsolètes

Les extensions de mots clé du compilateur sans trait de soulignement et avec un seul trait de soulignement sont soit obsolètes soit non prises en charge dans les compilateurs C++ améliorés par Clang. Utilisez les versions à double trait de soulignement (elles sont aussi prises en charge dans BCC32) :

  • cdecl, _cdecl :    utilisez __cdecl.
  • pascal, _pascal :    utilisez __pascal.
  • _fastcall :    utilisez __fastcall, qui est maintenant le style Microsoft, non le style Borland.
  • _stdcall :    utilisez __stdcall.
  • _fortran, __fortran :    non pris en charge, obsolète.
  • asm, _asm, __asm :     l'assembleur inline n'est pas pris en charge.
  • _export :    utilisez __export.
  • _import :    utilisez __import.
  • _declspec :    utilisez __declspec.

Attributs BCC32 non pris en charge

Voir Solution pour les attributs C++11 (noreturn et final).

Les identificateurs Unicode ne sont pas pris en charge

Même si Unicode est pris en charge dans les chaînes littérales et les noms de fichiers, Unicode n'est pas autorisé dans les identificateurs.

Assembleur inline

Les compilateurs C++ améliorés par Clang autorisent l'assembleur inline avec les réserves suivantes :

  • Il n'est pas possible de mélanger l'assembleur avec le code C++.
  • Ne pas toucher au pointeur de pile (RSP).
  • L'assembleur doit utiliser la syntaxe ligne-par-ligne AT&T, et non la syntaxe d'Intel par blocs, plus familière. Pour de plus amples informations, voir GCC-Inline-Assembly-HOWTO (EN).

Les compilateurs C++ améliorés par Clang prennent en charge l'assembleur inline dans un style différent de l'assembleur inline pris en charge par BCC32 :

  • Différences au niveau de la syntaxe de l'assembleur :
    La syntaxe de l'assembleur prise en charge par les compilateurs C++ améliorés par Clang est la syntaxe ligne-par-ligne AT&T, et non celle d'Intel par blocs, plus familière.
  • Problèmes potentiels relatifs au débogage et à la gestion des exceptions :
La gestion des exceptions du compilateur pose des limites supplémentaires concernant le code assembleur écrit manuellement et combiné avec C++. Les fonctions écrites entièrement en assembleur (avec un assembleur distinct tel que NASM (EN) ou MASM) peuvent être liées dans votre programme. Toutefois, il faut être conscient des problèmes inhérents potentiels (débogage et gestion des exceptions) avant de commencer.
Les raisons de ces problèmes relatifs à l'assembleur inline peuvent être résumées comme suit : pdata. L'absence de prise en charge de l'assembleur inline est assez courante. Pour que les exceptions et le débogage fonctionnent, le code doit générer des structures de données (pdata) qui décrivent chaque fonction et ce qui doit être extrait si une exception est déclenchée. Après l'insertion de l'assembleur inline, le compilateur ignore des détails infimes comme les espaces de pile supplémentaires alloués par l'assembleur inline. L'assembleur inline (c'est-à-dire la combinaison du code assembleur et C/C++) rend impossible la génération précise des structures pdata par le compilateur. Pour de plus amples informations sur pdata, voir http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx (EN).

Pour un exemple de code illustrant l'utilisation de l'assembleur inline avec un compilateur C++ amélioré par Clang, voir Assembleur inline et BCC64 (C++).

Pour plus d'informations sur l'assembleur et les compilateurs C++ améliorés par Clang, voir :

Les blocs try ne peuvent pas gérer certaines exceptions

Les exceptions synchrones sont des exceptions déclenchées à l'aide d'une instruction throw dans votre programme ou dans les bibliothèques utilisées par votre programme. Les compilateurs savent où et quand ces exceptions sont déclenchées.
Les exceptions asynchrones sont des exceptions qui proviennent du système d'exploitation et qui peuvent être déclenchées à tout moment, comme les divisions par zéro ou les violations d'accès.

Les langages C et C++ standard sont conçus pour gérer les exceptions synchrones seulement. Cependant, lorsque vos applications C++Builder établissent une liaison avec la RTL, vous ajoutez à vos applications la capacité d'intercepter également les exceptions asynchrones.

Toutefois, Clang est conçu pour les exceptions synchrones seulement, et ne prend pas en charge la gestion des exceptions d'absence d'appel. Si un bloc try ne contient aucune instruction throw ni aucun appel aux fonctions pouvant contenir des instructions throw, Clang ignore les blocs catch et __finally associés à ce bloc try. Cela signifie que si un bloc try ne peut pas déclencher une exception synchrone, vous ne pouvez pas non plus intercepter une exception asynchrone dans ce bloc try.

Par exemple : 

float a = 1;
float b = 0;
try {
    try {
        a = a / b;  // The RTL throws an asynchronous exception (division by zero).
    }
    __finally {
        // Execution never reaches this point.
    }
}
catch (...) {
    // Execution never reaches this point.
}

Au lieu d'intercepter ces exceptions spéciales que les compilateurs améliorés par Clang ne peuvent pas gérer, vous devez procéder de l'une des manières suivantes :

  • Déplacez le code pouvant déclencher une exception asynchrone vers sa propre fonction et appelez cette fonction à partir du bloc try.
  • Essayez d'empêcher que ces exceptions se déclenchent. Par exemple, vous pouvez contrôler la valeur de b avant d'effectuer la division.
Remarque : Si vous ne gérez pas les exceptions asynchrones, le gestionnaire d'exception par défaut du framework GUI de votre application les intercepte et votre application déclenche une exception externe EEFFACE.

Voir aussi

Récupérée de « http://docwiki.embarcadero.com/RADStudio/Seattle/f/index.php?title=Différences_entre_les_compilateurs_C%2B%2B_améliorés_par_Clang_et_les_compilateurs_C%2B%2B_de_précédente_génération&oldid=193091 »