>>> "What is the answer?"
Hint: If neither file is creating it, it probably doesn't exist!
>>> "What is the answer?"
Hint: If neither file is creating it, it probably doesn't exist!
Wave upon wave of demented avengers march cheerfully out of obscurity unto the dream.
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.
Blue
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!
Wave upon wave of demented avengers march cheerfully out of obscurity unto the dream.
// extern class abc test_abc; it is equivalent ofOriginally 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.
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.
Last edited by Betazep; 03-11-2002 at 05:30 AM.
Blue
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.
Wave upon wave of demented avengers march cheerfully out of obscurity unto the dream.
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....
Blue
>>>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.
Blue
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.
(junk2.cpp is the other file).Code:#include <iostream.h> #include "Junk2.cpp" abc test_abc; int main() { cout << test_abc.get_x() << endl; return (0); }
Wave upon wave of demented avengers march cheerfully out of obscurity unto the dream.
Well, Actually, the reason is not important, but I will tell you... Don't laugh.Originally posted by Betazep
I too am duly perplexed....
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.)
Originally posted by Betazep
Maybe we need to extern the error messages...
I suggest that we should extern ourself
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...
Blue
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;
}
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...Originally posted by kiran
try this code this is running perfectly on c++ compiler
and let me know did it solve ur 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