Quali sono le mie opzioni per l'utilizzo di una libreria C ++ 11 in un'applicazione C # WPF? [chiuso]

5

Sto scrivendo un'applicazione desktop multipiattaforma (OS X e Windows) in C ++ 11. Intendo utilizzare lo stesso core C ++ 11 su entrambe le piattaforme, utilizzando framework nativi per l'interfaccia utente (Cocoa e Objective-C su OS X e WPF e C # su Windows) poiché ritengo che la migliore esperienza UX sia nativa.

Attualmente l'applicazione viene eseguita come app per console su entrambe le piattaforme. L'applicazione esegue un lavoro intensivo della CPU e fornisce callback per la segnalazione dell'avanzamento e, quando completa, crea un'istanza di una raccolta di elementi ( std::vector<std::unique_ptr<Item>> ) che rappresenta i risultati dell'elaborazione.

Il mio obiettivo è che la libreria C ++ 11 funga da modello per l'interfaccia utente in un modo compatibile con i modelli MVC e MVVM.

L'interfaccia utente deve:

  • Permetti all'utente di scegliere un file da elaborare (apri una finestra di dialogo file e invia il percorso del file alla libreria C ++)
  • Visualizza lo stato di avanzamento (gestisci i callback dalla libreria C ++ per aggiornare una barra di avanzamento)
  • Visualizza i risultati in un modulo WPF (accedi alla classe Item e visualizza le informazioni che fornisce)

Ho esaminato WinRT e sembra che non ci siano molte informazioni là fuori per l'uso nelle applicazioni desktop. Inoltre, non mi piace l'idea di creare l'interfaccia utente stessa in C ++. Il mio obiettivo è quello di ottenere dati dentro e fuori dall'app C ++ e utilizzare C # per gestire l'interfaccia utente poiché credo che sia un modo più efficiente di lavorare con WPF.

Sono a conoscenza di P / Invoke ma la mia comprensione è che funziona solo con un'interfaccia C. Creare una simile interfaccia attorno al C ++ 11 sembra complicato.

Sono anche a conoscenza di C ++ / CLI, ma non sono sicuro che soddisferà le mie esigenze o se è compatibile con C ++ 11.

Ho dato un'occhiata a CppSharp ma sembra essere un work-in-progress e dubito che saprei come per aggirare eventuali problemi che potrebbero sorgere.

Ho molta esperienza con C ++ e un po 'con C # ma non sono sicuro se mi mancano le opzioni migliori o quale dei precedenti è un approccio corretto.

    
posta Rotsiser Mho 16.02.2014 - 19:44
fonte

3 risposte

2

SWIG può generare C # wrapper per codice C ++. Non ho esperienza nell'usarlo per questo, quindi non so quanto bene funzioni.

Credo che l'attuale versione di SWIG (versione 2.x) abbia almeno qualche supporto per C ++ 11, ma potrebbe essere necessario utilizzare versione di sviluppo per supporto completo.

    
risposta data 17.02.2014 - 14:34
fonte
1

Una parte di una risposta ...

La maggior parte delle volte nella soluzione di questo problema finirai con 3 livelli.

  1. Un livello C / C ++ nativo, che può chiamare l'API di Windows o le librerie COM o C ++
  2. Un livello C / C ++ gestito, che può accedere al modello di oggetto C # e al framework
  3. Un livello C #, perché è più facile utilizzare effettivamente .NET Framework e WPF in C #.

P / Invoke fa riferimento alle chiamate tra codice nativo e codice gestito, ma in questo tipo di struttura avvengono all'interno del livello (2). Il livello (2) era gestito da C ++ ma ora è sostituito da C ++ / CLI. Ciascuno dei livelli può parlare facilmente con quello adiacente, ma (1) non parla facilmente con (3) o viceversa.

Potresti trovare un prodotto che fa esattamente ciò che vuoi, ma non ne conosco uno. Più probabilmente dovrai scrivere ciò che ti serve con questo tipo di struttura a strati.

Ho fatto questo più di 3 volte con 3+ diverse generazioni di Managed C / C ++, e abbiamo un prodotto commerciale costruito in questo modo (legacy C / C ++ < = > ASP.NET/remoting). Ogni generazione del livello gestito è diversa ma la struttura generale è rimasta la stessa. [Modifica]

Suggerisco di scrivere del codice, ma ho intenzione di buttarlo via. La sperimentazione è in ordine.

    
risposta data 17.02.2014 - 15:03
fonte
0

Che cos'è un'interfaccia utente nativa su Windows? WPF non sembra "standard", winform e MFC sono morti, come Silverlight. Si potrebbe dire che la maggior parte delle app native sono ora HTML, specialmente se si scrivono i tiles di Windows8.

Quindi il mio suggerimento sarebbe quello di utilizzare wxWidgets che utilizza i controlli nativi per il rendering. L'interfaccia utente sarà simile a un programma Windows tradizionale piuttosto che a uno "Moderno", ma è quello che cercavi, vero?

Se hai ancora bisogno di usare WPF per la GUI, puoi scrivere un wrapper di interfaccia C ++ / CLI che chiama la tua DLL C ++, o potresti esporre la tua dll come servizio e lasciare che WPF faccia socket (o altro RPC) chiama in esso. Se è molto loquace, questa non sarebbe la soluzione migliore, ma se fa poche chiamate di lunga durata è il suo ideale. Un servizio sarebbe anche la soluzione migliore per associare un front-end Web alla tua DLL, anche se esporresti il servizio come WWS web service in questo caso.

    
risposta data 18.02.2014 - 09:49
fonte

Leggi altre domande sui tag