File Linking Problem

First, let me provide some background information. I use g++ compiler in the cygwin shell to Program c++.

Now, I have two files, namely, first.cc and second.cc


The content of first.cc is:

class abc {
private:
int x=99;
public:
int get_x() { return x; }
};

The content of second.cc is:

#include <iostresm.h>
extern class abc test_abc;

int main() {
cout << test_abc.get_x() << endl;
return (0);
}


The expected result is screen output 99.
There is no problem when I compile the first file into an object file.
However, when I try to compile the second.cc (by g++ -c -o second.o second.cc), an error message " no matching function for call to 'abc:: get_x ()' " showed up.

What irritates me is that I have already defined the class object test_abc as an extern, c++ should know that its member function get_x() belongs to a foreign file. So the error message did not make sense.

I have tried to change the line from "extern class abc test_abc;" to "extern class abc;". And then I declare test_abc within main(). Hoever, this time the error message is " extern is only for objects or functions ". Obviously, extern did not work for class itself.

So, what have I do wrongly? extern should support class object (class object is a kind of varible, too!). Then why c++ don't know that the object's member function belong to a foreign file as well?

What should I do? Can anyone please help? Thanks. ^_^

I don't have a compiler right now to test that on, but any time I've declared an instance of a class, I've just said:
classname objectname;
which, in your case, would be:
abc testabc;
I've never used the 'extern class' command or whatever it is, and I don't know what it's meant for, but I think your second.cc might run if you tried that..
But then again the files I've been dealing with have all been .cpp files, maybe it has to do with that.. I'm not sure, but try just saying abc testabc; and see what happens..


Linette

Firstly, Some admendment in first.cc must been make before it is compiled to object file.

Now, first.cc is:

class abc {
private:
int x;
public:
abc(void) { x=99; }
int get_x() { return x; }
};

This is because : ANSI C++ forbids initialization of member 'x'

And I followed Linette's advice to change my second.cc to:

#include <iostream.h>
abc test_abc;

int main() {
cout << test_abc.get_x() << endl;
return (0);
}


This generated an error message when compiling:
" 'test_abc' undeclared (first use this function) "

If I put the 'declaration' inside main():

#include <iostream.h>

int main() {
abc test_abc;
cout << test_abc.get_x() << endl;
return (0);
}


another similar error occured:
" 'abc' undeclared (first use this function)
'test_abc' undeclared (first use this function) "

