an idea for a fourth access level for class members

This is a discussion on an idea for a fourth access level for class members within the C++ Programming forums, part of the General Programming Boards category; maybe this has been brought up before by someone else, but I was thinking it might, under some conditions, be ...

  1. #1
    Registered User
    Join Date
    Oct 2006
    Posts
    2,349

    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.

  2. #2
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    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.
    Last edited by manasij7479; 04-10-2012 at 12:31 PM.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  3. #3
    Registered User
    Join Date
    Oct 2006
    Posts
    2,349
    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.

  4. #4
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,214
    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
    Last edited by phantomotap; 04-10-2012 at 03:48 PM.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #6
    Registered User
    Join Date
    Nov 2008
    Posts
    119
    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?

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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++.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Access to members of protected base class
    By DL1 in forum C++ Programming
    Replies: 13
    Last Post: 07-20-2009, 10:30 AM
  2. Replies: 10
    Last Post: 07-26-2008, 08:44 AM
  3. Low Level Drive Access?
    By coldfusion244 in forum C++ Programming
    Replies: 1
    Last Post: 03-09-2005, 07:19 AM
  4. Access violation on class members
    By filler_bunny in forum Windows Programming
    Replies: 2
    Last Post: 05-03-2004, 02:58 AM
  5. Replies: 5
    Last Post: 06-04-2002, 02:33 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21