2011-10-12 13 views
6

Come sviluppatore di librerie, voglio impedire ai miei utenti di librerie (Windows, MSVC) di collegarsi alla configurazione sbagliata (non collegare la libreria di debug ai loro programmi di rilascio e viceversa).Previene il missaggio di librerie di debug e release

E 'possibile avvisare l'utente durante la compilazione che dovrebbe collegarsi alla corretta configurazione della libreria?

EDIT

Sia debug e rilasciare le versioni dovrebbero essere disponibili per consentire agli sviluppatori di Windows per eseguire il debug delle loro applicazioni. Quindi dovrebbero essere disponibili entrambe le versioni di debug e release della mia libreria.

Sto facendo questa domanda perché il supporto per gli sviluppatori principianti di Windows è causato dal fatto che essi mischiano il codice di debug e di rilascio e ottengano errori di runtime difficili da debug.

+0

Perché vuoi che i tuoi clienti eseguano il debug della tua libreria? Stai fornendo codice sorgente con esso? Progetta la tua API in modo che le impostazioni del compilatore non siano importanti. L'ABI COM è un buon esempio. –

+0

Se si crea una lib statica invece di una DLL, è necessario aggiungere la versione di debug in qualsiasi modo. Altrimenti nessuno è in grado di creare una versione di debug. – Totonga

risposta

0

È possibile aggiungere una direttiva #warning, ma vi sconsiglio vivamente di farlo. Dovresti consegnare meglio alla versione diversa della tua libreria con due nomi diversi.

Ecco un altro suggerimento per il vostro problema:

myLib.h // Release Version 
myLibd.h // Debug Version 

Facendo così, si costringerà l'utente a fare attenzione quando si configurare l'applicazione con la libreria (dal momento che l'impostazione deve essere manuale) .

È inoltre possibile aggiungere una nota nel file README o INSTALL, la maggior parte degli utenti lo legge quando desidera impostare il collegamento su MSVC.

È inoltre possibile verificare il valore della macro DEBUG e NDEBUG nel programma. (Con un'asserzione durante l'inizializzazione della libreria

4

Buona domanda, ho sempre pensato che gli sviluppatori che utilizzano le mie librerie si collegassero alla versione corretta. Ora che ci penso, perché dovresti anche voler rilasciare la tua libreria di debug ? al pubblico perché non dovrebbe sia la loro debug e rilasciare versioni dei collegamenti alle librerie di rilascio

Indipendentemente da ciò, vedo un modo di fare questo esportando alcuni simboli per la configurazione:?

//header: 
class DLLIMPEXP Dummy 
{ 
    static int x; 
    virtual void dummy(); 
} 
//cpp 
#ifdef DEBUG 
int Dummy::x = 0; 
void Dummy::dummy() 
{ 
} 
#endif 

come si può vedi, il tuo simbolo verrà esportato solo se il tuo modulo è compilato in DEBUG. l'ode da un terzo modulo comporterebbe un errore del linker. Puoi avere qualcosa di simile per la cassa inversa.

Non ti suggerisco di farlo, preferirei documentarlo o distribuire solo la versione del mio modulo.

+0

Abbastanza interessante. Mi hai dato un'idea: aggiungi la funzione non in linea IsReleaseVersion() che sarà nella libreria. E aggiungere il controllo inline del costruttore (che sarà incluso nel lato dell'applicazione) per verificare la sua versione. – Phong

+0

Ho appena modificato la domanda per rispondere ad alcuni dei tuoi. Questo attiverà un errore di collegamento solo quando l'utente tenta di utilizzare quel simbolo nel proprio codice. Inoltre, voglio che gli utenti ricevano un messaggio chiaro dicendo loro che "non si sta collegando alla libreria corretta". – Mourad

+0

@Mourad: è possibile assegnare un nome al simbolo mancante come PleaseUseReleaseVersionOfXxxLibrary, come pure PleaseUseDebugVersionOfXxxLibrary. –

1

Ci sono due diversi aspetti qui:

  • problema di incompatibilità
  • problema di prestazioni

Se si tratta di una questione di prestazioni, allora la scelta dovrebbe essere ancora loro, essi potrebbero voler debug.

Se si tratta di incompatibilità, una cosa semplice è modificare lo spazio dei nomi per la versione di debug, in modo che i simboli vengano modificati in modo diverso.

#ifdef NDEBUG 
    namespace project { 
#else 
    namespace project { namespace debug { 
#endif 

// content 

#ifdef NDEBUG 
    } 
#else 
    } 
    using namespace debug; 
    } 
#endif 

Nidificando in un namespace debug, si cambia la storpiatura dei simboli (anche se, la compilazione-saggio, non cambia nulla). Questo in realtà impedisce il collegamento a una libreria compilata contro la versione di debug con la versione di rilascio (e quindi risolve l'incompatibilità all'inizio piuttosto che bloccarsi misteriosamente).

Tuttavia, ti esorto a prenotare questo per un insieme molto specifico di classi (è pesante).

Dovrebbe essere possibile, normalmente, essere in grado di fornire interfacce compatibili in entrambe le modalità di debug e di rilascio, in modo che i client possano eseguire l'hot-swap in fase di caricamento.

0

Aggiungere questo codice l'intestazione del vostro lib

nomi diversi per i diversi tipi

#ifndef _DLL 
// C runtime as dll 
# ifdef _DEBUG 
# pragma comment(lib, "MyLibD.lib") 
# else 
# pragma comment(lib, "MyLib.lib") 
# endif 
#else 
// C runtime statically 
# ifdef _DEBUG 
# pragma comment(lib, "MyLibSD.lib") 
# else 
# pragma comment(lib, "MyLibS.lib") 
# endif 
#endif 

percorso diverso per i diversi tipi

#ifndef _DLL 
// C runtime as dll 
# ifdef _DEBUG 
# pragma comment(lib, "debug/dynamic/MyLib.lib") 
# else 
# pragma comment(lib, "release/dynamic/MyLib.lib") 
# endif 
#else 
// C runtime statically 
# ifdef _DEBUG 
# pragma comment(lib, "debug/static/MyLib.lib") 
# else 
# pragma comment(lib, "debug/static/MyLib.lib") 
# endif 
#endif 

poi basta aggiungi il percorso alla lib al tuo linker e non sei più ab le per mescolarlo.

+1

Questo non è generalmente considerato una buona pratica (specificando librerie nel codice), ma è una soluzione, quindi non mi dilungherò . –

+0

Se sviluppi una lib statica e non una dll, preferirei sempre questo. Ci sono così tanti vantaggi ed errori evitati che non mi interesserei per ragioni filosofiche. – Totonga

Problemi correlati