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

141–150 of 160 posts

Re: C++ Patterns: The Badge

#141

Post by eps »

w0utert wrote: post #117
eps wrote: post #92

Earlier quoted context omitted.

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.

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

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

Re: C++ Patterns: The Badge

#142

Post by brianush1 »

GrayShade wrote: post #120
a1369209993 wrote: post #53

Earlier quoted context omitted.

It does, however, work fine if you use a proper "* (Badge * )&stub" cast.

Isn't casting unrelated types undefined behavior?

Yes, in the standard it isn't defined, but on most--or maybe even all?--systems and compilers it's perfectly defined, since there is no reason why a compiler would layout two different empty structs in different ways; they're both empty anyways.

Edit: Actually, from reading some of the other comments in the thread, the standard apparently specifies that empty structs are 1 byte in size, so technically they would both be the same size, so casting between them should be fine.

Re: C++ Patterns: The Badge

#143

Post by eps »

astonex wrote: post #118
eps wrote: post #92

Earlier quoted context omitted.

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.

>if all dudes involved read the code before chaning it And that's only ever possible if you're the only "dude", and your codebase is like <10k loc

No, not really. It works quite well for large projects too. Just look at any open source that is C-based.

The only mechanism for safe-guarding access to private parts is using privately defined structs that are passed around in a form of opaque pointers. Some project use it (PGPphone did, the original SSH did, etc.), some don't, e.g. BSD and Linux kernels.

It's really more of a matter of developers exercising some basic thought when using other people's code. And it just happens so that there's more of them outside of the C++ group than in it.

Re: C++ Patterns: The Badge

#144

Post by w0utert »

eps wrote: post #141
w0utert wrote: post #117

Earlier quoted context omitted.

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

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

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.

Re: C++ Patterns: The Badge

#145

Post by scoutt »

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

Re: C++ Patterns: The Badge

#146

Post by xleviator »

vnorilo wrote: post #110
xleviator wrote: post #106

Earlier quoted context omitted.

Sure within a single compilation unit. Otherwise, I like dearrifling's suggestion.

The example also shows a call to a different translation unit. There's no code for passing the empty struct. There's also none for handling it, as you can see from the assembly output. The one byte rule does nothing here, because its value is undefined and its address not observable. edit: if you find a case where an empty struct parameter causes code to be emitted, let's consider filing bugs.

Oops, I did miss that, but this seems to be compiler or calling convention specific. x86_64 gcc 9.1, linked, shows no difference. However arm64 gcc 8.2 and x86-64 clang show a difference.

Re: C++ Patterns: The Badge

#147

Post by dllthomas »

vnorilo wrote: post #85
dllthomas wrote: post #63

Earlier quoted context omitted.

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-

I'm surprised, particularly about the cross-linking bit as that seems to violate the spec (per my recollection of the spec, which is the most likely thing to be wrong).

It's worth noting that it does apply to the latest gcc and Clang but not to all the compilers listed there. For an example of a difference, the latest djggp (7.2.0) inserts an extra push in the call when the empty argument is present.

Re: C++ Patterns: The Badge

#148

Post by vnorilo »

dllthomas wrote: post #147
vnorilo wrote: post #85

Earlier quoted context omitted.

In this case, it should absolutely do it. Take a look: https://godbolt.org/z/DmeYL-

I'm surprised, particularly about the cross-linking bit as that seems to violate the spec (per my recollection of the spec, which is the most likely thing to be wrong). It's worth noting that it does apply to the latest gcc and Clang but not to all the compilers listed there. For an example of a difference, the latest djggp (7.2.0) inserts an extra push in the call when the empty argument is present.

If you use a calling convention that mandates the use of stack, you would see that push, or at least have a byte reserved.

AFAICT the C++ standard itself does not specify the particulars of calling convention, which is a function of the platform, compiler and flags/attributes.

Re: C++ Patterns: The Badge

#149

Post by vnorilo »

xleviator wrote: post #146
vnorilo wrote: post #110

Earlier quoted context omitted.

The example also shows a call to a different translation unit. There's no code for passing the empty struct. There's also none for handling it, as you can see from the assembly output. The one byte rule does nothing here, because its value is undefined and its address not observable. edit: if you find a case where an empty struct parameter causes code to be emitted, let's consider filing bugs.

Oops, I did miss that, but this seems to be compiler or calling convention specific. x86_64 gcc 9.1, linked, shows no difference. However arm64 gcc 8.2 and x86-64 clang show a difference.

thanks for clarification! you’re of course right about the calling convention.

Re: C++ Patterns: The Badge

#150

Post by Retra »

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…

"c++ m_ prefix" turns up several hits for me.
Post reply on HN