2011-10-12 19 views
6

Como desarrollador de biblioteca, quiero evitar que los usuarios de mi biblioteca (Windows, MSVC) se vinculen a la configuración incorrecta (no vincular la biblioteca de depuración a sus programas de lanzamiento, y viceversa).Evite mezclar bibliotecas de depuración y liberación

¿Es posible advertir al usuario durante el tiempo de compilación que debe conectarse a la configuración correcta de la biblioteca?

EDITAR

Tanto depuración y liberación de versiones deben estar disponibles para permitir a los desarrolladores de Windows para depurar sus aplicaciones. Por lo tanto, las versiones de depuración y versión de mi biblioteca deberían estar disponibles.

Estoy haciendo esta pregunta porque gran parte del soporte para los desarrolladores principiantes de Windows es causado por ellos mezclando código de depuración y liberación, y obteniendo errores difíciles de depurar en tiempo de ejecución.

+0

¿Por qué quiere que sus clientes depuren su biblioteca? ¿Estás suministrando código fuente con él? Diseña tu API para que la configuración del compilador no importe. El COM ABI es un buen ejemplo. –

+0

Si crea una lib estática en lugar de una DLL, debe agregar la versión de depuración de alguna manera. De lo contrario, nadie puede crear una versión de depuración. – Totonga

Respuesta

0

Puede agregar una directiva #warning pero lo desanimo firmemente a hacerlo. Debería entregar mejor a la versión diferente de su biblioteca con dos nombres diferentes.

Aquí es otra sugerencia para su problema:

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

Haciéndolo así, que obligará al usuario a tener cuidado cuando se van a configurar la aplicación con su biblioteca (ya que el ajuste debe ser manual) .

También puede agregar una nota en el archivo README o INSTALL, la mayoría del usuario la lee cuando quiere configurar el enlace en MSVC.

También puede verificar el valor de macro DEBUG y NDEBUG en su programa. (Con una afirmación durante la inicialización de su biblioteca.

4

Una buena pregunta, siempre he supuesto que los desarrolladores que usan mis bibliotecas vincularían a la versión correcta. Ahora que lo pienso, ¿por qué querrían lanzar su biblioteca de depuración? ? al público por qué no habría tanto su depuración y liberación de versiones enlazan en contra de su biblioteca de liberación

Independientemente, veo una forma de hacer esto mediante la exportación de algunos símbolos por configuración:?

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

Como se puede mira, tu símbolo solo se exportará si tu módulo está compilado en DEPURACIÓN. Intenta vincularlo con la lib en la versión m odo de un tercer módulo daría lugar a un error de enlazador. Puede tener algo similar para el caso inverso.

No sugiero que hagas esto, preferiría documentarlo o distribuir la versión de lanzamiento de mi módulo.

+0

Bastante interesante. Me hiciste una idea: agrega la función no en línea IsReleaseVersion() que estará en la biblioteca. Y agregue el cheque incorporado del constructor (que se incluirá en el lado de la aplicación) para verificar su versión. – Phong

+0

Acabo de editar la pregunta para responder algunas de las suyas. Esto desencadenará un error de enlace solo cuando el usuario intente usar ese símbolo en su propio código. Además, quiero que los usuarios obtengan un mensaje claro que les diga "no están enlazando a la biblioteca correcta". – Mourad

+0

@Mourad: puede nombrar el símbolo que falta como PleaseUseReleaseVersionOfXxxLibrary, así como PleaseUseDebugVersionOfXxxLibrary. –

1

Hay dos aspectos diferentes aquí:

  • problema de incompatibilidad
  • problema de rendimiento

Si se trata de una cuestión de rendimiento, entonces la elección debe todavía ser de ellos, que desearan depurar.

Si se trata de una cuestión de incompatibilidad, una cosa simple es cambiar el espacio de nombres para la versión de depuración, de modo que los símbolos se destrocen de manera diferente.

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

// content 

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

Al anidar en un espacio de nombres debug, se cambia el mangling de los símbolos (a pesar de que, compilación-sabia, no cambia nada). De hecho, esto impide que vincule una biblioteca compilada contra la versión de depuración con la versión de lanzamiento (y así resuelve la incompatibilidad desde el principio en lugar de estrellarse misteriosamente).

Sin embargo, le recomiendo que reserve esto para un conjunto muy específico de clases (es pesado).

Normalmente, debería ser posible proporcionar interfaces compatibles tanto en los modos de depuración como de liberación, para que los clientes puedan intercambiar en caliente en el momento de la carga.

0

Añadir este código a la cabecera de su lib

nombres diferentes para diferentes tipos

#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 

camino diferente para diferentes tipos

#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 

después, es suficiente con agrega la ruta a la lib a tu enlazador y ya no eres ab para mezclarlo.

+1

Esto generalmente no se considera una buena práctica (especificar bibliotecas en el código), pero es una solución, así que no voy a rechazarlo . –

+0

Si desarrolla una lib estática y no una dll siempre preferiría esto. Hay tantas ventajas y errores evitados que no me importaría por razones filosóficas. – Totonga

Cuestiones relacionadas