0

I was making a program for shader parsing and I wanted to move some pieces of code to different classes, then I got a lot of linker errors, started to debug them and tried to get to as basic situation as I can to eliminate them one by one, I removed all of the code and I don't know if it's just me being tired or there's something wrong with my visual studio but this code :

main.cpp

#include "Shader.h"

int main()
{
    Shader shader;
    shader.DoStuff();

    return 0;
}

Shader.h

#pragma once
class Shader
{
public:

    void DoStuff();
};

Shader.cpp

#include "Shader.h"
void Shader::DoStuff()
{
}

Generates linker error:

Severity    Code    Description Project File    Line    Suppression State
Error   LNK2019 unresolved external symbol "public: void __thiscall Shader::DoStuff(void)" (?DoStuff@Shader@@QAEXXZ) referenced in function _main   ShaderParser

Like, did I forget about something or what is going on?

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
Werem
  • 21
  • 2
  • https://stackoverflow.com/questions/17769977/lnk2019-unresolved-external-symbol-error-in-visual-studio-c – Polb Aug 18 '18 at 12:51
  • 2
    Please show your compile/link commandline. – Jesper Juhl Aug 18 '18 at 12:53
  • I just have /VERBOSE added – Werem Aug 18 '18 at 12:56
  • @Werem "I just have /VERBOSE added" - that may be so, but could you *please* show us what the *actual*, *final* command line ends up as? How is the compiler/linker *actually* called in your case? I don't care what you did in some GUI, I want to see how the compiler actually ended up getting invoked, regardless of build-system etc. Just show us the actual commandline used. – Jesper Juhl Aug 18 '18 at 13:14

1 Answers1

-1

It has passed compilation and it can run correctly on my computer Visual Studio, no problems. So:

  1. You had better check compilation options parameters.
  2. Whether these 3 files are put in the correct paths(folders) as commands written.
  3. "#pragma once" is not standard, try to change it to "#ifndef #define ... #endif"

The problem often happens when the pair of *.h and *.cpp are not corresponded.

asdf
  • 221
  • 1
  • 10