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

81–90 of 160 posts

Re: C++ Patterns: The Badge

#81

Post by taylorconor »

jcl wrote: post #79
dearrifling wrote: post #69

Earlier quoted context omitted.

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'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()?

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

Re: C++ Patterns: The Badge

#82

Post by asveikau »

gowld wrote: post #42

> These functions are called by all Device objects when they are constructed and destroyed respectively. They allow the VFS to keep track of the available device objects so they can be opened through files in the /dev directory. > Now, nobody except Device should ever be calling VFS::register_device() or VFS::unregister_device(), Why? Either have VFS call the constructor because non-registered devices are banned and…

I kind of agree that it's not clear why a VFS needs to register devices that only register themselves, however, if you suspend disbelief on that one it's a clever trick that is easy to imagine being useful.

Re: C++ Patterns: The Badge

#83

Post by dearrifling »

taylorconor wrote: post #81
jcl wrote: post #79

Earlier quoted context omitted.

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()?

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

Exactly.

https://godbolt.org/z/j-THTX

Re: C++ Patterns: The Badge

#84

Post by oAlbe »

keyle wrote: post #66
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 have to ask... why 'm_'?

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.

Re: C++ Patterns: The Badge

#85

Post by vnorilo »

dllthomas wrote: post #63
ryanianian wrote: post #30

Earlier quoted context omitted.

It's an empty struct so the compiler will elide any storage either way, but agreed having it be the first arg is a bit odd. Perhaps it's for regularity in the cases where you want to make variadic functions 'badged' in this way.

Empty structs have size 1, per the C++ spec. The compiler probably won't elide the storage unless it can show that no one probably cares.

In this case, it should absolutely do it.

Take a look: https://godbolt.org/z/DmeYL-

Re: C++ Patterns: The Badge

#86

Post by [deleted] »

mwkaufma wrote: post #22

I like it! The self-documentation of where the call is coming-from is quite nice (though a more descriptive name like CallFrom would make that even clearer, were it the principle intent). I can't help myself, though: template Badge FakeBadge() { struct Stub {} return reinterpret_cast >(Stub()); }

[deleted]

Re: C++ Patterns: The Badge

#87

Post by vnorilo »

microtherion wrote: post #27
mwkaufma wrote: post #22

I like it! The self-documentation of where the call is coming-from is quite nice (though a more descriptive name like CallFrom would make that even clearer, were it the principle intent). I can't help myself, though: template Badge FakeBadge() { struct Stub {} return reinterpret_cast >(Stub()); }

That's not a legal C++ cast, but it's conceivable that it could be made to work by casting to a reference type instead.

Badge could prevent this by making the copy and move constructors private.

Re: C++ Patterns: The Badge

#88

Post by geezerjay »

oAlbe wrote: post #84
keyle wrote: post #66

Earlier quoted context omitted.

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

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.

Re: C++ Patterns: The Badge

#89

Post by enriquto »

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

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

Re: C++ Patterns: The Badge

#90

Post by geezerjay »

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

Post reply on HN