Protected / Private Variables accessable.

Yop guys,

I have this bizzare (to me) question. I have a simple class:

Code:

---

class Koala
{

public:

  Koala();
  Koala(const char* name);
  ~Koala();
  Koala&        GetPartner();
  void          KillPartner();

private:

  const char*  _name;
  Koala*        _partner;
  bool          _hasPartner;

};

---

Here is one of the methods:

Code:

---

void            Koala::KillPartner()
{
  Koala        *tmp;

  if (this->_hasPartner == true)
    {
      tmp = &(this->GetPartner());  // So I have his next partner which is another instance of the object.
      //And here I can access all of his private variables...
      delete tmp;
    }
}

---

Now I am able to access ALL the private variables, of all my different instances of the object. (Koala A; Koala B; And Koala B can access private variables of Koala A as long as I have a pointer to the object).

I compile like this: "g++ -W -Wall *.cpp".

So my question.. How come it works? Arent Private/Protected variables supposed to be protected from each other? Or are all private variables, private between all the instances of the same object.

Thank you guys!

Quote:

---

Originally Posted by +Azazel+

Or are all private variables, private between all the instances of the same object.

---

Yes, rather, a class can access any protection level (public, protected, private) of any of it's own instances (aside from a possible detail someone's going to correct me about from the standard's sections). Basically an implicit friendship, why wouldn't you be friends with yourself?

If this weren't the case, I would pull my hair out writing copy constructors.

if private variables were private to a particular instance of a class, and not just within the scope of the class, copy construction and assignment would be impossible.

Also, the point of private members is code encapsulation. It's about separating code, not instances. It allows separate development of the internal object implementation and the external use (ideally). Having a class member access the implementation details of another instance of itself does not hinder this separate development.

It seems logical that a class can access the internals of an external instance of a class of the same type as the class itself, because otherwise implementing a lot operators (like operator =, etc) would be impossible (or very messy), since the class would need to access the external instance's internals.

As a side note suggestion, I'd advise for you to review your variable naming convention for private members of a class. I too use a specific convention for private members. I find terrifically useful while designing my classes and their relationships , since I can identify a private member at a glance.

In your case you are opting for starting the identifier with an underscore. Nothing wrong with this. But besides identifiers starting with a double underscore, the standard also reserves identifiers that start with an underscore followed by a uppercase letter.

While you aren't breaking this, you get close to it and identifiers like

Code:

---

_longitude //ok
_Longitude // potential problem. Reserved.

---

become less obvious to the eye (where the convention you may choose is more important). It's not a big deal, anyway. But I'd suggest something a little different. For instance moving the underscore to the end of the identifier. So,

Code:

---

const char*  name_;
Koala*        partner_;
bool          hasPartner_;

---

This is what I do personally. But it's not my intention to have you do as I do. Simply to point out what I believe is a small problem in your convention.

I like the prefix m_.
const char* m_name;
Koala* m_partner;
bool m_hasPartner;

