71–80 of 160 posts
I used to carefully design my C++ code with public / private / protected / friend (and the pointer-to-impl pattern for "compile time private") but a few years ago I started doing everything all-public ala python (struct instead of class by default) with occasionally an m_ prefix for "intended to be private", and I've never looked back. It's been great, made my programming life much easier. This badge thing is clever,…
In larger codebases with many developers, attention to the API is required in order to be able to maintain code without breaking clients. The main downside of Badge is that it comes with a performance penalty and ABI change for something that should be statically deducible (empty struct is one byte in C++).
This is a typical example of a solution to an artificial, self-imposed problem created by C++'s assumptions. As a programmer, I would feel frustrated to have to figure this out instead of spending time on something a user would actually care about.
Which popular programming languages provide proper ACLs (or equivalent functionality) for class members?
Earlier quoted context omitted.
I have to ask... why 'm_'?
I think it is supposed to mean member, but i don’t remember, common enough practice though
Earlier quoted context omitted.
Which popular programming languages provide proper ACLs (or equivalent functionality) for class members?
I'm aware of C++ and Xojo for sure.
Arguably the Badge pattern as presented in the article is just an honor system that provides zero security, since it's trivial to forge a fake Badge: https://repl.it/repls/BountifulQuerulousCron
While this is a clever little pattern, I'd argue that if you have a method of class X that can only be called from class Y, that is a code smell.
To me this is a violation of the Interface Segregation Principle. I think the author went the right way to fix it, but not far enough.
He added a parameter to segregate the device registration operations from other operations. It works, but the segregation is artificial : you still need a Device object (which seems to be used by a lot of classes, another smell, god object ?)
Instead of asking for an entire Device object, register_device should ask for a different type, specific to that operation, like « NewDevice », « UnregisteredDevice », etc. This object would depend on very specific information only available at the device creation. Now, if another developer tried to call register_device, he would need to create a weird object that he never heard of, with parameters he cannot even provide.
Thoughts ?
I used to carefully design my C++ code with public / private / protected / friend (and the pointer-to-impl pattern for "compile time private") but a few years ago I started doing everything all-public ala python (struct instead of class by default) with occasionally an m_ prefix for "intended to be private", and I've never looked back. It's been great, made my programming life much easier. This badge thing is clever,…
I have to ask... why 'm_'?
Earlier quoted context omitted.
In larger codebases with many developers, attention to the API is required in order to be able to maintain code without breaking clients. The main downside of Badge is that it comes with a performance penalty and ABI change for something that should be statically deducible (empty struct is one byte in C++).
You can make register_device() an inline function that just calls a do_register_device() private function without the badge. That way you don't have to pay for the empty class.
I used to carefully design my C++ code with public / private / protected / friend (and the pointer-to-impl pattern for "compile time private") but a few years ago I started doing everything all-public ala python (struct instead of class by default) with occasionally an m_ prefix for "intended to be private", and I've never looked back. It's been great, made my programming life much easier. This badge thing is clever,…
In larger codebases with many developers, attention to the API is required in order to be able to maintain code without breaking clients. The main downside of Badge is that it comes with a performance penalty and ABI change for something that should be statically deducible (empty struct is one byte in C++).
You can have a look here: https://godbolt.org/z/DmeYL-