SO... what should I do? Help =(

you aren't getting an error for initializing the value of x within the class? Should be done during construct...


***edit... ahh, see you have gotten that far. Use a header file to declare your class and put your implementation in a seperate .cpp file. Place #include "your_h_file.h" in each cpp file. Compile both your implementation cpp file and your main cpp file together.

This may help you... GL

Code:

---



file.h

//++++++++++++++

#ifndef CLAS
#define CLAS


class Clas
{

  public:

            void hello(void);

};//end class

#endif

//+++++++++++++++

file.cpp

//+++++++++++++++

#include "file.h"
#include <iostream>
using namespace std;

void Clas::hello(void)
{
  cout << "Hello" << endl;
}

//+++++++++++++++

driver.cpp

//+++++++++++++++

#include "file.h"
int main()
{

  Clas umm;

  umm.hello();

return 0;

}

//++++++++++++++++

---

To Betazep,

absolutely no error for this (first.cc):

class abc {
private:
int x;
public:
abc(void) { x=99; }
int get_x() { return x; }
};

Because x=99 ins put inside the constructor of the class abc.

P.S. Any idea of how to solve my problem?
I still cannot find any method of compiling my second.cc into an object file... ...

To Betazep again,

Thanks for your help. However, the problem is that I don't want to use a header file to do this.

I wish that I could combine the two object file, first.cc containing the class definition, second.cc containing the main program utilizing the class in first.cc .

However, whenever I tried to compile the second.cc, error occurs.

I donno why even I have declared the class as an extern in second.cc, the compiler still claim that it cannot find the class' member function! The compiler *should* understand that if the class is an extern, its member function is an extern as well (i.e., in a foreign file).

=(

I don't know if there's a different way you're supposed to do these things with .cc files, but as far as I know, like betazep said, you should save your first.cc file as a .h file, and then include it in your second file.
I also noticed you'd mispelled iostream. Change that too, if that was how you wrote it in your compiler (little mistakes cause hard-to-detect problems).. oh, and do leave that declaration in your main.
That's all I can think of right now.. hope it helps.

Linette

Oh, I guess what I just wrote was useless then.
How can you use two different files, and not have one be a header file but still use the class in the other file? I think that is why you're getting that error.. I can't think of a way your compiler would know which class you want to use, without an include statement..

?

by using extern

#include <iostream.h>

int main() {
extern abc test_abc;
cout << test_abc.get_x() << endl;
return (0);
}

Try that... I do not have time to test it out. If that doesn't work, make the class a _c style name type and extern that as

extern _abc test_abc

hmm, I didn't know that..
So why did you suggest a .h file too?

ANSI

and I prefer it, but he doesn't want to use one. So he needs to let the compiler know that the class declaration is external to his code.

Quote:

---

Originally posted by Betazep
#include <iostream.h>

int main() {
extern abc test_abc;
cout << test_abc.get_x() << endl;
return (0);
}

Try that... I do not have time to test it out. If that doesn't work, make the class a _c style name type and extern that as

extern _abc test_abc

---

Well, writing "extern abc test_abc;" within main cause the following error when compiling:
" warning: ANSI C++ forbids declaration of 'abc' with no type
'test_abc' undeclared (first use this function) "

Therefore I rewrite the sentence as:
" extern class abc test_abc; "
This time the following error occur:
" no matching function for call to 'abc::get_x ()' "

Your second suggest create the same error, " _abc " seems to have no different with " abc ".

I really dunno what's wrong with the extern syntax. It is supposed to declare foreign object or function. By this way, the compiler should not try to look for member function of the foreign class object abc within second.cc . Because the compile should know that any member functions of a foreign class object belongs to a foreign file too.

Any method? =(

class abc
{
private:
int x; // you have not initial x direct with 99.

public:
abc() { x=99;} // constrctur initial the member x with 99.

int get_x() { return x; }
};

//The content of second.cc is:

#include <iostream.h> // syntax error"iostresm"
extern class abc test_abc;

int main() {

abc test_abc; // create an test_abc object.

cout << test_abc.get_x() << endl;

return (0);

}

Quote:

---

Originally posted by M.shawan
class abc
{
private:
int x; // you have not initial x direct with 99.

public:
abc() { x=99;} // constrctur initial the member x with 99.

int get_x() { return x; }
};

//The content of second.cc is:

#include <iostream.h> // syntax error"iostresm"
extern class abc test_abc;

int main() {

abc test_abc; // create an test_abc object.

cout << test_abc.get_x() << endl;

return (0);

}

---

Thanks. But if you have read my second message, you would know that I have used iostream already.

Now, your suggestion creates an error when compiling second.cc:
" In function 'int main()' :
aggregate 'class abc test_abc' has incomplete type and cannot
be initialized. "

So, any other suggestions? =(

P.S. extern.... It drive me crazy, how to use it with class object?

You are going to need zen, stoned_coder, or nvoigt's help with this. They are very familiar with 'extern'. I have used it to incorporate assembly functions into my C++ programs, but that is about the extent of it.

C++ has a different naming convention than C. The compiler names your functions something funky instead of _function(). In order to call a C naming convention, you need to declare your function a C style naming convention and then

extern "C"
{
void function(); // or in this case class
}

then function would be named _function() by the compiler and your linker would look for an object file that contains _function().

How that incorporates with classes, I am unsure. And how you identify your class name as a C naming convention, I am also unsure.

That is of course if you even need to go through all that pain.

PM one of the experts mentioned above. When you find a solution, let us know so that we have a better understanding of extern.

Good Luck...

Betazep

Thanks betazep.

Before I PM one of those guy you mentioned, I would like to restate again my situation in case some of you get fussy while reading all these long post.

Say, I have two file:

within file1.cc
int i = 0;

within file2.cc
extern int i;
int main(){i; return 0;}

There is NO problem in this case, however when the variable i is changed to a class object, problem ARISED:

I have two file, one for defining the class, namely first.cc :

class abc {
private:
int x;
public:
abc(void) { x=99; }
int get_x() { return x; }
};

The second file contains the main program which utilize the above class, namely second.cc :

#include <iostream.h>
extern class abc test_abc;

int main() {
cout << test_abc.get_x() << endl;
return (0);
}

Compiling the first file into object file (by "g++ -c -o first.o first.cc"
in cygwin ) has absolutely NO problem.

But compiling the second file always lead to ERROR message. But I think I
have used the syntax "extern" appropiately. The compiler know that test_abc is a foreign object. However it doesn't know get_x() is a foreign function. It always reply me as "no function for call to abc:: get_x()". Isnt it ridicuious that the compiler knows the object is foreign, but it dunno the member function of the object is foreign, too?

Thats my question. And I must not use any header file, too.

I know that a header file is appropiate, but I don't want to use it.
Because a header file is not possible to be encrypted. I mean that I want other to use my class, but I don't want them to know my content. If I am able to compile it into an object file, which is human unreadable, the computer is still able to read it. You may wonder then how they know how to use my class then. Actually I will tell them the use of the my class, but not the actual algorithm within the class.

I hope I have made it clear.
Thanks for reading. Any advice? ^_^

extern int i

would work because it is an int... try the same thing with a function.

I have tried many different ways to implement that. I am at a loss...

well there is one way... but you probably don't want to do this either.

Code:

---


file test.cpp+++++++++++++++++++

class test
{

  public:
              test() { x=99; }
              int ret_x() { return x; }

  private:
              int x;

};

++++++++++++++++++++++++++++

file test2.cpp+++++++++++++++++++

#include <iostream>
#include "test.cpp"
using std::cout;

int main()
{
  test testing;

  cout << testing.ret_x();

return 0;
} // end main

+++++++++++++++++++++++++++++

---

Then just compile test2.cpp and your class is linked in. You are going to need to get help from one of the more knowledgeable people here on extern. I have tried countless ways to do it....

Hey, Yim!
"int" is a standard, build-in, type of compiler. But "abs" is your user-defined type. So you must tell your compiler what is a type "abs" in second file. The keyword "extern" concerns to a variable, not to a type, which must be defined as well.

Quote:

---

Originally posted by Betazep
I have tried many different ways to implement that. I am at a loss...

---

Thanks for the trials... But your way still need the visible file test.cpp to be present when compiling... So that's no a perfect way yet.

Quote:

---

Originally posted by Unregistered
Hey, Yim!
"int" is a standard, build-in, type of compiler. But "abs" is your user-defined type. So you must tell your compiler what is a type "abs" in second file. The keyword "extern" concerns to a variable, not to a type, which must be defined as well.

---

I understand that abc is my user-defined type. Therefore instead of writing "extern abc test_abc;", I wrote "extern class abc test_abc". Therefore one would expect abc to be a class and test_abc is a class object.

extern concerns to variable, as well as objects. So the compiler knows test_abc is an extern object. But what surprise me is that the compiler don't know that test_abc.get_x() is an extern too.

Oh!
Try write "test_abc.get_anything()"! The same error will be encountered. The compiler do not know what methods are in class "abs".
It is possible in COM technology, not in pure C.

>>>So the compiler knows test_abc is an extern object.


I disagree...

extern class blah type;

comes back with an error that pretty much states that class cannot be used as an extern in this fashion.

extern class blah;

blah type;

comes back with a similar error.


extern blah;

blah type

is a completely different error stating something to the fact that blah isn't reconized as an object of type class, struct, whatever.

Now you really have me wanting to find an answer to this too... ;)

Perhaps using malloc to set memory aside for a class... hmmm. I need to not be this intrigued while I have finals... you are a bad bad man. :)

The extern storage modifier tells the compiler to accept the use of the name in the file in which it occurs, but not to allocate storage for the "extern" item, in this case your class.

Since your file with your main has test_abc declared as external, it allocates no storage for the object.

Your other file defines the class and it's components, but does not actually create an instance.

The question you need to ask yourself is, "where is the object?"...

The question for me is... "What is the answer?" ;)

Quote:

---

Originally posted by Unregistered
Oh!
Try write "test_abc.get_anything()"! The same error will be encountered. The compiler do not know what methods are in class "abs".
It is possible in COM technology, not in pure C.

---

Yes, the same error will occur. Isn't it ridiculous? the compiler *should* know the method in 'class abc'. Because I have type the line "extern class abc test_abc;" . THe compiler should know that the method in abc is stored in another file and don't bother when compiling. However it echoes me with an error message.

Betazep, nice to hear that you get involved, hoho. I have a new light to this problem: "pimpl idiom".

I don't know whether "pimpl idiom" can help or not. But it seems to be something about hiding class content. My knowledge to "pimpl idiom" is very limited however.

By the way, can did you(Betazep) PM-ed the guys you mentioned for me? I am new to this board and maybe you can help me by sending them PM. Because I don't know them and I didnt do any PM before. Furthermore, I am not registered. :P

Good Luck, Let's work towards the answer to "class encryption"!

I sent a PM to Stoned_Coder...

he is brilliant. Hopefully he will know.

I am starting to think that it cannot be done with extern.

Oh... and register.

>>> "What is the answer?"

Hint: If neither file is creating it, it probably doesn't exist!

But it isn't a linking problem. It is a compiling problem. So if you only compile the main.cpp file into object code and it doesn't compile, yet the other one does... does this mean that the memory has to be allocated within main.cpp to hold an object of the class.

Is this possible? That would be a better hint. ;)

