6 ms·

I like it but is access restriction really a problem? In my years of C++ programming it always seemed to be a theoretical problem more than something that leads

I like it but is access restriction really a problem? In my years of C++ programming it always seemed to be a theoretical problem more than something that leads to crashes.

detaro 7y ago
I'd guess it's more architectural concern than runtime. Making sure only code that is supposed to uses a semi-private interface so people don't build dependencies that aren't wanted.
bdowling 7y ago
The C++ access restrictions exist solely to teach and enforce proper API usage by other developers. They're supposed to trigger a reconsideration of the API when a new developer runs into a restriction, but more often in my experience the new developer will just add a new public interface.
- kazinator 7y ago
  And you can add yourself a public interface even if all you have is a compiled library, and header files. Flipping a "private:" to "public:" has no effect on the binary compatibility.
  - slavik81 7y ago
    > Flipping a "private:" to "public:" has no effect on the binary compatibility. That's not the case on Windows. The access qualifier is part of the mangled name. https://en.wikiversity.org/wiki/Visual_C%2B%2B_name_mangling#Basic_Structure https://en.wikiversity.org/wiki/Visual_C%2B%2B_name_mangling...
    - kazinator 7y ago
      That shouldn't prevent the subversion of data members or inline functions, or the ability to add your own member functions to the class.
    - bdowling 7y ago
      It's still an honor system. There's a way to generate code that will call the "private" or "protected" data/function even if it violates what's specified in the headers.
  - dearrifling 7y ago
    It can change the "POD for the purpose of layout" status of a class on Itanium. It can change layout.
  - vnorilo 7y ago
    Because Badge is a template, this will produce a linker error (duplicate symbols). Of course you can get around if you really, really want to. But I think this subthread is starting to split hairs.
jandrewrogers 7y ago
This solves a chronic architectural maintenance problem in complex C++ code bases, which I've also run into countless times. Any visible interface, public or private (via friend), will eventually be used by other programmers for other than its intended use case simply because it is there and accessible. For the maintainer of an interface with a single intended purpose, what should be a clean, tidy modification within the scope of its intended use ends up breaking all kinds of unrelated code that the maintainer wasn't even aware of that is using the interface in ways the designer didn't anticipate. It is a common form of architectural rot. Reducing the incidence of this in large code bases is usually enforced by soft means, like sternly worded comments, vigorous policing, etc but that only goes so far. Ideally, an access policy would be in the code itself and enforced by the compiler. The public/private labels don't address this. If you make things public, the world has the ability to do unseemly things with your interface. If you friend a bunch of classes so they can access private methods, those classes have the ability to do unseemly things with your private implementation details. Both cases embrittle the architecture. What you really want is fine-grained ACLs to class members to document both intent and dependencies. This method of restricting usage of methods to specific classes at compile time is clever and provides good documentation of design intent, I haven't seen that pattern before. I also would guess that the compiler elides the Badge argument since it is never used.
- nwallin 7y ago
  There's a name for this phenomena: Hyrum's Law. > With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. http://www.hyrumslaw.com/ http://www.hyrumslaw.com/
  - kjeetgill 7y ago
    I never knew it had a "real name". I always referenced back to the comic: https://xkcd.com/1172/ https://xkcd.com/1172/ Essentially, a bugfix that prevents CPU overheating breaks someone's workflow involving a temperature sensor (jokingly).
- SolarNet 7y ago
liquidify 7y ago
This pattern is defensive by nature so people who use your library in the future will be less prone to making mistakes. Also, it shows intent to protect that asset clearly which generally leads to easier maintainability. If someone sees this guys code, they will definitely ask questions about why he is doing it, and if they are competent, they can draw the same conclusions that his blog leads you to without having to read the blog.

I like it but is access restriction really a problem? In my years of C++ programming it always seemed to be a theoretical problem more than something that leads to crashes.

detaro 7y ago

I'd guess it's more architectural concern than runtime. Making sure only code that is supposed to uses a semi-private interface so people don't build dependencies that aren't wanted.

bdowling 7y ago

The C++ access restrictions exist solely to teach and enforce proper API usage by other developers. They're supposed to trigger a reconsideration of the API when a new developer runs into a restriction, but more often in my experience the new developer will just add a new public interface.

kazinator 7y ago
And you can add yourself a public interface even if all you have is a compiled library, and header files. Flipping a "private:" to "public:" has no effect on the binary compatibility.
- slavik81 7y ago
  > Flipping a "private:" to "public:" has no effect on the binary compatibility. That's not the case on Windows. The access qualifier is part of the mangled name. https://en.wikiversity.org/wiki/Visual_C%2B%2B_name_mangling#Basic_Structure https://en.wikiversity.org/wiki/Visual_C%2B%2B_name_mangling...
  - kazinator 7y ago
    That shouldn't prevent the subversion of data members or inline functions, or the ability to add your own member functions to the class.
  - bdowling 7y ago
    It's still an honor system. There's a way to generate code that will call the "private" or "protected" data/function even if it violates what's specified in the headers.
- dearrifling 7y ago
  It can change the "POD for the purpose of layout" status of a class on Itanium. It can change layout.
- vnorilo 7y ago
  Because Badge is a template, this will produce a linker error (duplicate symbols). Of course you can get around if you really, really want to. But I think this subthread is starting to split hairs.

jandrewrogers 7y ago

This solves a chronic architectural maintenance problem in complex C++ code bases, which I've also run into countless times. Any visible interface, public or private (via friend), will eventually be used by other programmers for other than its intended use case simply because it is there and accessible. For the maintainer of an interface with a single intended purpose, what should be a clean, tidy modification within the scope of its intended use ends up breaking all kinds of unrelated code that the maintainer wasn't even aware of that is using the interface in ways the designer didn't anticipate. It is a common form of architectural rot. Reducing the incidence of this in large code bases is usually enforced by soft means, like sternly worded comments, vigorous policing, etc but that only goes so far. Ideally, an access policy would be in the code itself and enforced by the compiler. The public/private labels don't address this. If you make things public, the world has the ability to do unseemly things with your interface. If you friend a bunch of classes so they can access private methods, those classes have the ability to do unseemly things with your private implementation details. Both cases embrittle the architecture. What you really want is fine-grained ACLs to class members to document both intent and dependencies. This method of restricting usage of methods to specific classes at compile time is clever and provides good documentation of design intent, I haven't seen that pattern before. I also would guess that the compiler elides the Badge argument since it is never used.

nwallin 7y ago
There's a name for this phenomena: Hyrum's Law. > With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. http://www.hyrumslaw.com/ http://www.hyrumslaw.com/
- kjeetgill 7y ago
  I never knew it had a "real name". I always referenced back to the comic: https://xkcd.com/1172/ https://xkcd.com/1172/ Essentially, a bugfix that prevents CPU overheating breaks someone's workflow involving a temperature sensor (jokingly).
SolarNet 7y ago

liquidify 7y ago

This pattern is defensive by nature so people who use your library in the future will be less prone to making mistakes. Also, it shows intent to protect that asset clearly which generally leads to easier maintainability. If someone sees this guys code, they will definitely ask questions about why he is doing it, and if they are competent, they can draw the same conclusions that his blog leads you to without having to read the blog.