0

I have a two-part question. First, I understand that C++ provides only class-level data encapsulation, meaning that all objects of the same class have access to one another's private members. I understand the reason for this, but have found some links (i.e. http://www.programmerinterview.com/index.php/c-cplusplus/whats-the-difference-between-a-class-variable-and-an-instance-variable/) which appear to contradict this point, suggesting that I could do the following:

class testclass {
  private:

  // Below would be an instance-level variable, and new memory for it is set aside 
  // in each object I create of class testclass 
  int x;

  // Below would be a class-level variable, memory is set aside only once no matter 
  // how many objects of the same class 
  static int y;
}

What I would like to do is actually make this work, i.e., I would like to define a variable in a class which is private in each instantiation (this is my second question). Since the code snippet above does not appear to achieve this, is there a work around I can use to create data that is private to individual objects? Thank you!

EDIT:

It's true that I'm still learning OO basics. I'll use the ubiquitous car example to show what I'm trying to do, which I'm sure must be a common thing to try. I'd welcome any suggestions for how to rethink it:

class car {
  private:
    int mileage;
  public:
    car(int); // Constructor
    void odometer();
};

car::car(int m) {
  mileage = m;
}

void car::odometer() {
  return mileage;
}

int main(void) {
  car ford(10000), honda(20000);

  cout<<ford.odometer(); //Returns 20000, since honda constructor overwrites private variable 'mileage'
}

Is there any way to get the odometer() method to return the mileage of either the ford or honda, depending on what I want?

Taylor
  • 59
  • 2
  • 5
  • 1
    What is the first question? And why do you want to protect instances against accessing each other's member variables? – Udo Klein Mar 07 '13 at 17:16
  • `//Returns 20000, since honda constructor overwrites private variable 'mileage'` This is totally wrong. Did you verify this? It overwrites its *own* member, sure, but why would it touch anything else? – GManNickG Mar 08 '13 at 21:18

1 Answers1

1

Priviledge (public, private, protected) only applies to names. Only during the time when a name is resolved will the compiler apply permissions. Once compiled, all such information is gone.

In your example above, all uses of the names x and y within a scope that resolves to THOSE variables will be private to your class. Only functions declared in your class, be they static or not, will be able to access those variables by name.

All bets are off however if you give out the variable to other objects that can then refer to the variable by other names which have other permissions.

I'm not sure what you're asking with reference to "in each instantiation". AFAIK, there is no native way to make a variable private such that only that instance can access it. In all cases, instances can access each other's private parts.

There's some ways you could get around this I suppose. First is to templatize your class and give each instance a different type. You could do this with an integer template parameter or something. This could make life annoying though as you try to work with these types as the same kind of thing. You'd have to virtualize and have an abstract base class or something.

Currently that's the only method I can think of. All others depend on calling entities playing nice.

Generally speaking it's rare that you'd want to protect members from other instances. The usual case of the same type being passed to the same type is during copy and assignment, where you basically need all knowledge about the source to correctly copy. My bet is that you need to rethink what you're trying to do, whatever that is.

Edward Strange
  • 40,307
  • 7
  • 73
  • 125
  • @user1207789 - per your edit... I don't get the result you say you get. After making the source compilable: http://stacked-crooked.com/view?id=46205e48402d8726f99e1c9c5946ab0c-18aa934a8d82d638dde2147aa94cac94 – Edward Strange Mar 07 '13 at 18:38
  • Hm @crazyeddie, interesting point. I don't see the difference between my example above and the program I'm actually trying to write, though, yet you're right, this little example doesn't illustrate my problem. I'll post a new question in a day or so. – Taylor Mar 08 '13 at 19:52
  • Alright I've started a clearer question here: http://stackoverflow.com/questions/15303398/private-class-members-not-fully-encapsulated – Taylor Mar 08 '13 at 21:14