Would you please explain a little bit further? What is the .obj file you are referring to?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...
Yeah... I already posted something to that effect. He didn't want to include the second .cpp file.
Blue
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"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
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.
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.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);
And that is the beauty of it....
Last edited by Betazep; 03-11-2002 at 12:11 PM.
Blue
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.
Blue
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.
Blue
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...
Blue
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
Last edited by JasonLikesJava; 03-11-2002 at 12:33 PM.
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....
Blue
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....
Blue