Consider this line...

>>> cout << test_abc.get_x() << endl;

... where is test_abc? In this file, it is declared as external, therefore the name is valid and can be used,
but the compiler knows not to actually create the object, that it is being created somewhere else, and that the linker will fill in the gaps. Now look at his other file, nothing in there that creates an object.

I haven't tried to run this through the compiler, but whatever the error it gives me, it could not possibly work!

Quote:

---

Originally posted by Yin
Yes, the same error will occur. Isn't it ridiculous? the compiler *should* know the method in 'class abc'. Because I have type the line "extern class abc test_abc;" . THe compiler should know that the method in abc is stored in another file and don't bother when compiling. However it echoes me with an error message.

---

// extern class abc test_abc; it is equivalent of
class abc;
extern abc test_abs;

You can write the reduced class declaration:
class abc { int get_x(); }
extern abc test_abs;
to avoid the compilier error. But it is not correctly in some cases.

>>>... where is test_abc?

Which is the error I am getting when it is 'most right.' Something to the effect or "structure required on the left side of . or .*"

But I was trying to allocate space with the new operator for a new class of type test in main. That has been ineffectual as well...

extern just will not work with class objects or classes themselves.... oh well.

If you create an instance of the class in the file with the main() and want to use that instance, then it is no longer external.