I don't prefix or suffix my C++ code. Just like most people don't in scripting languages. I find it more aesthetically pleasing and easy to read (and I always explicitly use the 'this' variable so I don't need to prefix member variables), IDE's help with this, and I never use reserved names anyway. Although when I do use a prefix/suffix, I use an underscore suffix like Mario F, mostly because that seems to be well adopted by Boost (Asio specifically). I used to use m_, and even mb_, mi32_ and other verbose names, merely because I read it in a book (which I then read was stupid if you ended up changing the type).

That's just me. Haven't had a problem yet.

Quote:

---

Yes, rather, a class can access any protection level (public, protected, private) of any of it's own instances (aside from a possible detail someone's going to correct me about from the standard's sections). Basically an implicit friendship, why wouldn't you be friends with yourself?

If this weren't the case, I would pull my hair out writing copy constructors.

---

I still shiver a bit when a copy constructor or something accesses another class's private members. I much prefer to use protected functions or something to do the same job . . . though whether that actually makes the code any easier to maintain and whatnot is something I haven't figured out. Just a personal opinion.

[Okay, I give. What's the possible little detail?]

If it was not possible for one instance to access the private members of another instance it would actually hurt encapsulation. The class would have to expose accessors to allow access to the internal state (for copy construction and other useful things), but then these accessors would be available in general and other code could then use them to access internal state it has no reason to access.

The alternative would be to declare the class to be a friend of itself, which seems really weird.

I didn't suggest using public accessors . . . I suggested (at least I hope I did) that one use protected accessors. That way, private data is only used inside a class itself, and if it wants to access data from another instance of itself, it has to go through the protected interface. As I mentioned, it's just a personal opinion, one which will probably disappear the moment I try to code a sticky situation which the abovementioned private access would make much easier. :)

Quote:

---

Originally Posted by dwks

I didn't suggest using public accessors . . . I suggested (at least I hope I did) that one use protected accessors. That way, private data is only used inside a class itself, and if it wants to access data from another instance of itself, it has to go through the protected interface.

---

Why protected instead of private? After all, this is merely a convention, but making them protected means that subclasses can access them when they perhaps should not.

Yes, of course. Really, there should perhaps be another access level for "other instances of the same class, or subclasses thereof" (as if C++ needs another access level . . .).

I guess it's another side of the old argument: should a class access its private variables directly, or through accessor methods? Because the protected methods I mentioned could easily be private ones . . . in which case it's a question of whether that makes the code any easier to use.

You wouldn't happen to know what the "possible detail" is, would you?

Quote:

---

Originally Posted by dwks

You wouldn't happen to know what the "possible detail" is, would you?

---

It is possible that it does not exist, or that Dae had something in mind that is not implied, and merely wanted to "protect" himself/herself pre-emptively.

Quote:

---

Originally Posted by laserlight

merely wanted to "protect" himself/herself pre-emptively.

---

Haha, yup that's it. As the first response I always feel like someone's going to come up behind and me and quote some random part of the standard ("actually Dae is wrong because section 3.2.9 says this and that"). I'd like to at least imply I don't know exactly what I'm talking about, so I don't warp the OP. I haven't read barely any of the standard, and haven't followed a book in a long time. Been meaning to get around to that.

Quote:

---

Originally Posted by dwks

Yes, of course. Really, there should perhaps be another access level for "other instances of the same class, or subclasses thereof" (as if C++ needs another access level . . .).

---

How about a modifier, haha? Could always use more of those. o.o

Trouble with prefixes and suffixes is that they don't mix with auto generated accessors and mutators.

I see. I couldn't think of any situation in which a class could not access private members of another instance of the same class, though I did wrack my brain (static variables? variables inherited from some base class?). :)

Quote:

---

mutilators

---

I laughed when I read that (no offense, I just thought it was funny) . . . not sure if it was intentional, but the term is usually "mutators". :)

*sneaks up behind prefixed member variable and beats upon bits with handy bitmask*
"That's one for unsuffix'd-kind!"

Yeah, I spelled it like that first, but my spell check picked it up, and I obviously didn't look closely enough at the choices. Fixed now.

Quote:

---

Originally Posted by dwks

I didn't suggest using public accessors . . . I suggested (at least I hope I did) that one use protected accessors. That way, private data is only used inside a class itself, and if it wants to access data from another instance of itself, it has to go through the protected interface. As I mentioned, it's just a personal opinion, one which will probably disappear the moment I try to code a sticky situation which the abovementioned private access would make much easier. :)

---

Why have accessors at all? That's like saying "I, as the implementor of this class, do not know how the thing I am implementing is implemented, therefore I will protect myself from my own implementation changes by making my own implementation inaccessible to myself."

So suppose you have a protected accessor called GetWidth(). Presumably this guards against changes to the implementation. But if the implementation does change, you now have to change GetWidth() instead of some other piece of code. What advantage does that have?

Now, it's possible that GetWidth() has to perform some complicated calculation in order to return a result, and so logically belongs in its own method. But that's a case of properly abstracting and refactoring code, nothing to do with visibility.

POST EDITED: Was reading protected an still thinking in terms of public. What a nut! Really shouldn't reply to posts at 3am.

Quote:

---

Originally Posted by brewbuck

So suppose you have a protected accessor called GetWidth(). Presumably this guards against changes to the implementation. But if the implementation does change, you now have to change GetWidth() instead of some other piece of code. What advantage does that have?

---

Hmm... the alternative would be to have a protected data member, but this may not be desirable if you wish to implement read-only or write-only access to a base-class data member from within derived classes.

I believe it may also be useful if you expect considerably changes to the base-class sometime in the future and want to guard against having to change all of the derived classes. Essentially bringing functional abstraction onto the class hierarchy, if you predict the need.

On a third and final note it may just be that you do trust your own implementation, but you don't want to trust it to anyone deriving from your class :)