Símbolo externo no resuelto en archivos objeto

Compruebe que está incluyendo todos los archivos de origen dentro de su solución a los que hace referencia.

Si no está incluyendo el archivo fuente (y por lo tanto la implementación) para la clase Field en su proyecto, no se construirá y no podrá vincular durante la compilación.

Alternativamente, tal vez usted está utilizando una biblioteca estática o dinámica y se ha olvidado de decirle al enlazador acerca de la .lib s?

Parece que le falta una biblioteca o include, puede intentar averiguar qué clase de su biblioteca tiene getName, GetType, etc... y ponlo en el archivo de encabezado o usando #include.

También si estos son de una biblioteca externa, asegúrese de hacer referencia a ellos en su archivo de proyecto. Por ejemplo, si esta clase pertenece a un abc.lib entonces en su Visual Studio

1. Haga clic en Propiedades del proyecto.
2. Vaya a Propiedades de configuración, C / C++, Generar, verificar apuntas al abc.lib ubicación bajo Adicional Incluir Directorios. En Enlazador, Entrada, asegúrese de que tiene la abc.lib bajo Dependencias Adicionales.

Acabo de ver el problema de que no puedo llamar a una función desde main in .archivo cpp, correctamente declarado en .h archivo y definido en .archivo c. Se ha encontrado un error de enlazador. Mientras tanto puedo llamar a la función de lo habitual .archivo c. Posiblemente depende de la convención de llamadas. La solución era agregar las siguientes líneas preproc en cada .archivo h:

#ifdef __cplusplus
extern "C"
{
#endif

Y estos al final

#ifdef __cplusplus
}
#endif

Tuve un error donde mi proyecto fue compilado como x64 project. y he usado una Biblioteca que fue compilada como x86.

He recompilado la biblioteca como x64 y lo solucionó.

Tuve los mismos errores de enlace, pero de un proyecto de prueba que hacía referencia a otra dll. Descubrí que después de agregar _declspec(dllexport) delante de cada función que se especificó en el mensaje de error, el enlace estaba funcionando bien.

Además de la excelente respuesta de Chris Morris anterior, encontré una forma muy interesante de recibir este mismo error si está llamando a un método virtual que no se ha establecido en pure pero no tiene su propia implementación. Es exactamente la misma razón (el compilador no puede encontrar una implementación del método y por lo tanto crooks), pero mi IDE no detectó este error en lo más mínimo.

Por ejemplo, el siguiente código obtendría un error de compilación con el mismo mensaje de error:

//code testing an interface
class test
{
   void myFunc(); 
}

//define an interface
class IamInterface
{
    virtual void myFunc();
}

//implementation of the interface
class IamConcreteImpl
{
    void myFunc()
    {
       1+1=2;
    }
}

Sin embargo, cambiar IamInterface myFunc() para que sea un método virtual puro (un método que "debe" ser implementado, que de un método virtual que es un método que "puede" ser anulado) eliminará el error de compilación.

//define an interface
class IamInterface
{
    virtual void myFunc() = 0;
}

¡Espera que esto ayude a la próxima persona de StackOverFlow a pasar por el código!

Asegúrese de decorar sus archivos de encabezado con

#ifndef YOUR_HEADER_H
#define YOUR_HEADER_H

// your header code here

#endif

Las cosas malas, incluyendo esto, pueden suceder si no lo haces

Creo que la mayoría de los puntos con respecto a las causas y remedios han sido cubiertos por todos los contribuyentes en este hilo. Solo quiero señalar que mi problema 'externo no resuelto' fue causado por un tipo de datos definido como macro que se sustituye de manera diferente a lo esperado, lo que resulta en que ese tipo incorrecto se suministre a la función en cuestión, y como la función con tipo nunca se define, no podría haberse resuelto. En particular, bajo el lenguaje C / C++ ->, hay un atributo llamado 'Treat WChar_t As Built in Type, que debería haber sido definido como' No (/Zc: wchar_t-)' pero no lo hizo en mi caso.

A veces, si se agrega un nuevo archivo de encabezado, y este error comienza a venir debido a eso, también debe agregar biblioteca para deshacerse de unresolved external symbol.

