an idea for a fourth access level for class members

maybe this has been brought up before by someone else, but I was thinking it might, under some conditions, be useful to have an access level - let's call it secret for now - under which those members declared as secret would only be accessible by the instance that owns them, and not by other instances of the same class. secret static members would only be accessible by static functions.

an example:

Code:

---

class foo
{
  public:
    foo() : secretValue(314) // ok
    {
    }
    foo(const foo& rhs) : secretValue(rhs.secretValue) // error
    {
    }
    int GetSecretValue() { return secretValue; }
  secret:
    int secretValue;
}

---

what do you all think of this idea? I was thinking it might be a good way to protect resources like network sockets in classes where a given instance owns a particular resoource object.

I actually think that private should have that feature instead.
I once found it very puzzling that it was not the case. ( http://cboard.cprogramming.com/cplus...compliant.html )
Dwks's point, there, on it being a technical hindrance, makes 'some' sense to me.

in that thread they make a few very good points. the most critical one being that a "secret" member like I suggest would have to be checked at runtime, but public versus private can be done at compile time. one possible way that I can think of to avoid this would be to require any reference to a secret member to be done by explicitly specifying this->secretValue, otherwise it would throw a compiler error. that seems like a bit of a hack though, and the standards committee would certainly never agree to put that in the standard. in a managed language with reflection, I could definitely see it being a viable option, where the runtime is already checking public versus private access, and it would just be one more value in the enum of access levels.

Quote:

---

what do you all think of this idea?

---

What you are talking about can already be done by smart pointers that can't be copied or resource duplicating smart pointers with the benefit that the programmer chooses the exact behavior.

[Edit]
To be clear, the use of such smart pointers wouldn't prevent other instances of the same class to access the smart pointers of other instances.

That simply isn't an issue because the compiler doesn't generate any methods other than the few specific constructors and an operator.

That's a long way of saying: if you don't want to access a member of another instance, don't.
[/Edit]

Quote:

---

I was thinking it might be a good way to protect resources like network sockets in classes where a given instance owns a particular resoource object.

---

O_o

Any object controlling a resource that can't be copied should not provide any mechanism to create a copy.

You can't really get simpler than that. The notion of "secret" doesn't help.

If the "secret" element influences behavior and can't be conceptually copied any object pretending to provide a operation resulting in a conceptual copy is breaking its own encapsulation because the thing that claims to be a copy doesn't behave the same way.

Quote:

---

that a "secret" member like I suggest would have to be checked at runtime

---

I didn't read that thread but I can assure you that that is a violation of the spirit of the standard in any event.

The compiler doesn't check that access to a private member is legal if it happens by tricking the compiler with pointer mutation or unions.

The compiler only understands and enforces access control for the purposes of supporting "OOP" design patterns; it doesn't care if the programmer goes out of the way to violate access control.

Soma

Access control isn't about instances, it's about code. Basically, when you make something private, you don't want code outside of your class to access that member, because it is code you don't control. As the author of a class, you control all its code. It's the other code that you worry about. (Even if you write that other code yourself - once you write other code, you're no longer in the mindset of that class, meaning that you could forget the invariants it has to uphold.)
There's just no point in restricting access to the current instance, because the other instances run on the very same code, which is code you control and actively have in your mind. It's really a very easy matter of code discipline not to access other instances' private members except inside the copy/move constructor. There's really no need to get compiler support for it.

I always thought this was how private worked. But after reading the linked thread, wow, I learned something surprising and new today. Is this a C++ specific feature or is it the case for most OO languages?

There are some languages that don't have "private" as such, but instead special syntax for accessing the current instance's member variables. Ruby is one such. In such languages, I don't think there's a way to access the member variables of any instance other than the current "this".
But for languages that have access specifiers that apply to declarations, I'm not aware of any language that works differently from C++.