The first thing I would probably try is to create the instance in the other file by placing the name required, (test_abc), after the class declaration, but before the closing brace. However, this is obvioulsly not his entire application, this may not be appropriate - it is better that he actually understands what is going on, then he can decide the right way to do it.

It should, of course, be in a header, but he says he doesn't want to do that. I don't really understand his reasoning for not having the header, it is not as if he has to distribute the header files with the app.

When I write "extern class abc;", the compiler echoes with "extern is only for objects and functions". What I lkearn in school is that object=variable or class object. Therefore I change the line as "extern class abc test_abc;" to avoid extern using on a class. However, just as Betazep has mentioned, extern seem do not work on class object either, let alone class.

The compiler will this time echo with "no function for call to abc:: get_x()" (I can memorize the various error message by now, wonderful?). Maybe we need to "extern" the member functions of the class as well.

>>>The first thing I would probably try is to create the instance in the other file by placing the name required, (test_abc), after the class declaration, but before the closing brace.


Yeah... I tried that. No go.


>>>It should, of course, be in a header, but he says he doesn't want to do that. I don't really understand his reasoning for not having the header, it is not as if he has to distribute the header files with the app.

I too am duly perplexed....

>>>Maybe we need to "extern" the member functions of the class as well.


Tried that... didn't work.

