How to fix the following problem?

-----------------------Lab002.h------------------------------
#ifndef _LAB_002_
#define _LAB_002_

class base{
char *msg;
public:
base(char *);
~base();
void print(void);
};

class derived1 : base{
public:
derived1(char *);
~derived1();
};

class derived2 : derived1{
public:
derived2(char *);
~derived2();
};
#endif

----------------------------main.cpp------------------------------
#include <iostream>
#include "Lab002.h"
using namespace std;

void main(void){
derived2 x("X");
{
derived2 y("Y");
}
derived2 z("Z");
}

-------------compiler complaint------------------------------------1>main.obj : error LNK2019: unresolved external symbol "public:
__thiscall derived2::derived2(char *)" (??0derived2@@QAE@PAD@Z)
referenced in function _main

what 's wrong with it?

re: How to fix the following problem?

SamuelXiao <foolsmart2005@gmail.comwrote:
There are two things wrong with the above code.
1) 'main' returns an int, not void.

2) 'main' attempts to create several derived2 objects by using the
derived2::derived2(char*) constructor, unfortunately according to the
linker, no such constructor has been provided.

If you provided the constructor in a separate file, the consult your
compiler documentation on how to add the file to the link process.

re: How to fix the following problem?

Daniel T. wrote:[MONTY-PYTHON]
There are THREE things wrong with the above code.
[/MONTY-PYTHON]

3) The identifier for the include guard _LAB_002_ is reserved to the
implementation. You may not use it for your own purposes like that.


[MONTY-PYTHON]
There are THREE AND A HALF things wrong with the above code.
[/MONTY-PYTHON]

3.5) the (void) argument list is a C-ism, discouraged in C++. Avoid
its use.

As a side note, the contents of <iostreamare not used, and the
"using namespace std;" is unnecessary, since no members of std:: are
used.

re: How to fix the following problem?

I think the original question was about the specific error, not the
style.
I believe the author should take a closer look at "declaration vs.
definition" and "compilation and linkage" chapter of his course.

The simple solution would be to implement all declaration from
Lab002.h in main.cpp This is a bad practice, don't do that in the
future, but it is OK to start learning that way.

re: How to fix the following problem?

On 4 Sep, 04:27, red floyd <no.spam.h...@example.comwrote:Aren't there FOUR AND A HALF things wrong with the code?

To the OP: the errors you have shown each say "unresolved external
symbol". This means that the linker is dealing with a name, and it
wants to do something with the thing of that name, but it can't find
anything of that name (it can't "resolve" the name). The error
messages also give the name that it can't resolve.

The second is "derived2::derived2(char *)" - the constructor for
derived2 which takes a char * as its parameter. You said you were
going to provide such a constructor, and you've used it three times in
main, but, as Daniel said, you haven't actually provided it. Not in
the code you've posted, at least.

And the first is "derived2::~derived2(void)" - the destructor for
derived2. You said that you were going to provide one of these as
well, and so the computer will run it when it destroys the three
derived2s that you created - but again, you don't seem to have
actually provided it. It's not in the code you've posted, and if it's
in some other code, it doesn't seem to be getting linked properly.

Hope that helps.
Paul.