C++ Patterns: The Badge

I used to carefully design my C++ code with public &#x2F; private &#x2F; protected &#x2F; friend (and the pointer-to-impl pattern for &quot;compile time private&quot;) 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 &quot;intended to be private&quot;, and I&#x27;ve never looked back. It&#x27;s been great, made my programming life much easier.<p>This badge thing is clever, but seems like yet more accidental&#x2F;unnecessary complexity on top of the already-probably-unnecessary private&#x2F;protected&#x2F;friend - as requirements change you now have this extra layer of access-control cruft to reason about, that you probably wouldn&#x27;t even miss if it didn&#x27;t exist.<p>Not to get too ranty, and no disrespect to Andreas, but the C++ culture seems to thrive in unnecessary &#x2F; 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.<p>OOP also; I&#x27;ve seen so many crazy class architectures that could just be a handful of plain-old-functions, complex virutal &quot;type families&quot; that could just be a TypeOfThingThisIs enum with some if statements in the respective functions, etc.<p>I don&#x27;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&#x27;d lean towards just making everything simple &amp; 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).

Hello friends! Author here, nice to see so much discussion :)<p>I&#x27;ve spent most of my adult life working on large C++ codebases with public API&#x27;s (most notably Qt and WebKit), which has led me to cultivate a defensive programming mindset. Someone mentioned Hyrum&#x27;s law, which is 100% accurate in my experience.<p>I should be honest and admit that Badge&lt;T&gt; is not yet diligently applied everywhere in the Serenity codebase. I wanted to &quot;feel it out&quot; for a while first, but now I&#x27;ve decided I like it, so I&#x27;m applying it more and more going forward.<p>Oh and while I have your attention, I recently posted a May 2019 update video[1] on the Serenity OS project if you&#x27;re curious how things are going :)<p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=KHpGvwBTRxM" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=KHpGvwBTRxM</a>

Personally I&#x27;d move the register_device() and unregister_device() functions outside of the VFS class entirely, perhaps to namespace scope.<p>Alternatively, there are other ways to leverage friendship and access control in C++. Here&#x27;s one option:<p><pre><code> template &lt;typename Registry&gt; class DeviceManager; class Device { template&lt;typename Registry&gt; friend class DeviceManager; int y; }; class VFS { friend struct DeviceManager&lt;VFS&gt;; int x; }; template &lt;typename Registry&gt; struct DeviceManager { static void register_device (Registry&amp; registry, Device&amp; device) { registry.x = 1; &#x2F;&#x2F; accessing privates device.y = 2; &#x2F;&#x2F; accessing privates } }; int main() { VFS vfs; Device dev; DeviceManager&lt;VFS&gt;::register_device (vfs, dev); } </code></pre> Here all DeviceManager&lt;&gt;&#x27;s can reach inside Devices, but only the VFS device manager can reach inside VFS.<p>This is also flexible. Remove &#x27;static&#x27; and you get yourself a stateful mediator&#x2F;manager. Add a variadic template register_devices_s_ member to Devicemanager and you&#x27;ve got yourself a convenience function for registering multiple devices (of heterogeneous types) without bloating the VFS API and, without runtime cost, and without losing type safety (by e.g. casting down to Device&amp; from USBDevice&amp;).

Could you make the badge the last argument and give it a default value, so you don&#x27;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.<p>I&#x27;m not sure if it would work, cppreference has this to say about default arguments:<p>&gt; The names used in the default arguments are looked up, checked for accessibility, and bound at the point of declaration, but are executed at the point of the function call<p><a href="https:&#x2F;&#x2F;en.cppreference.com&#x2F;w&#x2F;cpp&#x2F;language&#x2F;default_arguments" rel="nofollow">https:&#x2F;&#x2F;en.cppreference.com&#x2F;w&#x2F;cpp&#x2F;language&#x2F;default_arguments</a>

