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

131–140 of 160 posts

Re: C++ Patterns: The Badge

#131

Post by h8hawk »

smadurange wrote: post #104
QuadrupleA wrote: post #100

Earlier quoted context omitted.

Python has a well-established convention of _underscore for intended-to-be-private members, with no enforcement, and it works fine. Just document your conventions. The horrors of some other programmer using it wrong seem overblown to me. In my IDE in c++ I can quickly refactor m_ to non-m to make it "semantically public" without having to edit header files, change struct packing order / ABI, etc. And most of the time…

Those access modifiers are there for a reason and they work very well in not just C++ in many other object oriented languages like C# and Java. So, using Python to justify that style of coding is a far cry from anything that is reasonable. If it work for you that's fine, but I don't think it's a good idea generally.

They are same languages. Java style access modifiers don't exist in Smalltalk.

Re: C++ Patterns: The Badge

#132

Post by lenkite »

nly wrote: post #38

Personally I'd move the register_device() and unregister_device() functions outside of the VFS class entirely, perhaps to namespace scope. Alternatively, there are other ways to leverage friendship and access control in C++. Here's one option: template class DeviceManager; class Device { template friend class DeviceManager; int y; }; class VFS { friend struct DeviceManager ; int x; }; template struct DeviceManager {…

Love this. I also felt that having an explicit `register` on a mediator like `DeviceManager` made much more sense for SOC, but this is really elegant. Maybe you should write and publish some C++ Idioms :)

Re: C++ Patterns: The Badge

#133

Post by nurettin »

geezerjay wrote: post #88
oAlbe wrote: post #84

Earlier quoted context omitted.

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.

This is the often case where some HN downvotes you to heck and the next hour bunch shoots you up to the moon. There is pretty much no predictability and it all depends on whether your responder makes a good case.

Re: C++ Patterns: The Badge

#134

Post by akling »

mirsadm wrote: post #128
akling wrote: post #127

Earlier quoted context omitted.

This style of development obviously will not scale to large, long-term C++ projects with many developers, as anyone who has worked on such projects knows all too well. No disrespect to you, QuadrupleA, do whatever makes you the most productive, but I wouldn't want to work together with you in this way :)

I hear this argument a lot, why would it not scale?

Code/API scalability:

Over a long enough time, every API will be called in every possible way. If an API misbehaves, some code somewhere will begin to rely on the specific kind of misbehavior. This is just the reality of publishing API's, so you deal with it and fix bugs as they are discovered.

If you make your entire class definition public in a large project, you will eventually have code poking at the internals of your class. I've seen this countless times, it's some kind of inevitable natural thing.

Developer scalability:

You know everything about how your code works, but I don't. A well-defined API with clear access rules gives me a fair chance to avoid using your class in ways you didn't intend.

In small-enough teams, or with small-enough projects, it's possible for everyone to understand (mostly) everything, but there's some magic number of concurrent developers where that privilege ends.

Re: C++ Patterns: The Badge

#135

Post by vnorilo »

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.

Because Badge is a template, this will produce a linker error (duplicate symbols).

Of course you can get around if you really, really want to. But I think this subthread is starting to split hairs.

Re: C++ Patterns: The Badge

#136

Post by vnorilo »

desdiv wrote: post #75
inetknght wrote: post #65

Earlier quoted context omitted.

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

Is it possible to have a proper compile time ACL for C++? Arguably the Badge pattern as presented in the article is just an honor system that provides zero security, since it's trivial to forge a fake Badge: https://repl.it/repls/BountifulQuerulousCron

It's less trivial if you make the copy/move constructors private.

https://repl.it/repls/HatefulMadeupMicrostation

Of course, type systems are orthogonal to any real security, at least in most languages, and certainly all languages with no-holds-barred interface to machine code.

Re: C++ Patterns: The Badge

#137

Post by AstralStorm »

This is essentially a capability system enforced by the compiler, which means your code is not actually in control for any third party caller.

A glaring security hole. Any old hacker can forge or clone a data structure. This "badge" (AKA token) has to be explicitly unpredictably replay-proof generated and hard to forge, and also automatically verified.

Re: C++ Patterns: The Badge

#138

Post by mkettn »

whats the advantage over declaring register_device as a functor object from an anon class? for example:

  class Device;
  class VFS {
  public:
   class {
   friend Device;
   void operator()(int y) {/* do stuff with y here*/}}     register_device;
  };
  class Device {
  public:
   void foo(VFS fs) {
    fs.register_device(1);
   }
  };
  
  int main(int argc, char *argv[]) {
  // fails:
  // VFS().register_device(2);
  // works:
   Device().foo(VFS());
   return 0;
  }
and no need for a badge class (erm... well but an anon class).

my c++ skills are a bit rusty, because most of the time python works just fine.

Re: C++ Patterns: The Badge

#139

Post by akling »

mkettn wrote: post #138

whats the advantage over declaring register_device as a functor object from an anon class? for example: class Device; class VFS { public: class { friend Device; void operator()(int y) {/* do stuff with y here*/}} register_device; }; class Device { public: void foo(VFS fs) { fs.register_device(1); } }; int main(int argc, char *argv[]) { // fails: // VFS().register_device(2); // works: Device().foo(VFS()); return 0; }…

Hmm, IMO Badge has two main advantages over your approach:

1. Aesthetics. (This is down to personal taste of course, but I much prefer how Badge gets the job done without needing multiple lines of code at every declaration.)

2. What if I need to put the function implementation out-of-line?

Re: C++ Patterns: The Badge

#140

Post by gjm11 »

geezerjay wrote: post #90
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…

> you're the epitome of the main source of C++'s problems

This seems unnecessarily personal. See https://news.ycombinator.com/newsguidelines.html for the, um, best practices around these parts, which you are not following here.

Post reply on HN