Maybe we need to extern the error messages... those work fine. :D

This compiles and runs, but I really don't like usinbg the .cpp files as a header. main() now knows what an "abc" is, and has a valid instance to work on.

Code:

---

#include <iostream.h>

#include "Junk2.cpp"

abc test_abc;

int main()
{
    cout << test_abc.get_x() << endl;
    return (0);
}

---

(junk2.cpp is the other file).

Quote:

---

Originally posted by Betazep


I too am duly perplexed....

---

Well, Actually, the reason is not important, but I will tell you... Don't laugh.

The fact is that my teacher is giving my class a homework. The homework is to write a header file. The file consists of two classes. So, one of my friend and I have a competition privately. Who finish the homework buglessly wins. However, we don't want to let each other to see our finished job before the deadline of the homework comes.

Therefore a problem arised: we cannot prove our work to be bugless since the other side cannot check it. So I want my class to be encrypted, but able to be compiled. So, a header file is inappropiate in this sense. Funny?

By the way, I don't think c++ is so weak that it even don't have any method to encrypt a class. (You know, by using extern, you can encrypt variables and functions, but not class object, that didn't make sense.)

Quote:

---

Originally posted by Betazep


Maybe we need to extern the error messages...

---

I suggest that we should extern ourself :D

Quote:

---

Originally posted by adrianxw


code:--------------------------------------------------------------------------------
#include <iostream.h>

#include "Junk2.cpp"

abc test_abc;

int main()
{
cout << test_abc.get_x() << endl;
return (0);
}
--------------------------------------------------------------------------------

---

Well, Junk2.cpp is still visible to other. If we can include Junk2.o , then that's good. (just joking)

Your encryption lay within your object code. It is suitable enough. Just give him the .obj file to link along with the function prototype list for your class. Your implementation is kept secret then...

try this code this is running perfectly on c++ compiler
and let me know did it solve ur problem

u have not included the file in second.cpp in which it will search for the class

//first.cpp

class abc
{
private:
int x;
public:
abc()
{
x=99;
}
int getx()
{
return x;
}
};


//second.cpp
#include<iostream.h>
#include "first.cpp"
int main()
{
abc test;
cout<<test.getx()<<endl;
return 0;
}

Quote:

---

Originally posted by kiran
try this code this is running perfectly on c++ compiler
and let me know did it solve ur problem

---

Well of course it works... Because you didn't encrypt first.cpp at all! This violate my requirement. I don't want the content of first.cpp to be visible. So, it *didn't* solve my problem...

Just a thought but maybe if you compiled the second file with:

g++ first.o second.cpp -o second.o

or

g++ first.o second.cpp -o second for an executable

it would work

Quote:

---

Originally posted by Betazep
Your encryption lay within your object code. It is suitable enough. Just give him the .obj file to link along with the function prototype list for your class. Your implementation is kept secret then...

---

Would you please explain a little bit further? What is the .obj file you are referring to?

Yeah... I already posted something to that effect. He didn't want to include the second .cpp file.

Quote:

---

Originally posted by JasonLikesJava
Just a thought but maybe if you compiled the second file with:

g++ first.o second.cpp -o second.o

or

g++ first.o second.cpp -o second for an executable

it would work

---

It works because first.cc is present. I have removed first.cc and leave first.o here. The result is an error message "first.cc not found"

The purpose of the header file is to give your notes on the class and the function prototypes only.

a function prototype would be like

int my_proto(int, float, char);

Your implementation of these functions are put in to a seperate .ccp file that includes your header. Then you compile without linking the implementation file into an object file.

You give the object file and the header (explanation of functions) to your class user. They do not get to see how you implemented the code because it is in near machine language, so it is kept secret.

The class user looks at your header file and says, "Aha. Though I do not even know how he implemented the code for these functions, I do know what they need to receive and what they return (as well as their name)."

"I know that I can use

the_class.my_proto(int, float, char)

and supply the function with an int, a float, and a char, and I will get back an int. Wonder how he did that? I guess I will never know."

In your header(description) file, you will want PRE:, POST:, and RETURN: description. They tell the class user what the function does without giving away any code.

Code:

---

// PRE:  Accepts age as an int, years of service
//      as a float, and category as a char
// POST: Performs necessary calculations on data and
//      stores information in private data members
// RETURN:  Returns a 0 if successful, a 1 if unsuccessful,
//          or a 2 if years of service incorrect

int my_proto(int,float,char);

---

From that information, you now know how to utilize the function as a class user, but you don't know what calculations and actions occur in the implementation, and since all you have is a .obj file, you will never know. Unless you pay me big money of course.

And that is the beauty of it....

But you can't compile the second without linking in the first

>>>But you can't compile the second without linking in the first

It is a mute point. We already discussed this, and he doesn't want to do that. Plus it is not recommended that you include .cpp files.

I am not recommending he include a .cpp file

I am saying you must link in the compiled .o file

ahhh... sorry. Mistook you for kiran.

The main implementation still won't compile even if you do that, because it has to be compiled before linking. Even if you include the second object file in the command line, it is only passed through the compiler and onto the linker. Good suggestion tho...

I know I've done something like this before (I used headers but I would think it would work without them)... I guess I'd need to tinker with it a bit, but I don't have a compiler on hand.


And this is a long shot but if you compiled the first into a library... who know...

ar cru firstlib.a first.o

and then compile with

g++ second.cpp -o second -lfirstlib.a -lm

Just a far out suggestion... I know this works for me. I was creating a library with a bunch of my custom functions just yesterday. Just trying to help :)

