Símbolo externo no resuelto en archivos de objeto

Durante la encoding en Visual Studio obtuve un error de símbolo externo no resuelto y no tengo idea de qué hacer. No se lo que está mal. ¿Podrías por favor descifrarme? ¿Dónde debería estar buscando qué tipo de errores?

1>Form.obj : error LNK2019: unresolved external symbol "public: class Field * __thiscall Field::addField(class Field *)" (?addField@Field@@QAEPAV1@PAV1@@Z) referenced in function "public: void __thiscall Form::parse(class std::basic_stringstream<char,struct std::char_traits,class std::allocator > &)" (?parse@Form@@QAEXAAV?$basic_stringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) 1>Form.obj : error LNK2019: unresolved external symbol "public: virtual void __thiscall Field::parse(class std::basic_stringstream<char,struct std::char_traits,class std::allocator > &)" (?parse@Field@@UAEXAAV?$basic_stringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) referenced in function "public: __thiscall InputField::InputField(class std::basic_stringstream<char,struct std::char_traits,class std::allocator > &)" (??0InputField@@QAE@AAV?$basic_stringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) 1>Form.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Field::prompt(void)" (?prompt@Field@@UAEXXZ) 1>Form.obj : error LNK2001: unresolved external symbol "public: virtual class std::basic_string<char,struct std::char_traits,class std::allocator > __thiscall Field::getName(void)" (?getName@Field@@UAE?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) 1>Form.obj : error LNK2001: unresolved external symbol "public: virtual class std::basic_string<char,struct std::char_traits,class std::allocator > __thiscall Field::getType(void)" (?getType@Field@@UAE?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) 1>Form.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Field::describe(void)" (?describe@Field@@UAEXXZ) 1>C:\Users\tomy\Documents\Visual Studio 2010\Projects\zapoctovkac++\Debug\zapoctovkac++.exe : fatal error LNK1120: 6 unresolved externals 

Este error a menudo significa que alguna función tiene una statement, pero no una definición.

Ejemplo:

 // A.hpp class A { public: void myFunc(); // Function declaration }; // A.cpp // Function definition void A::myFunc() { // do stuff } 

En su caso, la definición no se puede encontrar. El problema podría ser que está incluyendo un archivo de encabezado, que trae algunas declaraciones de funciones, pero usted:

  1. no defina las funciones en su archivo cpp (si usted mismo escribió este código)
  2. no incluya el archivo lib / dll que contiene las definiciones

Un error común es definir una función como independiente y olvidar el selector de clase, por ejemplo A:: , en su archivo .cpp :

Incorrecto: void myFunc() { /* do stuff */ }
Derecha: void A::myFunc() { /* do stuff */ }

Verifique que esté incluyendo todos los archivos fuente dentro de su solución a la que hace referencia.

Si no incluye el archivo fuente (y, por lo tanto, la implementación) para el Field de la clase en su proyecto, no se comstackrá y no podrá vincularlo durante la comstackción.

Alternativamente, ¿quizás está utilizando una biblioteca estática o dinámica y se le olvidó contarle al vinculador acerca de la .lib s?

Parece que falta una biblioteca o incluir, puede intentar averiguar qué clase de su biblioteca tiene getName, getType, etc … y poner eso en el archivo de encabezado o con #include .

Además, si estos provienen 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, verifique que apunta a la ubicación de abc.lib en Directorios de inclusión adicionales. En Linker, Input, asegúrese de tener abc.lib en Dependencias Adicionales.

Acabo de ver el problema. No puedo llamar a una función desde main en el archivo .cpp, declarada correctamente en el archivo .h y definida en el archivo .c. Encontrado un error del enlazador. Mientras tanto puedo llamar a la función desde el archivo .c habitual. Posiblemente depende de la convención de llamadas. La solución fue agregar las siguientes líneas de preproceso en cada archivo .h:

 #ifdef __cplusplus extern "C" { #endif 

y estos al final

 #ifdef __cplusplus } #endif 

Tuve un error donde mi proyecto fue comstackdo como proyecto x64 . y he usado una biblioteca comstackda como x86 .

He recomstackdo la biblioteca como x64 y lo resolvió.

