2011-09-23 9 views
6

Ho una base di codice piuttosto grande che è altamente modulare (molti e molti plugin) e molto spesso è necessario passare stringhe e così via tra i moduli. Per riferimento, il codice:Passaggio di oggetti STL e/o MFC tra i moduli

  • compila solo in MSVC/Visual Studio e molto chiaramente non supporta e non supporta altri compilatori. Sostenerli non è una preoccupazione.
  • funziona solo su Windows e molto chiaramente non supporta e non supporta altri sistemi operativi. Come sopra.
  • tutti i moduli saranno PE di Windows di qualche tipo; assumere la stessa identità e che sono costruiti per la stessa piattaforma.
  • ci sono alcuni punti in cui MFC è più facile da usare, alcuni in cui STL è. Ci sono ottime possibilità che entrambi verranno utilizzati all'interno di ciascun modulo.
  • La domanda è solo per il passaggio degli oggetti tra i moduli.

Ora, ho l'impressione che il passaggio degli oggetti STL tra i moduli possa realmente interrompersi, se la libreria o il versatore del compilatore cambiano. In particolare quando si tratta di dvd e di oggetti distrutti al di fuori del modulo/versione in cui sono stati creati.

MFC è più sicuro in questo modo? È possibile passare un oggetto MFC (ad esempio CString) da Base.dll a Plugin.dll in modo sicuro? Devi passare un puntatore, non puoi cancellarlo tranquillamente dal plugin?

È importante se MFC è collegato o utilizzato in modo statico da una DLL?

MSDN menziona in alcuni posti che:

Tutte le allocazioni di memoria all'interno di una DLL regolare dovrebbero rimanere all'interno della DLL; la DLL non deve passare o ricevere dalla chiamata eseguibile uno dei seguenti:

  • puntatori a MFC oggetti
  • puntatori a memoria allocata da MFC

Se avete bisogno di fare una qualsiasi delle sopra, o se è necessario passare oggetti derivati ​​da MFC tra l'eseguibile chiamante e la DLL, è necessario creare un'estensione DLL.

Tuttavia, the page extension DLLs menzionano che sono destinati principalmente agli oggetti implementati derivati ​​da oggetti MFC. Non ho alcun interesse a farlo, basta usarli e passare tra vari moduli.

Il passaggio di shared_ptrs modifica qualcosa (o una classe con un virtual dtor)?

Esiste una soluzione a questo senza ricorrere ai tipi C?

risposta

4

Un'estensione DLL condividerà la DLL MFC con l'applicazione e qualsiasi altra DLL di estensione, in modo che gli oggetti possano essere passati liberamente tra di loro. Microsoft potrebbe aver inteso che le DLL di estensione implementassero classi estese, ma questo non è un requisito: puoi usarlo come preferisci.

Il più grande pericolo con la libreria standard è che gran parte di esso si basa su modelli.Questo è pericoloso, perché se la DLL e l'applicazione sono costruite con versioni diverse dei modelli che si eseguono contro la regola One Definition e il comportamento indefinito si morde nella parte posteriore. Questo non è solo l'inizializzazione o la distruzione dell'oggetto, ma qualsiasi operazione contro l'oggetto qualunque!

+0

La mia comprensione è che facendo un'estensione MFC è necessario che il client (qualunque eseguibile utilizzi le DLL?) Debba utilizzare anche MFC e la stessa versione. Sembra che escluderebbe l'aggiornamento di una DLL e l'utilizzo di MFC se il client non lo utilizzava in origine. È corretto? Sembra una buona soluzione, altrimenti. – ssube

+0

@peachykeen, sì l'app deve utilizzare MFC. E sì, dovrebbe essere la stessa versione di quella usata dalla DLL, ma non sono sicuro delle conseguenze di una mancata corrispondenza: MFC tende ad evolversi meno rapidamente rispetto alla libreria C++, e poiché nessuna di esse è basata su modelli I Non sono sicuro delle incompatibilità dalla versione alla versione. –

0

È possibile dichiarare interfacce solo come metodo di abstruzione COM e passare invece l'interfaccia. Ad esempio, scrivi un metodo factory come WMCreateReader che crea un oggetto (che sia basato su MFC o che i membri STL non abbiano bisogno di essere esposto al chiamante) e restituisca la sua interfaccia.

+0

Uso già parecchie interfacce per il passaggio di oggetti e la conoscenza di ciò che un plugin mostrerà; come risolve il passaggio, ad esempio, agli archi? – ssube

+0

Passali come BSTR, probabilmente? –

Problemi correlati