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

121–130 of 160 posts

Re: C++ Patterns: The Badge

#121

Post by edflsafoiewq »

enriquto wrote: post #89
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,…

> OOP also; I've seen so many crazy class architectures that could just be a handful of plain-old-functions, also, tons of "generic" numerical code with templates everywhere, where the only two possible instantiations are "float" and "double". Some people do really like to add useless complexity everywhere.

What's wrong with that? It seems like the easiest way to write code that works with either floats or doubles.

Re: C++ Patterns: The Badge

#122

Post by w0utert »

akling wrote: post #91

Hello friends! Author here, nice to see so much discussion :) I've spent most of my adult life working on large C++ codebases with public API's (most notably Qt and WebKit), which has led me to cultivate a defensive programming mindset. Someone mentioned Hyrum's law, which is 100% accurate in my experience. I should be honest and admit that Badge is not yet diligently applied everywhere in the Serenity codebase. I wa…

I like this idea, except for the fact that the extra parametrer pollutes the method signature and method calls, for something that really should only be a compile-time directive.

I'm actually curious why something like this has never been included as a language feature, it seems trivial to come up with a syntax for fine-grained access control, that is fully backwards-compatible and a true zero-cost abstraction.

Most obvious first shot:

  class A
  {
    private:
      void badgedFunction() const friend Device, SomeOtherClass;
  };
Did you ever check with the C++ working group if there are any proposals for language extensions for this purpose?

Re: C++ Patterns: The Badge

#123

Post by [deleted] »

enriquto wrote: post #89
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,…

> OOP also; I've seen so many crazy class architectures that could just be a handful of plain-old-functions, also, tons of "generic" numerical code with templates everywhere, where the only two possible instantiations are "float" and "double". Some people do really like to add useless complexity everywhere.

[deleted]

Re: C++ Patterns: The Badge

#124

Post by QuadrupleA »

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

> Python has a well-established convention of _underscore for intended-to-be-private members, with no enforcement, and it works fine. Python does not have access modifiers. C++ does. It makes absolutely no sense to write Python code in C++ while entirely oblivious to basic, age-old C++ features just because your background lies somewhere else and you failed or refused to learn even the basics. And you know what actua…

You keep accusing me of "failing to understand" or "refusing to learn" the "best practices" of using access specifiers.

I understand them well, and I've experimented with their use in my own projects, and decided they're a minor complexity I don't need to bother with. And that decision has served me well.

Dogmatic adherence to "best practices" is silly, even when people can agree on what they are. Learn them, yes, evaluate them carefully, but ultimately choose what works best for your constraints. Including what your team's conventions are.

The programmers I've seen taking most about "best practices" generally don't think very critically about their approaches and go with dogmatic answers, often tying up their codebases in ridiculous complexity. E.g. the "best practice" now to make a website is a React.js SPA, and now every site out there takes 20 seconds to load with 10 little spinner icons while all the HTTP requests go out to their microservices on docker clusters, and everything requires a hundred-library-deep build stack.

Re: C++ Patterns: The Badge

#125

Post by zvrba »

QuadrupleA wrote: post #102
zvrba wrote: post #99

Earlier quoted context omitted.

> but a few years ago I started doing everything all-public This is a recipe for disaster as soon as inheritance is in the picture.

Everything is a recipe for disaster one inheritance is in the picture :)

That's a blind, dogmatic position. Inheritance is a tool, as everything else.

Re: C++ Patterns: The Badge

#126

Post by akling »

w0utert wrote: post #122
akling wrote: post #91

Hello friends! Author here, nice to see so much discussion :) I've spent most of my adult life working on large C++ codebases with public API's (most notably Qt and WebKit), which has led me to cultivate a defensive programming mindset. Someone mentioned Hyrum's law, which is 100% accurate in my experience. I should be honest and admit that Badge is not yet diligently applied everywhere in the Serenity codebase. I wa…

I like this idea, except for the fact that the extra parametrer pollutes the method signature and method calls, for something that really should only be a compile-time directive. I'm actually curious why something like this has never been included as a language feature, it seems trivial to come up with a syntax for fine-grained access control, that is fully backwards-compatible and a true zero-cost abstraction. Most…

Yeah, polluting the signatures is a shame.

I've only just decided that I enjoy using this pattern so my internal standards committee hadn't progressed to the proposal stage yet. :)

Your syntax makes perfect sense to me, and I think it would make a great addition to the language. I wonder what the real working group would say. (I tried quickly googling for something that might sound like an existing proposal but came up empty.)

Re: C++ Patterns: The Badge

#127

Post by akling »

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

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 :)

Re: C++ Patterns: The Badge

#128

Post by mirsadm »

akling wrote: post #127
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,…

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?

Re: C++ Patterns: The Badge

#129

Post by mirsadm »

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…

Equally being too defensive and over-complicating code in case a "bad" developer makes a breaking change often leads to code that is worse in the long term.

Re: C++ Patterns: The Badge

#130

Post by QuadrupleA »

akling wrote: post #127
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,…

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 :)

It's more of a C style I guess, that I prefer, or a very selective use of C++. Certainly C has supported some big projects.

Anyway language rants aside, your project looks very cool - I remember seeing it posted here a while back.

Post reply on HN