7 ms·

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 a

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, but seems like yet more accidental/unnecessary complexity on top of the already-probably-unnecessary private/protected/friend - as requirements change you now have this extra layer of access-control cruft to reason about, that you probably wouldn't even miss if it didn't exist. Not to get too ranty, and no disrespect to Andreas, but the C++ culture seems to thrive in unnecessary / accidental complexity, deep template hacks and the like that add friction to refactoring, obfuscate underlying logic so you miss opportunities to simplify, and turn straightforward programming problems into brain-bending template puzzles. OOP also; I've seen so many crazy class architectures that could just be a handful of plain-old-functions, complex virutal "type families" that could just be a TypeOfThingThisIs enum with some if statements in the respective functions, etc. I don't know the Serenity codebase and use-case very well, and perhaps this kind of thing has a place in large libraries, but honestly even then I'd lean towards just making everything simple & public and use a prefix when needed, or describe appropriate usage in documentation. Seems to work in the python world (minus a few outlier codebases that go OOP-crazy).

picacho 7y ago
yeah, python LOC > 5000 try to debugging it while some dude just modified your type instance's guts.
- eps 7y ago
  OP's approach works if all dudes involved read the code before chaning it and stay off private parts even if they aren't guarded by the language constructs.
  - YayamiOmate 7y ago
    So it's an implicit contract based on syntax vs explicit? It's a user/m_ prefix vs compiler/private. Im not sure if former is better. It's a strong trade off imho. In my experience relying on people reading code and agreeing on imlicit contracts does not scale beyond 5 people, but maybe I've been mistreated by life.
  - w0utert 7y ago
    That's not how software development works in e.g. companies where multiple people use the software (framework, libraries, API's) at different levels/roles. For example, if we develop some framework to be used at multiple sites in the company, we can be 100% sure that at some point someone will assume that anything marked 'public' in the API is fair game to use (which IMO is a reasonable perspective). If they start using internal API's or depend on class internals that are only public just because the language did not provide us with a reasonable way to hide them, at some point we will change them and working systems could break elsewhere. In a similar fashion, misuse of private API's by violating preconditions that are completely opaque to users of your (intended) public API can lead to the worst kinds of bugs and unpredictable runtime failures. Software development always seems so simple and pragmatic if you don't need to care about other people you have no control over.
    - mirsadm 7y ago
      Equally being too defensive and over-complicating code in case a "bad" developer makes a breaking change often leads to code that is worse in the long term.
    - eps 7y ago
      > That's not how software development works ... ... in your setup. All shops are different. To each their own. There's no private/protected scaffolding in the Linux kernel to give the most obvious example.
      - w0utert 7y ago
        Well last time I checked the Linux kernel was C and not C++, so that might explain why ;-). I don't know anything about kernel programming, but I assume that there's some very, very strict conventions about how the various parts of the Linux kernel interact, and nothing gets accepted for merging unless you follow them. This would be similar to imposing scope/visibility constraints at the language level, but considering C doesn't have anything for that, an extremely strict development process is the best you can do.
xleviator 7y ago
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<T> 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++).
- dearrifling 7y ago
  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.
  - jcl 7y ago
    I'm not sure I follow... The motivation for Badge is to have methods on VFS that only Device can call, without exposing VFS's internals to Device. Without Badge, what prevents non-Device functions from calling register_device()?
    - taylorconor 7y ago
      I guess the inline function would require a Badge and the private member function would not. So an inline constructed but never used Badge is even more likely to be completely optimized away
      - dearrifling 7y ago
        Exactly. https://godbolt.org/z/j-THTX https://godbolt.org/z/j-THTX
- maxxxxx 7y ago
  Don't you have to have pretty high performance needs for this class to make a performance difference? Unless it's called multiple thousand times per second I don't see it making much of a difference.
- vnorilo 7y ago
keyle 7y ago
I have to ask... why 'm_'?
- bronxbomber92 7y ago
  It's a simplified form of Hungarian notation: https://en.wikipedia.org/wiki/Hungarian_notation https://en.wikipedia.org/wiki/Hungarian_notation
