C++ Patterns: The Badge

The best guard against unintended uses that hamstring the maintenance of the library is the good old opaque handle:

   typedef struct foo_struct *foo;

   foo foo_make();
   void foo_destroy(foo);
   void foo_frobnicate(foo, int how);

The client executables have no idea how big a foo object is, or what alignment requirements are, let alone what its members might be. The client executables don't control the allocation, construction, clean-up, freeing, or anything else.

The programmers who use this cannot just edit a header file to gain access to something; the don't have a header file which tells them anything. They could reverse engineer the data structure, but to thwart that, you could scramble the order of the structure members with each new release of the component, so their hack wouldn't be backward or forward compatible.

Yes, this has various names. "Ticket" is traditional.

C++ could solve this without badges, if it didn't have a very tiny, silly misfeature.

The misfeature is this: a class A can only declare a specific member function of class B as a friend, if that B member function is public!

Example:

The idea here is that Device has a static member function called Device::registrationHelper. That specific function (not the entire Device class) is declared a friend to VFS, and so that function can call VFS::registerDevice.

[Edit: this doesn't quite match the Badge solution, though. If this worked, it would have the problem that the registrationHelper has access to all of VFS, which is almost as bad as the entire Device class being a friend of VFS. 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.]

  class Device;

  class VFS;

  class Device {
  public:  // we want this private!
     static void registrationHelper(VFS &v, Device &d);
  private:
     void registerWith(VFS &vfs) { registrationHelper(vfs, *this); }
  };

  class VFS {
  private:
     void registerDevice(const Device &);
     friend void Device::registrationHelper(VFS &, Device &);
  };

  void Device::registrationHelper(VFS &v, Device &d)
  {
     v.registerDevice(d);
  }

But we are forced to make Device::registrationHelper public, which defeats the purpose: anyone can call it and use it is a utility to register devices with VFSs.

If we make Device::registrationHelper private to prevent this, then the "friend void Device::registrationHelper" declaration in VFS fails.

This is an oversight; the privacy of the Device::registrationHelper identifier means that the VFS class is not even allowed to mention its name for the sake of declaring it a friend.

That should be fixed in C++. Declaring a function a friend shouldn'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 access to that function, yet is being prevented by access specifiers.

Problem is, nothing elides the presence of these obtrusive badge parameters in the source code.

A few bytes of stack is the least of my concerns on some file system device registration function that is called five times when the system boots.

If we imagine a software organization "going to town" with this badge approach so that there are badges all over the code base, it's not hard to imagine how it would be a nuisance.

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