Microsoft ha ancora limitazioni del contenitore C ++ quando passa alle DLL? [duplicare]

3

Microsoft ha avuto una discreta quantità di problemi in passato quando ha passato container STL come puntatori a stringa e vettoriali e riferimenti a DLL. Vedere, ad esempio, È possibile che si verifichi una violazione di accesso quando si accede a un oggetto STL tramite un puntatore o un riferimento in una DLL diversa o EXE .

Domanda : i tipi di problemi sono ancora presenti oggi in Visual Studio 2010 e 2013?

So che la domanda è un po 'aperta. Sto chiedendo perché li ho sperimentati in passato, sto lavorando a un nuovo design, il progetto potrebbe includere un'architettura di plugin e vorrei passare una stringa o un riferimento vettoriale a una DLL di plugin. Se i problemi continuano ad affliggere Microsoft, allora devo cambiare il design (o trovare una soluzione alternativa per evitare l'arresto anomalo).

Correlato, L'indirizzo del C ++ 11 riguardava problemi nel passaggio di oggetti lib std tra i contorni di librerie dinamiche / condivise? è simile ( grazie per il link). Ma in realtà non risponde alla domanda, anche se sembra riconoscere lo stesso problema.

Inoltre, KB di Microsoft Q168958, Come esportare un'istanza di una classe STL (Standard Template Library) e una classe che contiene un membro dati che è un oggetto STL , implica che può essere fatto. Ma è più o meno il momento in cui ricordo di avere i problemi, quindi sono curioso di sapere se si applica ancora (e se funziona attualmente in Visual Studio 2010 o 2013).

Il problema che sto incontrando è stato evidenziato da Robert e Doc: posso verificare la presenza di bug, ma non l'assenza di essi. Quindi potrei non essere in grado di innescare problemi durante i test, ma i problemi potrebbero realmente esistere (e risalire al momento peggiore).

    
posta jww 08.04.2015 - 06:57
fonte

1 risposta

4

Esporta un'interfaccia C.

Non solo risolve il problema della DLL, ma consente plugin in lingue diverse dal C ++.

Quindi scrivi un wrapper C ++ per l'API C come libreria solo .

Non è possibile utilizzare oggetti di layout non standard C ++ nell'API perché non esiste un ABI standard per loro, quindi è necessario che la libreria e gli utenti vengano compilati con lo stesso compilatore e librerie. Ciò è particolarmente negativo per i plugin: è un problema minore per le librerie in quanto l'utente della libreria può collegare staticamente la libreria con l'eseguibile, o almeno raggruppare i due in un singolo programma di installazione.

Si noti che un oggetto non POD può ancora essere un layout standard, a partire da C ++ 11.

    
risposta data 08.04.2015 - 15:15
fonte

Leggi altre domande sui tag