Tenía los mismos errores de enlace, pero de un proyecto de prueba que hacía referencia a otro dll. _declspec(dllexport) que después de agregar _declspec(dllexport) al frente de cada función que se especificó en el mensaje de error, el enlace funcionaba bien.

Además de la excelente respuesta de Chris Morris anterior, encontré una manera muy interesante de que pueda recibir este mismo error si llama a un método virtual que no se ha configurado como puro, pero que no tiene su propia implementación. Es exactamente la misma razón (el comstackdor no puede encontrar una implementación del método y por lo tanto ladrones), pero mi IDE no detectó esta falla en lo más mínimo.

por ejemplo, el siguiente código obtendría un error de comstackció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, cambiando IamInterface myFunc () para que sea un método virtual puro (un método que “debe” implementarse, que un método virtual que es un método en el que se puede “anular”) eliminará el error de comstackció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 

Cosas malas -incluyendo esto- pueden suceder si no lo haces

Creo que la mayoría de los puntos relacionados con las causas y los remedios han sido cubiertos por todos los contribuyentes en este hilo. Solo quiero señalar mi problema “externo no resuelto”, fue causado por un tipo de datos definido como macro que se sustituye de forma diferente a la esperada, lo que da como resultado que se suministre ese tipo incorrecto a la función en cuestión, y dado que la función con tipo nunca se define, no podría haberse resuelto. En particular, en C / C ++ -> Idioma, hay un atributo llamado ‘Tratar WChar_t como Construido en Tipo, que debería haberse definido como’ No (/ Zc: wchar_t-) ‘pero no en mi caso.

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

por ejemplo:

 #include WtsApi32.h 

necesitará:

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

Simplemente tuve un momento difícil con esto. Todo estaba lógicamente configurado. Declaré un constructor pero no lo definí

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

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

Estoy haciendo algo de C ++ por primera vez en mucho tiempo, y estoy obteniendo este error cuando me olvido de agregar el prefijo ClassName :: para la definición de la función, ya que esto es un poco exclusivo de C ++. ¡Así que recuerda comprobar eso también!

Consulte Linker Tools Error LNK2019 en MSDN, tiene una lista detallada de problemas comunes que causan LNK2019.

Una posible causa de este error de vinculador también pueden ser las funciones en inline 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 un puntero. Veo que este no era su problema, pero pensé que lo mencionaría porque seguramente desearía haber estado aquí cuando lo vi hace una hora. Mi problema consistía en declarar una variable miembro estática sin definirla (la definición debía venir después de otras configuraciones) y, por supuesto, un puntero no necesita una definición. Error igualmente elemental: P

Mi problema era un resumen que 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 algo más está construyendo por completo.

Mi problema era: tenía que hacer una statement directa de la clase cuyo coordinador 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. También al usar espacios de nombres, también los declara .

Solo pasé un par de horas para encontrar que el problema era que mi archivo principal tenía extensión .c lugar de .cpp

:/

verifique que la plataforma objective de su proyecto VS sea coherente con los Binarios que ha descargado.

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

Otra posibilidad más de comprobar, era mi problema esta vez.

Agregué la función a la biblioteca e incluí 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 enumerada anteriormente, por lo que VS estaba usando la biblioteca anterior y, por supuesto, no encontraba la nueva función.

Asegúrese de no intentar 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 causó en mi caso:

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

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

Foo.h palabra clave “estática” y agregué un Foo.h con esto:

 extern int var; 

¿Ves el error?

Me extrañaba totalmente que var se definiera originalmente en un espacio de nombres, porque la statement del espacio de nombres estaba enterrada en otro código. La solución es cambiar el extern así:

 namespace NS { extern int var; } 

Otro problema posible (que me acabo de pasar por la cabeza):

Si define sus funciones como en inline , ellas -¡por supuesto! – deben definirse en el encabezado (o en un archivo en línea ), no en una cpp .
En mi caso, estaban en un archivo en línea, pero solo porque eran una implementación específica de la plataforma, y ​​una cpp incluía este archivo inl correspondiente … en lugar de un encabezado. Sí, sucede.

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