and helping your are... ;)


unfortunately tho... it doesn't compile. The reason being that the compiler takes your argument list for compile request programs and compiles them, and then links. There is no way around that. If the compiler sees code that isn't copasetic, it kicks out an error, unless that code (variable or function) is specified to be supplied externally.

BUT......

extern class object;

or

extern class name;

does not work...

There is no way around it. That is why we utilize header files....

Ah, I understand the whole compile then link thing now... yeah, I see why that wouldn't work.

To Betazep,

According to your advice, I made an admendment, see if I get your point:

Now, I have three files, the first one, namely structure.h :

// tell the structure of the class only

class abc {
private:
int x;
public:
abc();
int getx();
};

the second one, namely content.cc :

//the actual content of the class is here

#include <iostream.h>
#include "structure.h"

abc::abc() { x=99; }
int abc::getx() { return x; }

the third one, namely main.cc :

/* the main program,which is used to test against the class. And the positive output is 99 */

#include <iostream.h>
#include "structure.h"

int main() {
abc test;
cout<<test.getx()<<endl;
return 0;
}


Now, what I have to do is:

1. Compile structure.h and content.cc to content.o

2. Give content.o and structure.h to my friend. Since content.o is human unreadable, and structure.h contain un-important class structure, it is ok to give them to my friend.

3. Ask him the write main.cc to test my class.

4. Ask him to compile structure.h and main.cc to main.o . Note that main.o is still not executable because the content of class is still unknown.

5. Now, my secret content of class is contained in content.o . I should ask him to link(or compile) content.o and main.o into an ultimate executable file final.exe .

6.If the output of final.exe is 99, then the whole thing is done.

If that's what you mean, I tell you, " That works!!!"

The only drawback that I can pick out is that the structure of class is exposed (however the content is "encrypted").

Congratulation! Thanks a lot everybody, especially Betazep. ^_^

P.S. finally, extern is not used at all... If there exists any method to encrypt the structure as well, do tell me, please. I think the perfect solution may lie on extern, library utilizing, or "pimpl idiom".