I do C++ for almost 20 years but never came across this simple technique before, so I&#x27;m quite surprised that I actually like it.<p>I usually avoid &#x27;friend&#x27; in these situations and just write<p><pre><code> &#x2F;&#x2F;private: </code></pre> before the method declaration. But it actually happened that co-workers used these private methods because they use code-completion instead of reading the header...<p>But I might would call the class Friend&lt;T&gt; or something.

I like it but is access restriction really a problem? In my years of C++ programming it always seemed to be a theoretical problem more than something that leads to crashes.

A different pattern I have thought of would be to provide an accessor interface object, and certain functionality is limited to be accessible only through that object. Controlling who has access to that interface can be flexible (possibly returning it along with construction, or passing it in at creation time...) Albeit, this is not without overhead, and for that, Badge is actually better, in terms of performance, if it fits the use case. What happens when you have multiple Device objects though, in this case, they can all access VFS..<p>--<p>C++&#x27;s private inheritance can be used here to avoid some of the gymnastics, wherein, that private aspect of the class can be passed out into the appropriate party at creation time or otherwise.<p>To illustrate: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;arithma&#x2F;0d96aec5c07e2d8dc24cfc6cd31f0c16" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;arithma&#x2F;0d96aec5c07e2d8dc24cfc6cd31f...</a><p>Note: I have never used this in production as far as I remember.

I like it! The self-documentation of where the call is coming-from is quite nice (though a more descriptive name like CallFrom&lt;T&gt; would make that even clearer, were it the principle intent). I can&#x27;t help myself, though:<p><pre><code> template&lt;typename T&gt; Badge&lt;T&gt; FakeBadge() { struct Stub {} return reinterpret_cast&lt;Badge&lt;T&gt;&gt;(Stub()); }</code></pre>

This reminds me of the Passkey idiom: <a href="https:&#x2F;&#x2F;arne-mertz.de&#x2F;2016&#x2F;10&#x2F;passkey-idiom&#x2F;" rel="nofollow">https:&#x2F;&#x2F;arne-mertz.de&#x2F;2016&#x2F;10&#x2F;passkey-idiom&#x2F;</a>

How is this different from the (relatively common afaik) passkey idiom <a href="https:&#x2F;&#x2F;arne-mertz.de&#x2F;2016&#x2F;10&#x2F;passkey-idiom&#x2F;" rel="nofollow">https:&#x2F;&#x2F;arne-mertz.de&#x2F;2016&#x2F;10&#x2F;passkey-idiom&#x2F;</a> ?

This is a typical example of a solution to an artificial, self-imposed problem created by C++&#x27;s assumptions.<p>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.

This is especially helpful in conjunction with private constructors and make_shared or make_unique. You cannot even friend make_shared because of namespace aliasing in standard libraries, but shared_from_this can make improperly allocated objects error at runtime. Private badges&#x2F;tokens solve that problem by allowing public constructors requiring a parameter value of the badge&#x2F;token type that has limited visibility, but can be constructed inside a factory and passed to make_shared.

I often wonder how this would map to other languages (as C++ often entails complexity and clever work arounds such as this article).<p>In Java or C# (and of course in C++), you could have a token system where the token can only be provided by Device :<p>VFS: void register(DeviceToken):<p>DeviceToken: empty interface (marker)<p>Device: private DeviceToken provideDeviceToken();<p>This hides both VFS and Device classes from accessing each others&#x27; private members.<p>You can also constrain how gets to provide DeviceToken by adding sufficient comments in code.

