Le code ISO C++ est-il directement compilable en C++/CLI?

Question

Je veux écrire du code de bibliothèque à partager entre les produits et entre les plates-formes, y compris OS X et .Net.

Mes recherches actuelles suggèrent que l'écriture de ce code de bibliothèque de base en C++ est une bonne approche. Évidemment, je pourrais aussi utiliser Java mais ce n'est pas mon fort - je préfère rester avec ObjC/C++/C# où je peux. Je crois que C++/CLI est le choix courant pour C++ dans .Net ainsi ma question est; est C++/CLI un surensemble strict de 'vanille' ISO C++? En d'autres termes, si j'écris du code C++ compilant sous gcc, par exemple, puis-je le compiler sans changement (ou avec quelques compilations conditionnelles) sous C++/CLI? Il va de soi que je devrais écrire des enveloppes autour des fonctions du système, des E/S etc. - c'est très bien - mais je veux que le code algorithmique de base soit aussi portable que possible.

Answer 1

Dans la plupart des cas, mais pas nécessairement. Par exemple, le STL/CLR est hideusement lent par rapport à la BCL, et certaines choses comme nullptr se réfèrent au nullptr managé, pas au nullptr natif. Même si votre application est compilée proprement pour .NET, cela ne fait pas la bonne chose à faire.

Il serait beaucoup plus raisonnable de compiler le côté natif vers une DLL et ensuite P/Invoke de C# si vous devez offrir une interface gérée. Ce sera beaucoup plus fiable.

Answer 2

Si vous utilisez simplement C#, vous pouvez compter sur Mono pour fournir des fonctionnalités multiplates-formes. Une alternative pourrait être de fournir C# et une version C++ native et portable.

Si vous avez vraiment besoin d'une version de code managé en dehors de Windows, j'utiliserais Java. Apprendre Java est beaucoup plus utile que C++/CLI, et le portage en Java à partir de C# n'est pas une science de fusée.

Je voudrais éviter C++/CLI à moins que vous absolument devez le faire pour un client riche/important.

La priorisation des implémentations devrait dépendre des exigences du marché.

Answer 3

NO ne pourra probablement pas

• Selon la documentation MSDN il sera. Mais c'est un vilain mensonge. Je suis tombé dans ce piège. Quand des milliers de LOC ont été écrits, il s'est avéré que CLI a des problèmes avec boost :: thread. Ce dernier ne fonctionne tout simplement pas. Donc, je suppose qu'il peut y avoir d'autres choses aussi. Alors, n'y allez pas, c'est mon bon conseil.
• Même sans CLI, vous ne pouvez pas supposer que tout ce qui compile avec gcc sera compilé avec MSVC, car ce dernier a de nombreux problèmes de conformité ISO. Pire, les deux peuvent se compiler mais fonctionner différemment. Microsoft suce si fort ... mais leur IDE est juste superbe :)