Introduction au monde du C++/CLI

Un objet est managé (managed) lorsque son allocation et sa désallocation sont prises en charge par le CLR. Ce mot est utilisé un peu à toutes les sauces, à défaut d'en avoir des plus explicites. Par exemple, il faudrait plutôt parler de C++/CLI plutôt que de C++ managé.

Un objet est non managé (unmanaged) lorsque son allocation et sa désallocation sont prises en charge par le CRT (malloc).

Pour interagir entièrement avec des objets managés quel que soit le langage dans lequel ils ont été implémentés, les objets managés ne doivent exposer aux appelants que les fonctionnalités qui sont communes à tous les langages avec lesquels ils doivent fonctionner.
Pour cette raison, un ensemble de fonctionnalités de langage appelé spécification CLS (Common Language Specification), qui comprend les fonctionnalités de langage de base nécessaires à de nombreuses applications, a été défini.
La spécification CLS permet d'optimiser et d'assurer l'interopérabilité des langages en définissant un ensemble de fonctionnalités sur lequel les développeurs peuvent compter dans de nombreux langages. La spécification CLS établit également des exigences de conformité CLS ; elles vous permettent de déterminer si votre code managé est conforme à la spécification CLS et dans quelle mesure un outil donné prend en charge le développement du code managé qui utilise des fonctionnalités CLS.

Si votre composant n'utilise que des fonctionnalités CLS dans des interfaces API qu'il expose à un autre code (y compris des classes dérivées), le composant est assuré d'être accessible à partir d'un langage de programmation prenant en charge la spécification CLS.

Il est important de comprendre que le respect du CLS augmente la sécurité de votre programme.

Afin que des classes définies dans plusieurs langages puissent communiquer entres elles, elles ont besoin d'un ensemble de types de données communs. C'est l'objet du CTS, il définit les types de données que le Runtime .NET comprend et que les applications .NET peuvent utiliser.

On l'appelle aussi le runtime .NET. Le CLR est le moteur d'exécution du noyau .Net pour exécuter des applications. Il apporte des services tels que la sécurité d'accès de code, la gestion de la vie d'un objet, la gestion des ressources, la sûreté des types, etc.

Dans le contexte de C++/CLI, cela correspond à du C++ pouvant interagir avec le CLR.

C'est un jeu d'instruction indépendant du CPU généré par les compilateurs .NET, à partir de langages comme le J#, C# ou Visual Basic. Le langage MSIL est compilé avant ou pendant l'exécution du programme par le VES (Virtual Execution System), qui fait partie intégrante du CLR.

Le premier mode (sans option /clr) est, vous l'aurez compris, le mode classique qui ne permet pas d'utiliser les extensions managées du framework .net. Le compilateur génère uniquement du langage machine dans ce mode-là.
Autrement dit, le compilateur va générer un exécutable Win32 classique, indépendant de .Net qui ne pourra donc pas accéder aux fonctions des bibliothèques du framework .Net.

Cette option /clr permet de compiler du code C++ dans un mode mixte. C'est-à-dire que nous pourrons faire cohabiter du code natif avec du code managé. Le compilateur génère alors du MSIL. À partir du moment où on utilise un mode de compilation qui utilise /clr, le compilateur génère uniquement du MSIL.
Plus précisément, il pourra générer du langage machine lorsqu'il ne saura pas générer de MSIL, mais il génère prioritairement du MSIL.
La principale force de ce mode mixte est ce qu'on appelle IJW (It Just Work). Ce concept représente la capacité du compilateur à créer un exécutable « managé » à partir d'une application non managée. Plus de détails sur IJW et sur la capacité de mixer du code managé et du code natif.

On utilise /clr:pure lorsque l'on n'utilise aucune classe non managée dans son application. Ce mode empêche la compilation de code natif, mais autorise l'écriture de code qui dérogerait aux règles du CLS. Ce mode ne permet pas d'utiliser la technologie IJW.
Un des avantages de /clr:pure est que le code est sûr et possédant des performances meilleures qu'avec /clr uniquement. En effet, les assemblys purs contiennent uniquement du MSIL, il n'y a pas de fonctions natives et, par conséquent, aucune transition managée/non managée n'est nécessaire (hors appels P/Invoke).

Le mode /clr:safe génère des assemblys vérifiables, en se conformant aux exigences du CLS qui permettent au Common Language Runtime (CLR) de garantir que le code ne viole aucun paramètre de sécurité actuel.

Sachez dès à présent que les futures versions de Windows exigeront de plus en plus que les composants et les applications soient vérifiables ; donc, commencer à écrire ses assemblys en mode /clr:safe est une bonne idée. (Par contre, cela rend impossible l'interopérabilité).

Le mode /clr:oldsyntax est utilisé pour avoir une compatibilité avec les extensions managées du framework 1.x. Il est utile pour migrer en douceur son code pour se conformer à la syntaxe du framework 2.0. Cette syntaxe indigeste est à bannir au plus vite et à remplacer avantageusement par l'utilisation du C++/CLI.

Un type ref est un type CLI qui est alloué sur le heap managé. Il est pris complètement en charge par le garbage collector qui gère sa désallocation quand il n'est plus utile.
Le mot clé ref permet de créer donc des objets managés ou des structures managées (on utilise alors ref class ou bien ref struct).

ref class CMaClasse
{
    CMaClasse(void);
    ~CMyClass(void);
    bool maFonction();    
    String ^ monAttributChaine;
};

Un type de valeur (value type) est un type CLI qui est alloué sur la pile et qui est détruit lorsqu'il sort de sa portée. Il se comporte essentiellement comme un type POD (Plain Old Data : un type POD est un type C++ qui possède un équivalent en C. Il correspond aux types composés à partir des types primitifs).

On ne peut pas hériter d'un type de valeur. Ils n'ont pas non plus de constructeur par défaut, de destructeur, d'opérateur de copie ou d'affectation.
Lorsque l'on conçoit un objet qui fonctionne comme un type natif (un int par exemple), alors cette classe est une candidate parfaite pour un type de valeur.
Pour créer un type de valeur, on utilise alors value class ou bien value struct.

value class MonTypeDeValeur { 
    String^ uneChaine; 
    String^ uneAutreChaine; 
};

Remarque
- Les types de valeurs ont été créés pour permettre une copie rapide et efficace de données, sans utiliser d'indirections de mémoire inutile pour y accéder (pas besoin d'une place mémoire dans le garbage collector et d'une place mémoire pour le handle le référençant). Ainsi, le type de mémoire n'est pas stocké sur le heap managé et permet d'éviter l'encombrement du garbage collector. Ils bénéficient de même des optimisations de registre.
- Sans les types de valeurs, .Net aurait été beaucoup trop lent face à ses concurrents Java et C++, même pour des petits projets.
Cependant, il faut noter que lors de la phase d'optimisation du compilateur, celui-ci peut décider lui même si le type de valeur aurait été un meilleur choix qu'un type de référence et choisir ainsi le meilleur emplacement pour ce type, dans la plupart des cas.
- On utilise l'expression « types managés » ou « objets managés » par abus de langage. Il est plus correct de parler de types CLI.

Il est en général recommandé pour le CLS d'utiliser des structures pour les types de valeurs et des classes pour les types de références.