C++ could solve this without badges, if it didn&#x27;t have a very tiny, silly misfeature.<p>The misfeature is this: a class A can only declare a specific member function of class B as a <i>friend</i>, if that B member function is public!<p>Example:<p>The idea here is that Device has a static member function called <i>Device::registrationHelper</i>. That specific function (not the entire Device class) is declared a friend to VFS, and so that function can call <i>VFS::registerDevice</i>.<p>[Edit: this doesn&#x27;t quite match the Badge solution, though. If this worked, it would have the problem that the <i>registrationHelper</i> has access to all of <i>VFS</i>, which is almost as bad as the entire <i>Device</i> class being a friend of <i>VFS</i>. That is one of the problems which motivate Badge. Nice try, though! The C++ restriction is probably worth fixing anyway. What the C++ friendship mechanism really needs here is to be able to say that a specific member function in B is allowed to access a specific member of A.]<p><pre><code> class Device; class VFS; class Device { public: &#x2F;&#x2F; we want this private! static void registrationHelper(VFS &amp;v, Device &amp;d); private: void registerWith(VFS &amp;vfs) { registrationHelper(vfs, *this); } }; class VFS { private: void registerDevice(const Device &amp;); friend void Device::registrationHelper(VFS &amp;, Device &amp;); }; void Device::registrationHelper(VFS &amp;v, Device &amp;d) { v.registerDevice(d); } </code></pre> But we are forced to make <i>Device::registrationHelper</i> public, which defeats the purpose: anyone can call it and use it is a utility to register devices with VFSs.<p>If we make Device::registrationHelper private to prevent this, then the &quot;friend void Device::registrationHelper&quot; declaration in VFS fails.<p>This is an oversight; the privacy of the <i>Device::registrationHelper</i> identifier means that the <i>VFS</i> class is not even allowed to mention its name for the sake of declaring it a friend.<p>That should be fixed in C++. Declaring a function a <i>friend</i> shouldn&#x27;t require it to be accessible; we are not lifting its address or calling it; we are just saying that it can call us. Allowing a function to call us is not a form of <i>access</i> to that function, yet is being prevented by <i>access</i> specifiers.

I might be wrong, but doesn&#x27;t it look like a way to enforce SRP violation? In the provided example we don&#x27;t only let the device know how to register itself via VFS, but we also make sure there will be no future DeviceManager to do that. Unless we duplicate the entire interface with Badge&lt;DeviceManager&gt; tag. Am I missing any non-obvious benefits of this approach?

While this is a clever little pattern, I&#x27;d argue that if you have a method of class X that can only be called from class Y, that is a code smell.

Up to this point the comments seem to be missing the obligatory &quot;Treasure of the Sierra Madre&quot; reference, so here I am fixing that.

In D, you can access private members of a class within a single module. I like it, because it allows to move methods outside of the class, but doesn&#x27;t require explicit friend declarations. And you still have the data protection because other modules can&#x27;t access the private fields.

I had never seen this before, I cannot think of another way to do this. I suspect it has 1 byte overhead (on the stack) cost, but that&#x27;s pretty cheap and may be optimized out.

How can {} return a Badge object? Some kind of operator overload?

So a badge seems a bit like a capability. Clever; I like it.

This is essentially a capability system enforced by the compiler, which means your code is not actually in control for any third party caller.<p>A glaring security hole. Any old hacker can forge or clone a data structure. This &quot;badge&quot; (AKA token) has to be explicitly unpredictably replay-proof generated and hard to forge, and also automatically verified.

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

whats the advantage over declaring register_device as a functor object from an anon class? for example:<p><pre><code> class Device; class VFS { public: class { friend Device; void operator()(int y) {&#x2F;* do stuff with y here*&#x2F;}} register_device; }; class Device { public: void foo(VFS fs) { fs.register_device(1); } }; int main(int argc, char *argv[]) { &#x2F;&#x2F; fails: &#x2F;&#x2F; VFS().register_device(2); &#x2F;&#x2F; works: Device().foo(VFS()); return 0; } </code></pre> and no need for a badge class (erm... well but an anon class).<p>my c++ skills are a bit rusty, because most of the time python works just fine.

Wouldn&#x27;t -Wextra yell about the Badge being an unused parameter in the register devices? You would have to do some kind of dummy call that the compiler would have to optimize away.

&gt; 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 &#x2F;dev directory.<p>&gt; Now, nobody except Device should ever be calling VFS::register_device() or VFS::unregister_device(),<p>Why?<p>Either have VFS call the constructor because non-registered devices are banned and RAII is good, or don&#x27;t create arbitrary restrictions to hamstring how the rest of the system manages Devices.

Isn’t this exactly the problem that categories in Objective C solve? Why not adopt that pattern versus this “Badge” thing?