A virtual statement canceling the 'error LNK2001: unresolved external symbol' error?

I tried to generate a “applepie.dll”, which used some functions defined in a header file called ‘Apple.h’. But the compiler showed error in linking process as below:

applepie.obj : error LNK2001: unresolved external symbol "public: double __thiscall Apple::Function2(void)" (?Function2@Apple@@QAENPBD@Z)
.\ applepie.dll : fatal error LNK1120: 1 unresolved externals


The ‘Apple’ application is used to generate another ‘Apple.dll’

Code:

---

//Apple.h////////////////////////////////////////////////
Class Apple{
public:
        double Function1(const char* arg);
        double Function2(void);
}


//Apple.cpp////////////////////
double Apple::Function1(const char* arg){
//Do something here;
}

double Apple::Function2(void){
//Do something here;
}

---

Please let me describe how the problem happened in more detail. In ApplePie.cpp, I try to use the functions defined in Apple.cpp like:


Apple* m_Apple;
m_Apple=something //some method was used to get the pointer to class Apple.

double weight;
weight= m_Apple-> Function2();

The compilation process does not show error, but the link error will show up. I searched online, and included ‘Apple.lib’ in the ‘applepie’ application using Project->settings->link, following the instructions to similar ‘error LNK2001: unresolved external symbol’ problems that many people have, but this did not help.


However, I found that if I put ‘virtual’ before the definition of function 2, like:

virtual double Function2(void);

then the compiler can link successfully, no error shows up.


I am totally confused about what’s happening here, why a ‘virtual’ statement could cancel the linking error?

Hmm. That's odd alright! I'm assuming that code you wrote up there was just for example cause class has a capital c and there isn't a terminating ; after the class definition.

I normally use __declspec(dllimport)/__declspec(dllexport) when I'm using dlls. Something like:

(when making dll):

Code:

---

#ifndef TWOMERS_APPLE_H
#define TWOMERS_APPLE_H

class __declspec(dllexport) myapple {
private:
  int something;

public:
  myapple( void );
  myapple( int );

  int get( void );
  void set( int );
};

#endif

---

Code:

---

#include "myapple.h" // The above file

myapple::myapple( void ) : something( 24 ) {
}

myapple::myapple( int n ) : something ( n ) {
}


int myapple::get( void ) {
  return something;
}

void myapple::set( int n ) {
  something = n;
}

---

Header file linking to it:

Code:

---

#ifndef TWOMERS_APPLE_H
#define TWOMERS_APPLE_H

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

class __declspec(dllimport) myapple {
private:
  int something;

public:
  myapple( void );
  myapple( int );

  int get( void );
  void set( int );
};

#endif

---

And main:

Code:

---

#include "myapple.h"

int main( void ) {
  myapple apple;
  std::cout<< apple.get();

  apple.set(4);
  std::cout<< ", " << apple.get();

  return 0;
}

---

Virtual-ing some functions doesn't affect mine here. To be honest I don't know a whole lot about making dlls and what I showed there mightn't be the best way of doing it but it runs fine for me. What compiler are you using?

Right, It's just example code here. The real code is exteremy big and messy, and both the ApplePie class and Apple class are based on some fundamental classes, they use someother libraries. So I can only write some pseudo code here to describe how I am using the classes, and what's the effect of the virtual statement .

I am using visual c++ 6.0

Quote:

---

Originally Posted by pingpangpang

Right, It's just example code here. The real code is exteremy big and messy, and both the ApplePie class and Apple class are based on some fundamental classes, they use someother libraries. So I can only write some pseudo code here to describe how I am using the classes, and what's the effect of the virtual statement .

---

Perhaps strip it down to real code -- a minimal amount -- that actually demonstrates the issue(s). The problem with pseudocode and paraphrased code is that once debugged, it may have absolutely no bearing on the actual code.