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

61–70 of 160 posts

Re: C++ Patterns: The Badge

#61

Post by kazinator »

slavik81 wrote: post #39
kazinator wrote: post #32

Earlier quoted context omitted.

And you can add yourself a public interface even if all you have is a compiled library, and header files. Flipping a "private:" to "public:" has no effect on the binary compatibility.

> Flipping a "private:" to "public:" has no effect on the binary compatibility. That's not the case on Windows. The access qualifier is part of the mangled name. https://en.wikiversity.org/wiki/Visual_C%2B%2B_name_mangling...

That shouldn't prevent the subversion of data members or inline functions, or the ability to add your own member functions to the class.

Re: C++ Patterns: The Badge

#62

Post by xleviator »

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

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

Re: C++ Patterns: The Badge

#63

Post by dllthomas »

ryanianian wrote: post #30
sorenjan wrote: post #19

Could you make the badge the last argument and give it a default value, so you don't need the initialization at the function call? It looks a bit strange and would need an explanation for why the empty initialization list is there IMO. I'm not sure if it would work, cppreference has this to say about default arguments: > The names used in the default arguments are looked up, checked for accessibility, and bound at th…

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.

Re: C++ Patterns: The Badge

#65

Post by inetknght »

jandrewrogers wrote: post #50
henning wrote: post #45

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?

I'm aware of C++ and Xojo for sure.

Re: C++ Patterns: The Badge

#66

Post by keyle »

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_'?

Re: C++ Patterns: The Badge

#67

Post by nxpnsv »

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 think it is supposed to mean member, but i don’t remember, common enough practice though

Re: C++ Patterns: The Badge

#68

Post by mindfulplay »

I often wonder how this would map to other languages (as C++ often entails complexity and clever work arounds such as this article).

In Java or C# (and of course in C++), you could have a token system where the token can only be provided by Device :

VFS: void register(DeviceToken):

DeviceToken: empty interface (marker)

Device: private DeviceToken provideDeviceToken();

This hides both VFS and Device classes from accessing each others' private members.

You can also constrain how gets to provide DeviceToken by adding sufficient comments in code.

Re: C++ Patterns: The Badge

#69

Post by dearrifling »

xleviator wrote: post #62
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,…

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.

Re: C++ Patterns: The Badge

#70

Post by dearrifling »

kazinator wrote: post #32
bdowling wrote: post #17

Earlier quoted context omitted.

The C++ access restrictions exist solely to teach and enforce proper API usage by other developers. They're supposed to trigger a reconsideration of the API when a new developer runs into a restriction, but more often in my experience the new developer will just add a new public interface.

And you can add yourself a public interface even if all you have is a compiled library, and header files. Flipping a "private:" to "public:" has no effect on the binary compatibility.

It can change the "POD for the purpose of layout" status of a class on Itanium. It can change layout.
Post reply on HN