class abc {
private:
int x;
public:
abc();
int getx();
};

you got it....

The thing is... who cares about the structure of the class? It means nothing. Just a bunch of lines that state which functions can be utilized. (and your class implementor needs to know that anyway... how can he/she call a public member function if the name and argument list isn't available? He/she can't...)

This is why we hide the implementation, but give them the function prototypes in the header file...

Take care... look forward to working through more issues with you in the future....

Quote:

---

Originally posted by Betazep
class abc {
private:
int x;
public:
abc();
int getx();
};

you got it....

The thing is... who cares about the structure of the class? It means nothing. Just a bunch of lines that state which functions can be utilized. (and your class implementor needs to know that anyway... how can he/she call a public member function if the name and argument list isn't available? He/she can't...)

This is why we hide the implementation, but give them the function prototypes in the header file...

Take care... look forward to working through more issues with you in the future....

---

Well, the structure of class may lead to some hints to my friend's homework. Therefore it's perfect to have it hidden too.

And you asked "how can he/she call a public member function if the name and argument list isn't available? ". In most case you are right. But you know, this is a piece of homework. So, everyone in my class know how to implement the class.

Nice to chat/work with you. You are really helpful. ;)

are you guys using the same function names though?

if you aren't then it wouldn't matter about the implementation. Nobody would be able to call a function...

if I do not know that

int abc(int);

is a member of the TEST class, then I wouldn't know I could use

TEST testing;

i = testing.abc(10);

it could be

i = testing.xyz(10);

so you have to know the function names and their arguments... else you are lost, and the class cannot be utilized.

I feel honoured to see my name up there ;)

Some general comments: The right way is doing it through header files. Create a headerfile for your class and include it in your main file. This way, your function prototypes are open to view for everyone, but if you are going to call them, they are known anyway. The implementation should be in your cpp file, which can be compiled into an object file. This is the standard way.

To clarify some things that were said:

extern

The extern keyword is for making known variables that were declared elsewhere. However, the type of variable must be know at this time. You cannot 'extern' types, only instances of known types.

There are ways around it. You can 'forward' a class or struct. This is what you want. You want to let your compiler know there exists a class ABC somewhere else. Forwarding a class or struct will let you use the type of this class as a typename, but not more.

Example:

class A;

// so called forwarding A, compiler knows there is an A, but has
// no clue what it might be able to do

class B
{
A member; // legal
};

However, if you want to do anything with the member, i.e. calling functions, initialize it etc, you have to provide a full declaration of it. This is useful for classes that somehow link to each other:

class A; // forward

class B
{
A a;
};

class A // real declaration
{
B b;
};

Any class functions dealing with the A member of B have to be written after the complete declaration of A, or they will flag syntax errors.


Conclusion: There is no way around, you need header file(s).



While things may seem logical for us, once you write your own compiler or interpreter, you will notice that for the program, it's not so obvious. Something that isn't 100% sure and error free is as good as a wild guess. And guesses lead to errors. So while it would be a good guess to say you are declaring a class with this extern and as you as the user have to know better, this has to have the function you called on it, the compiler can only hope this is right. It has no way to check, at least not in this version. And hoping for you not to make errors is not in the limits of a compiler ;) And I'm damn glad it is this way, for many of my errors would go unnoticed until the program crashes if it were the other way round ;)

Quote:

---

Originally posted by Betazep
are you guys using the same function names though?

if you aren't then it wouldn't matter about the implementation. Nobody would be able to call a function...

---

You are right. But we guys are really using the same function name. If not, my teacher would need to create a different file to test against each of our class. In order to reduce his workload, we are required to use to same class name, same member function name. Of course, for those extra member function we added in the class, the name is free for us to choose, but they won't be tested by my teacher. :D

And what I dont want to show to my friend is the name of the member functions. Because what he need to test is only one or two required member function. But then all the member function name is visible to him. But never mind, I think the memthod of "three file" is secure enough.