an idea for a fourth access level for class members

**Elkvis** · 04-10-2012

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.

**manasij7479** · 04-10-2012

I actually think that private should have that feature instead.
I once found it very puzzling that it was not the case. ( Is the following code Standard compliant ? )
Dwks's point, there, on it being a technical hindrance, makes 'some' sense to me.

**Elkvis** · 04-10-2012

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.

**phantomotap** · 04-10-2012

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]

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.

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

**CornedBee** · 04-12-2012

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.

**homer_3** · 04-13-2012

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?

**CornedBee** · 04-13-2012

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++.

Thread: an idea for a fourth access level for class members

Thread Tools

Search Thread

Display

an idea for a fourth access level for class members

Similar Threads

Access to members of protected base class

free functions (or static members) to access private function from different class

Low Level Drive Access?

Access violation on class members

hi, is it possible to access the prviate members of a class using a friend function?