calling functions in another class
-
For some reason I get error when I try to call a funtion in another class/file. Here is what I am doing: I have written a program that accesses a PCI card and performs functions on that card. Everything wroks fine when I call these functions from myMainFile.cpp In that file I have included the pciFunctions.h I need a class that calls these functions performs tasks on the data and returns the data to the myMainFile.cpp I need to do this so that I can display the values in various widgets. so I created a new header file and created a class. #ifndef rfmAccess_H #define rfmAccess_H #include pciFunctions //other standard includes class RFMAccess{ private: public: RFMAccess(){} int openCard(char *devPath); //this is the function prototype }; #endif *************In myMainFile.cpp*************** #include "rfmAccess.h" //I created a pointer to the class RFMAccess *RFMAccess; Then I call the function. TmyMainFileForm1::Action1Execute(TObject *Sender){ RFMAccess::openCard("////.//RFM1"); or RFMAccess.openCard("////.//RFM1"); or RFMAccess->openCard("////.//RFM1"); } Should I create the function in the rfmAccess.h or should I create another *.cpp file and do it in there? Do I have to create a prototype or can I just finish the function in the rfmAccess.h file Am I doing this right? Am I calling the function correctly? Sorry for so many questions, but I need alittle help. :) :) :) Thanks, steven
-
For some reason I get error when I try to call a funtion in another class/file. Here is what I am doing: I have written a program that accesses a PCI card and performs functions on that card. Everything wroks fine when I call these functions from myMainFile.cpp In that file I have included the pciFunctions.h I need a class that calls these functions performs tasks on the data and returns the data to the myMainFile.cpp I need to do this so that I can display the values in various widgets. so I created a new header file and created a class. #ifndef rfmAccess_H #define rfmAccess_H #include pciFunctions //other standard includes class RFMAccess{ private: public: RFMAccess(){} int openCard(char *devPath); //this is the function prototype }; #endif *************In myMainFile.cpp*************** #include "rfmAccess.h" //I created a pointer to the class RFMAccess *RFMAccess; Then I call the function. TmyMainFileForm1::Action1Execute(TObject *Sender){ RFMAccess::openCard("////.//RFM1"); or RFMAccess.openCard("////.//RFM1"); or RFMAccess->openCard("////.//RFM1"); } Should I create the function in the rfmAccess.h or should I create another *.cpp file and do it in there? Do I have to create a prototype or can I just finish the function in the rfmAccess.h file Am I doing this right? Am I calling the function correctly? Sorry for so many questions, but I need alittle help. :) :) :) Thanks, steven
johnstonsk wrote: Should I create the function in the rfmAccess.h or should I create another *.cpp file and do it in there? Technically you could do either, but most of the time you will want to create a .cpp file corresponding to your .h file and define the function there. johnstonsk wrote: Do I have to create a prototype or can I just finish the function in the rfmAccess.h file See answer above. Small technical point: what you have in the header file already *is* the prototype. johnstonsk wrote: Am I calling the function correctly? If you are calling the function via a pointer, then you'll want to use lpRFMAccess->openCard("////.//RFM1");. If you are calling the function from an object you'll want to use oRFMAccess.openCard("////.//RFM1");. There are some other problems with your code above: When you define a pointer to the RFMAccess class, you need to give it a valid name. You have written RFMAccess *RFMAccess; -- give the pointer a name other than the class name like this : RFMAccess *lpRFMAccess; Also, when you use a pointer, make sure it is valid. The way you have your code, the pointer is never made to point to a valid RFMAccess object, thus trying to call a function via your pointer will probably crash your program. --Dean
-
johnstonsk wrote: Should I create the function in the rfmAccess.h or should I create another *.cpp file and do it in there? Technically you could do either, but most of the time you will want to create a .cpp file corresponding to your .h file and define the function there. johnstonsk wrote: Do I have to create a prototype or can I just finish the function in the rfmAccess.h file See answer above. Small technical point: what you have in the header file already *is* the prototype. johnstonsk wrote: Am I calling the function correctly? If you are calling the function via a pointer, then you'll want to use lpRFMAccess->openCard("////.//RFM1");. If you are calling the function from an object you'll want to use oRFMAccess.openCard("////.//RFM1");. There are some other problems with your code above: When you define a pointer to the RFMAccess class, you need to give it a valid name. You have written RFMAccess *RFMAccess; -- give the pointer a name other than the class name like this : RFMAccess *lpRFMAccess; Also, when you use a pointer, make sure it is valid. The way you have your code, the pointer is never made to point to a valid RFMAccess object, thus trying to call a function via your pointer will probably crash your program. --Dean
Thank you, very helpful and it makes sense. You mentioned: most of the time you will want to create a .cpp file corresponding to your .h file and define the function there. what is the purpose of creating a prototype and then defining the function in another *.h file when you can do it all in one shot? Just wanting to be a better programmer. Thanks, steven
-
Thank you, very helpful and it makes sense. You mentioned: most of the time you will want to create a .cpp file corresponding to your .h file and define the function there. what is the purpose of creating a prototype and then defining the function in another *.h file when you can do it all in one shot? Just wanting to be a better programmer. Thanks, steven
It removes clutter for one. Your header should be as clean as possible. Think of it as a reference for the functions that are contained in the class. If you can't remember how to call a function, you open up the header and find the prototype -- all that extra code in the file makes that task more difficult. The other (more important) reason for separating the two is known as "separating interface from implementation". Say you write a class and someone else wants to use it later on. They don't need to know how your class works -- only that it does the job you say it will. It keeps things simple for everyone -- it's basically another layer of abstraction. Plus, if you don't want anyone to see your source code for whatever reason, you can give them the header file and a compiled library to link against and they won't be able to tell how you did what you did with your class (at least not without a bit of extra work.) Then if you change your implementation later on (say for instance you find a faster algorithm for one of your functions) all you have to do is compile a new version of your code library and give it to your users. Then rather than having to recompile their whole program, your users only need to relink their application to your new library rather than recompiling their whole program. Hope that all makes sense. --Dean
-
It removes clutter for one. Your header should be as clean as possible. Think of it as a reference for the functions that are contained in the class. If you can't remember how to call a function, you open up the header and find the prototype -- all that extra code in the file makes that task more difficult. The other (more important) reason for separating the two is known as "separating interface from implementation". Say you write a class and someone else wants to use it later on. They don't need to know how your class works -- only that it does the job you say it will. It keeps things simple for everyone -- it's basically another layer of abstraction. Plus, if you don't want anyone to see your source code for whatever reason, you can give them the header file and a compiled library to link against and they won't be able to tell how you did what you did with your class (at least not without a bit of extra work.) Then if you change your implementation later on (say for instance you find a faster algorithm for one of your functions) all you have to do is compile a new version of your code library and give it to your users. Then rather than having to recompile their whole program, your users only need to relink their application to your new library rather than recompiling their whole program. Hope that all makes sense. --Dean
very informative, thanks for the knowledge. steven