Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Patterns: The Badge

awesomekling.github.io

Post reply on HN
Print view View original

91–100 of 160 posts

Re: C++ Patterns: The Badge

#91

Post by akling »

Hello friends! Author here, nice to see so much discussion :)

I've spent most of my adult life working on large C++ codebases with public API's (most notably Qt and WebKit), which has led me to cultivate a defensive programming mindset. Someone mentioned Hyrum's law, which is 100% accurate in my experience.

I should be honest and admit that Badge is not yet diligently applied everywhere in the Serenity codebase. I wanted to "feel it out" for a while first, but now I've decided I like it, so I'm applying it more and more going forward.

Oh and while I have your attention, I recently posted a May 2019 update video[1] on the Serenity OS project if you're curious how things are going :)

[1] https://www.youtube.com/watch?v=KHpGvwBTRxM

Re: C++ Patterns: The Badge

#92

Post by eps »

picacho wrote: post #60
QuadrupleA wrote: post #44

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,…

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

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.

Re: C++ Patterns: The Badge

#93

Post by nercht12 »

Seems more of a people problem than a software problem. That's normal. Why not just use a comment that says "Don't use this. It will break."? If people can't obey simple instructions, you have a different problem entirely.

Re: C++ Patterns: The Badge

#94

Post by kjeetgill »

nwallin wrote: post #24
jandrewrogers wrote: post #20

Earlier quoted context omitted.

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…

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/

I never knew it had a "real name". I always referenced back to the comic: https://xkcd.com/1172/

Essentially, a bugfix that prevents CPU overheating breaks someone's workflow involving a temperature sensor (jokingly).

Re: C++ Patterns: The Badge

#95

Post by barrkel »

QuadrupleA wrote: post #44

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,…

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.

Re: C++ Patterns: The Badge

#96

Post by oAlbe »

geezerjay wrote: post #88
oAlbe wrote: post #84

Earlier quoted context omitted.

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 th…

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

I fail to see the "complaining" side in all of this. I interpreted the question as "what's the meaning behind 'm_'?". Until I read your comment, it didn't occur to me to see it in a complaining light, also because I imagine the question would have been worded differently in that case (e.g. "why m_ instead of ?").

And judging by other comments to the question, I wasn't alone, luckily.

Re: C++ Patterns: The Badge

#97

Post by akling »

jhalstead wrote: post #13

This reminds me of the Passkey idiom: https://arne-mertz.de/2016/10/passkey-idiom/

Oh wow, that's so similar! So similar in fact, that I must have seen this blog post at some point and internalized the idea :)

The improvement that Badge makes is the part; you don't need to look up the PassKey declaration to see who can construct PassKeys, it's encoded right there in the type instead.

I do like how PassKey makes the copy ctor private. I think we can improve on that and delete both the copy and move ctors in Badge.

Re: C++ Patterns: The Badge

#98

Post by barrkel »

nercht12 wrote: post #93

Seems more of a people problem than a software problem. That's normal. Why not just use a comment that says "Don't use this. It will break."? If people can't obey simple instructions, you have a different problem entirely.

Code completion doesn't necessarily read comments. Why would people read the headers before using?

If people would only obey simple rules, C++ would be a memory safe language. Alas, they don't.

Re: C++ Patterns: The Badge

#99

Post by zvrba »

QuadrupleA wrote: post #44

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 a few years ago I started doing everything all-public

This is a recipe for disaster as soon as inheritance is in the picture.

Re: C++ Patterns: The Badge

#100

Post by QuadrupleA »

geezerjay wrote: post #90
QuadrupleA wrote: post #44

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 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…

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.

Post reply on HN