VC ++ Biblioteca scontrandosi Problema

Question

Sto lavorando su un progetto C ++ che utilizza Qt (GUI lib), VTK (lib grafica) e un'altra libreria che è così oscuro che non menzionerò il suo nome e sarà invece chiamarlo LIB_X. Il progetto utilizza Qt per i componenti dell'interfaccia grafica e VTK (più precisamente l'estensione QVTKWidget fornito da VTK che supporta Qt) per il rendering della geometria .. e usa LIB_X per raccogliere e manipolare la geometria.

Il problema è che si scopre che in realtà usa LIB_X VTK (dove e come, non so, è closed source). In un primo momento non c'era nessun problema, la compilazione con entrambe le librerie collegate stava andando bene, ma ad un certo punto ho chiamato un certo (ed estremamente necessario) la funzione LIB_X e alla compilazione ha portato ad una serie di 'bla bla qualcosa su un lib VTK / obj già definite in errori LIB_X DLL'.

es. (E notare che questo è con / FORCE: MULTIPLE quindi è un avvertimento qui, fatemi sapere se si desidera che l'errore senza / FORCE: MULTIPLE e post-it):

1>LIB_X.lib(LIB_X.dll) : warning LNK4006: "public: __thiscall std::vector<double,class std::allocator<double> >::~vector<double,class std::allocator<double> >(void)" (??1?$vector@NV?$allocator@N@std@@@std@@QAE@XZ) already defined in vtkCommon.lib(vtkInformationDoubleVectorKey.obj);

Ho provato ad utilizzare / FORCE: MULTIPLE e sembrava di essere un miracolo in un primo momento, ma sto ottenendo errori casuali in codice che la maggior parte dare errori di heap. Ho deciso di rimuovere tutti i riferimenti a LIB_X dal progetto principale e creato un lib statica che avrebbe gestito tutte le cose LIB_X. Io non sono un esperto di C ++, quindi non sono certo come gestisce scontro lib quando si utilizza un lib pre-compilato, ma ho ancora ricevuto gli errori contrastanti lib quando si collega la mia lib statica nel mio progetto principale, così ho ancora è necessario utilizzare / FORCE: MULTIPLE.

Una volta ho avuto la statica lib sembrava che gli errori casuali erano andati via, sono stato in grado di fare molto con i metodi LIB_X nel progetto principale attraverso il lib statica, ma dal nulla, ho aggiunto un nuovo membro di dati classe di mio progetto principale (uno std :: vector di doppie) e improvvisamente mi è stato sempre un errore di heap in uno dei metodi di mia libreria statica. Se ho commentato il nuovo membro di dati, il metodo della libreria statica sarebbe funzionare bene. Odio dare l'errore corrente, perché onestamente non sono sicuro se esaminando sarà utile, ma qui è comunque nel caso in cui esso può aiutare:

Nota: si blocca a xutility sulla sulla linea 151, si apre l'affermazione: "File: Linea dbgheap.c: espressione 1279: _CrtIsValidHeapPointer (pUserData)"

L'errore arriva dopo l'aggiunta di un doppio vettore vettore ad un vettore doppia vettore vettore, schiantarsi sulla linea push_back:

std::vector<std::vector<double>> tmpVec;
for(srvl_iter = srvl.begin(); srvl_iter != srvl.end(); ++srvl_iter)
{
 tmpVec.push_back((*srvl_iter).getControlPoints());
}
this->_splines.push_back(tmpVec); //CRASH

E 'iniziato solo crash qui quando ho aggiunto un nuovo membro di dati al mio progetto principale (separata dalla lib statica!) Commentando il nuovo membro dei dati richiede l'errore di distanza.

std::vector<std::vector<std::vector<double>>> _geometry; 

Quindi, / FORCE: MULTIPLE sembra male, ricevo errori casuali che proprio non hanno senso per me. Ci sono altre soluzioni? Sto fregato? C'è qualcosa che posso fare con collegati LIB_X di VTK?

Answer 1

ho incontrato un sacco di errori LNK4006 quando si collega la mia applicazione ad una libreria (chiamarlo LIB_Y biblioteca) che ha fatto un uso pesante di std::vector<std::string>, che ho fatto anche nella mia app. Dopo un po 'di esperimenti ho trovato uno soluzione che ha funzionato -. Avvolgere LIB_Y in una DLL separata che chiama LIB_Y (LIB_Y_WRAPPER, per esempio), e quindi collegare l'applicazione principale contro LIB_Y_WRAPPER

Per provare il mio suggerimento è necessario:

1. Cambia la tua "lib statica che gestisce tutte le cose LIB_X" da un progetto LIB statica in un progetto DLL (che chiamerò LIB_X_WRAPPER).
2. Assicurarsi che i file di intestazione di LIB_X_WRAPPER non includono nessuno dei file di intestazione LIB_X. Si tratta di veramente importante , perché l'involucro ha bisogno di isolare completamente la vostra applicazione dai tipi di dati dichiarati nei file di intestazione LIB_X (come std::vector<double>). si riferiscono solo ai file header di LIB_X dall'interno i file sorgente del LIB_X_WRAPPER.
3. Cambiare la dichiarazione di tutte le classi e le funzioni nel lib statica per assicurare che siano esportati dalla DLL (vedi questa risposta se avete bisogno di informazioni sull'esportazione da una DLL).

Questa soluzione ha funzionato per me perché continuava l'istanza (funzioni del compilatore generato) della classe std::vector<std::string> usata da LIBY completamente separato dalla istanza di std::vector<std::string> nella mia app.

Per inciso, ho il sospetto che la causa dello schianto si sta vedendo (si commento è nel distruttore di std::vector<double>) è perché l'istanza di std::vector<double> nella tua app è diverso da quello in LIB_X.

Answer 2

Il commentando è probabilmente fortuna semplicemente casuale -. Se si sta corrompendo il mucchio che non sempre vede subito, ma un vettore STL sarà allocare e cose deallocare a sinistra ea destra in modo non c'è da meravigliarsi è trovare l'errore

Alcune librerie richiedono di includere le cose in un certo ordine. Io non sono sicuro perché esattamente perché a me sembra rinunciare e dicendo che non si può progettare una biblioteca correttamente, ma è il fatto triste. Fino a quando non si include questo lib_x da nessuna parte che si include vtk dovrebbe andare bene, però.

Tuttavia, essi potrebbero essere in lotta per qualche risorsa o utilizzando impropriamente qualcosa che rende impossibile per loro di lavorare insieme. Se siete in grado di ottenere la compilazione funzionare bene da loro separazione e non riesce ancora allora sì si sono solo fuori di fortuna perché è solo un difetto nel modo in cui questo lib_x è stato progettato e dato che è così oscura non è probabile che sia stato accuratamente il debug contro tutti gli usi. Quando qualcosa non è ampiamente utilizzato di solito finisce per essere qualcosa che funziona sulla macchina ed il progetto dello sviluppatore, ma non necessariamente di chiunque altro.