- nxpnsv 7y ago
  I think it is supposed to mean member, but i don’t remember, common enough practice though
  - Matthias247 7y ago
    Yes it stands for member. The notation had been used in conventions like Hungarian notation (https://en.m.wikipedia.org/wiki/Hungarian_notation https://en.m.wikipedia.org/wiki/Hungarian_notation) and WinApi.
- oAlbe 7y ago
  I don't understand why you have been downvoted for asking "why m_?". Is everybody on here supposed to know everything about everything, else you get downvoted into grey unreadability? Personally, I think that bashing/penalizing ignorance (and I mean the word ignorance literally, as being uninformed about a topic, no offense here whatsoever) is one of the lowest forms of abuse. It says much more about the downvoter than it does about the downvoted. And this not even considering the fact that searching online for "m_" isn't going to help you answer your own question. If everybody just downvoted the questions they deem unworthy of an answer because "you are supposed to know this", there would be no questions answered. Sorry for the OT.
  - geezerjay 7y ago
    > I don't understand why you have been downvoted for asking "why m_?". Because complaining about coding conventions on a discussion about a design pattern is noise and adds nothing to the discussion.
enriquto 7y ago
> OOP also; I've seen so many crazy class architectures that could just be a handful of plain-old-functions, also, tons of "generic" numerical code with templates everywhere, where the only two possible instantiations are "float" and "double". Some people do really like to add useless complexity everywhere.
- _pmf_ 7y ago
  Not only is it needlessly complex, but untested generic code is a minefield of subtle future bugs ... "oh, the function is there and tested, so it should work" ... well, not in this particular combination of the completely unrestricted generic parameter set.
- edflsafoiewq 7y ago
  What's wrong with that? It seems like the easiest way to write code that works with either floats or doubles.
  - enriquto 7y ago
    > It seems like the easiest way to write code that works with either floats or doubles. You never really need to do that. In the rare cases you need to, once every five years or so, it is trivial to change your code.
  - fnord123 7y ago
    Eh... I have seen the same in Rust. People write tests with i32. i32 implements the Copy trait which means your can blindly clone it all over the place. When you try using some libraries with String or anything else they don't work.
- deleted 7y ago
  [deleted]
geezerjay 7y 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. This is the sort of accidental complexity that access specifiers eliminated, but somehow you managed to reintroduce by trying to reinvent the wheel. The 'm_' prefix only means "private member variable, don'access it" to you and you alone, and anyone who will stumble on your code will not be aware or obligated to follow your personal style. That would not be the case.if you simply used a basic feature of C++ that's been available since the time of "C with classes". To me, you're the epitome of the main source of C++'s problems: programmers who failed to learn the basics of a language and instead decided to develop convoluted hacks to circumvent proper use of the language because they believe their new discovery is clever although in reality they only managed to needlessly add complexity to a code base while adding brittle and bug-prone code. What else? Do away with memory deallocation because there's nothing of the sort in Python and your C++ code is packed with segfaults? And by the way, the pimpl pattern is used to provide libraries a stable ABI in spite of what change might be done to the implementation. It is not a fad or a clever-looking trick.
- QuadrupleA 7y ago
  Python has a well-established convention of _underscore for intended-to-be-private members, with no enforcement, and it works fine. Just document your conventions. The horrors of some other programmer using it wrong seem overblown to me. In my IDE in c++ I can quickly refactor m_ to non-m to make it "semantically public" without having to edit header files, change struct packing order / ABI, etc. And most of the time I don't even bother with m_. It's one less thing to think about. I honestly don't think access specifiers are worth wasting mental cpu cycles on in most projects. Besides, in c++ people can always cast your intricately-protected object to a void pointer and start manipulating it nefarioisly anyway. Just document and communicate, and write simple straightforward code. I used pimpl at the time for faster recompiles when changing "private" stuff. Better build tools got me around that problem personally, but I'm sure it has it's uses.
  - smadurange 7y ago
    Those access modifiers are there for a reason and they work very well in not just C++ in many other object oriented languages like C# and Java. So, using Python to justify that style of coding is a far cry from anything that is reasonable. If it work for you that's fine, but I don't think it's a good idea generally.
barrkel 7y ago
Everything public versions poorly when you can't update all clients of your code after you change your implementation. It increases coupling in ways you can't control. It also doesn't work very well with code completion - implementation methods get mixed up with surface API - and usability by third parties suffers. If you're on a team of one, and you own the project for its whole lifetime, then you're fine.
- adrianN 7y ago
  The implicit contract is that anybody who uses m_ "intended to be private" members is responsible for fixing breakage.
  - pdpi 7y ago
    I’d rather have no breakages over a breakage that’s somebody else’s fault
- QuadrupleA 7y ago
  Admittedly my use case is generally projects that are under my control. But in the case of say an open source library, how likely are clients going to update their code with each new release of the library? Typical case is to do it from time to time, especially with compiled code / shared libs, and expect a few incompatibilities to sort out and fix when you do. In a fast evolving large team project, seems it depends on how well the boundaries of the subsystems are worked out. Misusing supposed-to-be-private members is one minor possibility amidst many challenges.
zvrba 7y ago
> but a few years ago I started doing everything all-public This is a recipe for disaster as soon as inheritance is in the picture.
- QuadrupleA 7y ago
  Everything is a recipe for disaster one inheritance is in the picture :)
  - zvrba 7y ago
    That's a blind, dogmatic position. Inheritance is a tool, as everything else.
    - Retra 7y ago
      Including all-public interfaces.
akling 7y ago
This style of development obviously will not scale to large, long-term C++ projects with many developers, as anyone who has worked on such projects knows all too well. No disrespect to you, QuadrupleA, do whatever makes you the most productive, but I wouldn't want to work together with you in this way :)
- mirsadm 7y ago
  I hear this argument a lot, why would it not scale?
  - akling 7y ago
    Code/API scalability: Over a long enough time, every API will be called in every possible way. If an API misbehaves, some code somewhere will begin to rely on the specific kind of misbehavior. This is just the reality of publishing API's, so you deal with it and fix bugs as they are discovered. If you make your entire class definition public in a large project, you will eventually have code poking at the internals of your class. I've seen this countless times, it's some kind of inevitable natural thing. Developer scalability: You know everything about how your code works, but I don't. A well-defined API with clear access rules gives me a fair chance to avoid using your class in ways you didn't intend. In small-enough teams, or with small-enough projects, it's possible for everyone to understand (mostly) everything, but there's some magic number of concurrent developers where that privilege ends.
- QuadrupleA 7y ago
  It's more of a C style I guess, that I prefer, or a very selective use of C++. Certainly C has supported some big projects. Anyway language rants aside, your project looks very cool - I remember seeing it posted here a while back.
scoutt 7y ago
I come from an embedded development environment, and for me simplicity is everything. But even that, I think the approach of an "all public" class is a little bit risky, and can be a pain to debug if accidentally you change an internal state. If a class is a black box, when you put your hand inside it, it becomes the "pain box" from the Bene Gesserit.

picacho 7y ago

yeah, python LOC > 5000 try to debugging it while some dude just modified your type instance's guts.

eps 7y ago
OP's approach works if all dudes involved read the code before chaning it and stay off private parts even if they aren't guarded by the language constructs.
- YayamiOmate 7y ago
  So it's an implicit contract based on syntax vs explicit? It's a user/m_ prefix vs compiler/private. Im not sure if former is better. It's a strong trade off imho. In my experience relying on people reading code and agreeing on imlicit contracts does not scale beyond 5 people, but maybe I've been mistreated by life.
- w0utert 7y ago
  That's not how software development works in e.g. companies where multiple people use the software (framework, libraries, API's) at different levels/roles. For example, if we develop some framework to be used at multiple sites in the company, we can be 100% sure that at some point someone will assume that anything marked 'public' in the API is fair game to use (which IMO is a reasonable perspective). If they start using internal API's or depend on class internals that are only public just because the language did not provide us with a reasonable way to hide them, at some point we will change them and working systems could break elsewhere. In a similar fashion, misuse of private API's by violating preconditions that are completely opaque to users of your (intended) public API can lead to the worst kinds of bugs and unpredictable runtime failures. Software development always seems so simple and pragmatic if you don't need to care about other people you have no control over.
  - mirsadm 7y ago
    Equally being too defensive and over-complicating code in case a "bad" developer makes a breaking change often leads to code that is worse in the long term.
  - eps 7y ago
    > That's not how software development works ... ... in your setup. All shops are different. To each their own. There's no private/protected scaffolding in the Linux kernel to give the most obvious example.
    - w0utert 7y ago
      Well last time I checked the Linux kernel was C and not C++, so that might explain why ;-). I don't know anything about kernel programming, but I assume that there's some very, very strict conventions about how the various parts of the Linux kernel interact, and nothing gets accepted for merging unless you follow them. This would be similar to imposing scope/visibility constraints at the language level, but considering C doesn't have anything for that, an extremely strict development process is the best you can do.

xleviator 7y ago

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

dearrifling 7y ago
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.
- jcl 7y ago
  I'm not sure I follow... The motivation for Badge is to have methods on VFS that only Device can call, without exposing VFS's internals to Device. Without Badge, what prevents non-Device functions from calling register_device()?
  - taylorconor 7y ago
    I guess the inline function would require a Badge and the private member function would not. So an inline constructed but never used Badge is even more likely to be completely optimized away
    - dearrifling 7y ago
      Exactly. https://godbolt.org/z/j-THTX https://godbolt.org/z/j-THTX
maxxxxx 7y ago
Don't you have to have pretty high performance needs for this class to make a performance difference? Unless it's called multiple thousand times per second I don't see it making much of a difference.
vnorilo 7y ago

keyle 7y ago

I have to ask... why 'm_'?

bronxbomber92 7y ago
It's a simplified form of Hungarian notation: https://en.wikipedia.org/wiki/Hungarian_notation https://en.wikipedia.org/wiki/Hungarian_notation
nxpnsv 7y ago
I think it is supposed to mean member, but i don’t remember, common enough practice though
- Matthias247 7y ago
  Yes it stands for member. The notation had been used in conventions like Hungarian notation (https://en.m.wikipedia.org/wiki/Hungarian_notation https://en.m.wikipedia.org/wiki/Hungarian_notation) and WinApi.
oAlbe 7y ago
I don't understand why you have been downvoted for asking "why m_?". Is everybody on here supposed to know everything about everything, else you get downvoted into grey unreadability? Personally, I think that bashing/penalizing ignorance (and I mean the word ignorance literally, as being uninformed about a topic, no offense here whatsoever) is one of the lowest forms of abuse. It says much more about the downvoter than it does about the downvoted. And this not even considering the fact that searching online for "m_" isn't going to help you answer your own question. If everybody just downvoted the questions they deem unworthy of an answer because "you are supposed to know this", there would be no questions answered. Sorry for the OT.
- geezerjay 7y ago
  > I don't understand why you have been downvoted for asking "why m_?". Because complaining about coding conventions on a discussion about a design pattern is noise and adds nothing to the discussion.

enriquto 7y ago

> OOP also; I've seen so many crazy class architectures that could just be a handful of plain-old-functions, also, tons of "generic" numerical code with templates everywhere, where the only two possible instantiations are "float" and "double". Some people do really like to add useless complexity everywhere.

_pmf_ 7y ago
Not only is it needlessly complex, but untested generic code is a minefield of subtle future bugs ... "oh, the function is there and tested, so it should work" ... well, not in this particular combination of the completely unrestricted generic parameter set.
edflsafoiewq 7y ago
What's wrong with that? It seems like the easiest way to write code that works with either floats or doubles.
- enriquto 7y ago
  > It seems like the easiest way to write code that works with either floats or doubles. You never really need to do that. In the rare cases you need to, once every five years or so, it is trivial to change your code.
- fnord123 7y ago
  Eh... I have seen the same in Rust. People write tests with i32. i32 implements the Copy trait which means your can blindly clone it all over the place. When you try using some libraries with String or anything else they don't work.
deleted 7y ago
[deleted]

geezerjay 7y 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. This is the sort of accidental complexity that access specifiers eliminated, but somehow you managed to reintroduce by trying to reinvent the wheel. The 'm_' prefix only means "private member variable, don'access it" to you and you alone, and anyone who will stumble on your code will not be aware or obligated to follow your personal style. That would not be the case.if you simply used a basic feature of C++ that's been available since the time of "C with classes". To me, you're the epitome of the main source of C++'s problems: programmers who failed to learn the basics of a language and instead decided to develop convoluted hacks to circumvent proper use of the language because they believe their new discovery is clever although in reality they only managed to needlessly add complexity to a code base while adding brittle and bug-prone code. What else? Do away with memory deallocation because there's nothing of the sort in Python and your C++ code is packed with segfaults? And by the way, the pimpl pattern is used to provide libraries a stable ABI in spite of what change might be done to the implementation. It is not a fad or a clever-looking trick.

QuadrupleA 7y ago
Python has a well-established convention of _underscore for intended-to-be-private members, with no enforcement, and it works fine. Just document your conventions. The horrors of some other programmer using it wrong seem overblown to me. In my IDE in c++ I can quickly refactor m_ to non-m to make it "semantically public" without having to edit header files, change struct packing order / ABI, etc. And most of the time I don't even bother with m_. It's one less thing to think about. I honestly don't think access specifiers are worth wasting mental cpu cycles on in most projects. Besides, in c++ people can always cast your intricately-protected object to a void pointer and start manipulating it nefarioisly anyway. Just document and communicate, and write simple straightforward code. I used pimpl at the time for faster recompiles when changing "private" stuff. Better build tools got me around that problem personally, but I'm sure it has it's uses.
- smadurange 7y ago
  Those access modifiers are there for a reason and they work very well in not just C++ in many other object oriented languages like C# and Java. So, using Python to justify that style of coding is a far cry from anything that is reasonable. If it work for you that's fine, but I don't think it's a good idea generally.

barrkel 7y ago

Everything public versions poorly when you can't update all clients of your code after you change your implementation. It increases coupling in ways you can't control. It also doesn't work very well with code completion - implementation methods get mixed up with surface API - and usability by third parties suffers. If you're on a team of one, and you own the project for its whole lifetime, then you're fine.

adrianN 7y ago
The implicit contract is that anybody who uses m_ "intended to be private" members is responsible for fixing breakage.
- pdpi 7y ago
  I’d rather have no breakages over a breakage that’s somebody else’s fault
QuadrupleA 7y ago
Admittedly my use case is generally projects that are under my control. But in the case of say an open source library, how likely are clients going to update their code with each new release of the library? Typical case is to do it from time to time, especially with compiled code / shared libs, and expect a few incompatibilities to sort out and fix when you do. In a fast evolving large team project, seems it depends on how well the boundaries of the subsystems are worked out. Misusing supposed-to-be-private members is one minor possibility amidst many challenges.

zvrba 7y ago

> but a few years ago I started doing everything all-public This is a recipe for disaster as soon as inheritance is in the picture.

QuadrupleA 7y ago
Everything is a recipe for disaster one inheritance is in the picture :)
- zvrba 7y ago
  That's a blind, dogmatic position. Inheritance is a tool, as everything else.
  - Retra 7y ago
    Including all-public interfaces.

