Krylar vs. Classes
Hiya,
I''m still having some troubles with classes, so I thought I''d bug you guys again for some help!
I''m trying to let one class see the contents of another classes vars and I can''t figure it out. I made a dinky little console app just to see how to do it, and that app has 3 files.
classtest.cpp (contains main())
compute.cpp (contains Makevars() and the variable iVar)
prvars.cpp (tries to print the variable iVar from compute.cpp)
Here''s the code (btw, I''m not going to put *all* the #include in here cause I wanna save space on this post):
**** START OF CODE ****
** Start of FILE: "classtest.cpp" **
#include "compute.h"
#include "prvars.h"
CCompute mCCompute;
CPRVars mCPRVars;
void main(void)
{
printf("Going to run CCcompute::Makevars()\n");
mCCompute.Makevars();
printf("Finished running CCcompute::Makevars()\n");
printf("mCCompute.Var = %d\n",mCCompute.iVar);
printf("Going to run mCPRVars:rintvars()\n");
mCPRVars.Printvars();
printf("Finished running CCcompute::Makevars()\n\n\n");
getch();
}
** Start of FILE: "compute.h" **
#ifndef _CCompute_
#define _CCompute_
class CCompute
{
public:
int iVar;
void Makevars(void);
};
#endif
** Start of FILE: "compute.cpp" **
#include "compute.h"
void CCompute::Makevars(void)
{
iVar = 10;
}
** Start of FILE: "prvars.h" **
#ifndef _CPRVars_
#define _CPRVars_
class CPRVars
{
public:
void Printvars(void);
};
#endif
** Start of FILE: "prvars.cpp" **
#include "prvars.h"
#include "compute.h"
CCompute prCompute;
void CPRVars:rintvars(void)
{
printf("PRVars sees the value from CCompute as <%d>\n",prCompute.iVar);
}
**** END OF CODE ****
I know the formatting is going to be stripped, but I hope you guys get the idea.
When I run this program it prints out all the info correctly up until the Printvars function from the CPRVars class is called. When that is called, it prints out 0 as what it percieves the value in CCompute.iVar is. But that value *should* print out as 10.
Any idea where I''m goofing up?
Thanks!
-Krylar
you could use friend class to do this. In your test, it would be more logical to regroup all this in a single object, with print and makevar as member functions and ivar as private data.
For me, friend class should be avoided for it disrupts c++ privacy structure ...
from msdn :
Friendship is not mutual unless explicitly specified as such. In the above example, member functions of YourClass cannot access the private members of YourOtherClass.
Friendship is not inherited, meaning that classes derived from YourOtherClass cannot access YourClass''s private members; nor is it transitive, so classes that are friends of YourOtherClass cannot access YourClass''s private members.
For me, friend class should be avoided for it disrupts c++ privacy structure ...
from msdn :
/*A friend class is a class all of whose member functions are friend functions of a class, that is, whose member functions have access to the other class''s private and protected members.*/// Example of the friend classclass YourClass{friend class YourOtherClass; // Declare a friend classprivate: int topSecret;};class YourOtherClass{public: void change( YourClass yc );};void YourOtherClass::change( YourClass yc ){ yc.topSecret++; // Can access private data}
Friendship is not mutual unless explicitly specified as such. In the above example, member functions of YourClass cannot access the private members of YourOtherClass.
Friendship is not inherited, meaning that classes derived from YourOtherClass cannot access YourClass''s private members; nor is it transitive, so classes that are friends of YourOtherClass cannot access YourClass''s private members.
------------------"Between the time when the oceans drank Atlantis and the rise of the sons of Arius there was an age undreamed of..."
quote: Original post by DungeonMaster
For me, friend class should be avoided for it disrupts c++ privacy structure ...
No no no Common misconception. If used wrongly, it can be a tool for evil, yes. But not always.
Observe this simplified setup for a linked list.
class LinkedListNode{private: LinkedListNode* next; LinkedListNode* prev; DataType* theData;};class LinkedList{private: LinkedListNode* first; LinkedListNode* last;public: DataType* GetFront(); DataType* GetBack();};
It is common to be able to ask a linked list for its first and last elements, as represented by the functions here. But those data elements are ''hidden'' away inside LinkedListNode. So how will LinkedList get to them?
Option 1: Make theData public.
This is obviously defeating the object of encapsulation if anything in the program can study the insides of your linked lists and change them at will.
Option 2: Make a GetData() accessor in LinkedListNode.
This might be your preferred option. But even now, -any- class or function has direct access to the internals of your linked list. If that data is a pointer to an object, it would be possible for someone to delete that object without your LinkedList knowing it is deleted, perhaps causing an error if your list assumes all its data pointers are valid.
Option 3: Make LinkedList a friend class to LinkedListNode.
Here, we have opened up LinkedListNode to -only one- other class. No-one else can interfere with it since it is private. LinkedList can interfere, but that''s ok since we deliberately made these 2 classes to work together. This is nearly always the preferred option.
Lesson ends
Make your one class a "friend" to the class it needs to see. Look up the friend keyword in your favorite c++ reference for the syntax.
ECKILLER
ECKILLER
ECKILLER
I haven''t checked everything (just woke up...), but have you tried Friend classes?
They are classes that can access Protected values without having inherited...
You should get a look on that concept to see if that''s what you want.
They are classes that can access Protected values without having inherited...
You should get a look on that concept to see if that''s what you want.
Now I know what I'm made of, and I'm afraid of it...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement