2009-11-20 8 views
1

Je suppose que vous ne pouvez pas simplement compiler une application C++ avec un compilateur C++/CLI. Je me demande si ce serait difficile. Est-ce que quelqu'un a essayé cela, et si oui: y avait-il beaucoup de modifications nécessaires?Est-il difficile de porter C++ en C++/CLI?

+0

Copie possible: http://stackoverflow.com/questions/704388/please-description-vous-expertise-de-l'utilisation-microsoft-c-cli –

+0

@Kirill - Err ... no. Pas même proche. –

Répondre

5

La situation est un peu comme la compilation de C en C++. La plus grande partie de C sera compilée en C++, mais elle est loin de ce que l'on pourrait considérer comme un exemple de C++. Il est donc probable que vous voudriez le modifier (souvent un peu) avant de l'utiliser.

De même, la plupart des C++ seront compilés en C++/CLI, mais il est probable que vous préférez ne pas l'utiliser de cette façon.

2

Cela fonctionnera bien pour presque n'importe quel code C++ natif. Il sera traduit en IL, tout comme le code managé, et compilera JIT à l'exécution. Vous pouvez appeler librement du code managé, grâce à C++ interop. La seule construction de code non managée que je sais qui ne peut pas être compilée est le mot clé __fastcall. Il y a un problème avec le mot-clé const, il est imparfaitement simulé avec des attributs, mais c'est seulement un problème lorsque vous importez des métadonnées. Continuez à utiliser des fichiers d'en-tête comme vous le faites maintenant. Un ensemble .NET est capable de stocker le code machine ainsi que l'IL. Vous pouvez en profiter en désactivant sélectivement la génération IL pour les cas où le compilateur a des problèmes ou lorsque vous pensez que le code généré n'est pas optimal. Enveloppez votre code avec un #pragma:

#pragma managed(push,off) 
void CompiledToMachineCode() { 
    // etc.. 
} 
#pragma managed(pop) 

Vous devrez également utiliser ce #pragma lorsque vous #include les en-têtes pour .libs qui ont été compilés séparément sans l'option/compiler clr.

Questions connexes