Por ejemplo:

#include WtsApi32.h

Necesitará:

#pragma comment(lib, "Wtsapi32.lib") 

Acabo de tener un momento difícil con esto. Todo estaba organizado lógicamente. Declaré un constructor pero no lo definí

class SomeClass
{
   SomeClass();  // needs the SomeClass::SomeClass(){} function defined somewhere, even here
}

Casi me golpeé la cabeza con el teclado cuando olvidé algo tan elemental.

Estoy haciendo algo de C++ por primera vez en mucho tiempo, y estoy recibiendo este error cuando me olvido de agregar el prefijo className:: para la definición de la función, ya que esto es un poco único para C++. Así que recuerde comprobar para que también!

Ver Error de Herramientas de enlace LNK2019 en MSDN, tiene una lista detallada de problemas comunes que causan LNK2019.

Una posible causa de este error de enlazador también puede ser inline funciones que se declaran pero no se definen en un archivo de encabezado que luego se incluye en otro lugar. Las funciones en línea deben definirse en cada unidad de traducción en la que se utilizan.

PUNTEROS

Tuve este problema y lo resolví usando puntero. Veo que este no era su problema, pero pensé en mencionarlo porque me hubiera gustado que hubiera estado aquí cuando vi esto hace una hora. Mi problema era declarar una variable miembro estática sin definirla (la definición tenía que venir después de otras configuraciones) y, por supuesto, un puntero no necesita una definición. Error igualmente elemental: P

Mi problema fue que un sconscript no tenía el archivo cpp definido en él. Esto puede ser muy confuso porque Visual Studio tiene el archivo cpp en el proyecto, pero se está construyendo algo completamente diferente.

Mi problema era: Tenía que hacer declaración de reenvío de la clase cuyo ctor era "externo no resuelto".

En el archivo donde obtuve el error, tuve que poner algo como esto:

#include "ClassB" 

class ClassB; // this solved the problem

class ClassA{
    void foo(){
        ClassB* tmp = new ClassB();
        // ...
    }
};

Por supuesto, mi proyecto es mucho más complicado y esto es solo un ejemplo de fragmento. También cuando se usan espacios de nombres, declararlos también.

Acabo de pasar un par de horas para encontrar que el problema era que mi archivo principal tenía extensión .c en lugar de .cpp

:/

Compruebe que su plataforma de destino VS project es consistente con los binarios que ha descargado.

Por ejemplo: Plataforma: Win32 ---- VS2013 32bits 6.3(estática)

Otra posibilidad para comprobar, fue mi problema esta vez.

Había agregado la función a la biblioteca e incluido la carpeta de salida de la biblioteca en la ruta de búsqueda.

Pero también tenía una carpeta con una versión anterior de la biblioteca listada anteriormente, por lo que VS estaba usando la biblioteca antigua, y por supuesto no encontraba la nueva función.

Asegúrese de que no está tratando de sobrecargar los operadores de inserción o extracción como funciones en línea. Tuve este problema y solo desapareció cuando eliminé esa palabra clave.

Lo que lo había causado en mi caso:

Tenía un archivo enorme Foo.cpp sin un Foo.h. Foo.cpp comenzó así:

// ... 100 LOC here ...
namespace NS {
// ... 100 more LOC here ...
static int var;

Eliminé la palabra clave "estática" y agregué un Foo.h con esto:

extern int var;

¿Ves el error?

Me perdí totalmente que var se definió originalmente en un espacio de nombres, porque la declaración de espacio de nombres estaba enterrada en otro código. La solución es cambiar el extern así:

namespace NS {
     extern int var;
}

Otro posible problema (que acabo de rascarme la cabeza durante algún tiempo):

Si defines tus funciones como inline, ¡por supuesto!- debe definirse en el encabezado (o en un archivo inline), no en un cpp.
En mi caso, estaban en un archivo inline, pero solo porque eran una implementación específica de la plataforma, y un cpp incluía este archivo inl correspondiente instead en lugar de un encabezado. Sí, eso pasa.

Pensé que deje esto aquí, también, tal vez alguien más se encuentra con el mismo problema y lo encuentra aquí.