2009-12-31 16 views
5

Quindi sto architettando un'applicazione che fa necessariamente C++, ma MFC/ATL è troppo disordinato per i miei gusti, quindi ho avuto questa brillante idea di fare tutto il codice "pensante" in C++ nativo e tutto il bel codice UI in C#. Il problema, tuttavia, è l'interoperabilità tra loro due. Prima che me ne vada troppo, mi chiedevo se si tratta di un problema risolto, e c'è un ottimo modo per farlo. Si noti che non voglio combinare la logica e la visualizzazione nello stesso modulo, in quanto genera un accoppiamento fastidiosamente alto.Native C++ e C# interop

Ecco quello che ho finora:

enter image description here

Allora dimmi, si può fare meglio?

+0

Perché deve essere C++? – SLaks

+1

Perché esiste una base di codice esistente che espone un'API C++ ed è la mia lingua franca. Sarei perso senza i miei suggerimenti. –

risposta

11

Il modo più semplice per gestire ciò è utilizzare C++/CLI ed esporre la logica come tipi .NET.

È molto semplice racchiudere una classe C++ nativa in un ref class che è utilizzabile direttamente da un'interfaccia utente C#.

Detto questo, questo era il mio piano, in origine, nel mio attuale progetto. Pensavo che avrei avuto bisogno del codice nativo per alcuni dei pesanti lavori di matematica che facciamo tipicamente. Ho scoperto, tuttavia, che è stato più facile, più veloce e più bello spostare la maggior parte della mia logica direttamente in C# (separata dal codice UI, ma ancora in un assembly C#) piuttosto che provare a implementarla in C++.

La mia esperienza è stata che la velocità non è stata un problema: il codice C# non sicuro è quasi sempre riuscito ad essere più veloce o più veloce del C++ equivoco quando sintonizzato, ed è più facile profilare e sintonizzare il codice C#.

+0

Quindi il codice wrapper che ho inserito in Proxy.dll è praticamente la stessa strategia? Posso considerare questo come un "mi sembra buono"? –

+0

Per quanto riguarda l'interfaccia .NET/C++ del tuo diagramma, sì, sembra buono. Ho fatto questo stesso genere di cose con una base di codice C++ esistente in cui volevo fare la GUI in C#. – AaronLS

+0

Anch'io ho riscritto il codice C in C# e sono stato molto soddisfatto delle prestazioni che ho visto. Dovrebbe essere un'applicazione molto intensiva del processore per non accorgersene. –

1

Si può avere una buona ragione perché il core sia una DLL. Ma non è necessario. Ho avuto successo con un'applicazione C++, crea un dominio App e carica un assembly in esso, quindi crea un'istanza di un oggetto nel dominio dell'app e lo chiama, passando un'interfaccia all'applicazione. Questo è fondamentalmente ciò che fa il C-runtime quando si crea un'app non gestita.

L'interfaccia che il codice C++ espone al codice C# è definita in C#. Penso che sia più facile che definire gli interi in puro COM. C# interop ti offre un maggiore controllo del marshalling rispetto a C++.

  • creare un file app_interface.cs che definisce l'interfaccia
  • compilare app_interface.cs in una DLL, non ci preoccupiamo per la dll. abbiamo bisogno della libreria dei tipi.
  • nel codice C++ #import <app_interface.tlb> raw_interfaces_only questo trasforma la libreria dei tipi in un C++ .h file con definizioni di interfaccia: app_interface.tlh
  • implementare le interfacce

si può cospargere i tuoi app_interface.cs con gli attributi che controllano lo smistamento così

[ComVisible(true)] 
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] 
[Guid("ffffffff-ffff-ffff-ffff-ffffffffffff")] // guid changed from what I really use 
public interface IMyHostApplication 
{ 
    ... 

    void AddErrorDetails (
     [MarshalAs(UnmanagedType.Error)] uint hr, 
     [MarshalAs(UnmanagedType.LPWStr)] string szErrDetails); 

    ... 
} 
+0

Mi piacerebbe separare il codice C++ dal codice C# il più possibile, mantenendo l'area della superficie al minimo. Inoltre, non voglio pensare al codice gestito mentre sto facendo il nativo. –

+0

Il punto principale è che quando si inizia da zero è più semplice definire l'intefaccia tra le due parti in C# dall'inizio. #import garantisce che ciò che C++ e C# vedono come la definizione dell'interfaccia provengono entrambi da un singolo file. –

+0

Non importa come lo fai, dovresti assolutamente provare a minimizzare la superficie dell'interfaccia tra C++ e C# –

Problemi correlati