akling 7y ago

This style of development obviously will not scale to large, long-term C++ projects with many developers, as anyone who has worked on such projects knows all too well. No disrespect to you, QuadrupleA, do whatever makes you the most productive, but I wouldn't want to work together with you in this way :)

mirsadm 7y ago
I hear this argument a lot, why would it not scale?
- akling 7y ago
  Code/API scalability: Over a long enough time, every API will be called in every possible way. If an API misbehaves, some code somewhere will begin to rely on the specific kind of misbehavior. This is just the reality of publishing API's, so you deal with it and fix bugs as they are discovered. If you make your entire class definition public in a large project, you will eventually have code poking at the internals of your class. I've seen this countless times, it's some kind of inevitable natural thing. Developer scalability: You know everything about how your code works, but I don't. A well-defined API with clear access rules gives me a fair chance to avoid using your class in ways you didn't intend. In small-enough teams, or with small-enough projects, it's possible for everyone to understand (mostly) everything, but there's some magic number of concurrent developers where that privilege ends.
QuadrupleA 7y ago
It's more of a C style I guess, that I prefer, or a very selective use of C++. Certainly C has supported some big projects. Anyway language rants aside, your project looks very cool - I remember seeing it posted here a while back.

scoutt 7y ago

I come from an embedded development environment, and for me simplicity is everything. But even that, I think the approach of an "all public" class is a little bit risky, and can be a pain to debug if accidentally you change an internal state. If a class is a black box, when you put your hand inside it, it becomes the "pain box" from the Bene Gesserit.