2009-09-01 7 views

Répondre

2

En général cela est vraiment dur, parce que C++ offrent des fonctionnalités différentes que C#: modèles, des amis, des chaînes terminées par zéro, pointeurs non gérés, COM, etc., pour ne pas mentionner que l'analyse syntaxique C++ est une chienne de un travail. Pour ce faire, vous avez besoin d'un analyseur C++ complet avec résolution de nom et de type, un ensemble d'idées sur la façon de convertir chaque construction (problématique ou non) en code C# équivalent, un moyen d'encoder ces idées en étapes de traduction automatique , et un plan pour ce qu'il faut faire avec les parties du code qui ne se traduisent pas bien (typiquement, "réparer à la main").

Utilisation du DMS Software Reengineering Toolkit, qui fournit toutes les machines nécessaires, mon entreprise, Semantic Designs, en fait construit un tel outil, mais jamais utilisé, pour un gros client qui voulait déplacer 800K SLOC de C++ en C#. Au cours des deux tiers du projet, le client a procédé à un remaniement de la gestion des cages à oiseaux et les nouveaux gestionnaires ont décidé de ne pas procéder à des économies (l'outil lui-même fonctionnait bien).

+0

semble intéressant :) –

+0

Comment maintenable et idiomatique était le code résultant? J'ai passé du temps dans une base de code traduite par machine et j'aurais préféré utiliser la langue d'origine. Si "les vrais programmeurs sont capables d'écrire FORTRAN dans n'importe quelle langue", la traduction automatique de FORTRAN réussit à atteindre cet "objectif" très bien. – AProgrammer

+0

Il est facile de construire un mauvais traducteur: il suffit de mapper directement les opérateurs langauge individuels à la langue cible sans tenir compte du contexte. Tandis que vous devez mapper des constructions de langauge, vous pouvez le faire en tenant compte du contexte (DMS est capable de rassembler des faits à travers l'application et de les utiliser pour contrôler ce qui est généré à chaque point) et vous pouvez post-optimiser le résultat traduit. Les deux techniques rendent le code beaucoup plus facile à maintenir. –

1

Est-ce que tout ce dont vous avez besoin est une déclaration de cette API? Il y a un outil appelé PInvoke Interop Assistant que vous pouvez utiliser, mais personnellement, je préfère l'approche DIY. Ce n'est pas si dur.

Essayez les définitions suivantes

struct EFS_CERTIFICATE_BLOB 
{ 
    public int dwCertEncodingType; 
    public int cbData; 
    public IntPtr pbData; 
} 

struct ENCRYPTION_CERTIFICATE 
{ 
    public int cbTotalLength; 
    public IntPtr pUserSid; 
    public IntPtr pCertBlob; 
} 

struct ENCRYPTION_CERTIFICATE_LIST 
{ 
    public int nUsers; 
    public IntPtr pUsers; 
} 

[DllImport("advapi32.dll", CharSet=CharSet.Unicode)] 
static extern uint AddUsersToEncryptedFile(string lpFileName, ref ENCRYPTION_CERTIFICATE_LIST pUsers); 
+0

@Mattias s - la liste complète du code est sur ce site: http://msdn.microsoft.com/fr-fr/library/aa363765(VS.85).aspx –

1

Si vous portage du code C++ pour C#, alors vous devriez peut-être envisager de convertir le code C++ non géré à C++/CLI. Vous pouvez alors commencer à transférer vers C# dans un manoir plus contrôlé (c'est-à-dire par un morceau à la fois - idéalement testé à l'unité comme vous allez). Une alternative à la conversion en C++/CLI serait d'envelopper votre code C++ non géré existant en utilisant SWIG, mais la migration sera rendue plus difficile en utilisant cette méthode.