Hacker News Reader

Comment by revivalizer | Hacker News Reader

This is a really well written article that explains the concepts straightforwardly. I had never bothered to understand this before.

... because I gave up on C++ in 2011, after reading Scott Meyers excellent Effective C++. It made me realize I had no desire to use a language that made it so difficult to use it correctly.

View on HN

I had exactly the same reaction to Effective C++, and I'd learned it back in the 90's (my first compiler didn't even support templates!). It's a wonderful book for sure, but it's a wonderfully detailed map to a minefield. The existence of guidelines like the "Rule of 7" should be raising questions as to why such a rule needs to exist in the first place.

As for this article, it really did de-mystify those strange foo&& things for me. I had no idea that they're functionally identical to references and that what C++ does with them is left up to convention. But I still felt like I had to fight against sanity loss from a horrid realization.

I don't get what's bad about rule 7. And I haven't really programmed in C++ for a decade. When you are calling derived object through a base class pointer you have a choice if you want to call the function of the base class or the function of the derived class. If you don't make it virtual it's called by pointer type, if you do, it's called by pointee type. Same goes for the destructors with only difference being that in case of virtual destructor the deatructor of a base class will be called automatically after the destructor of the derived class. So basically if you want to override methods or the destructor make your functions virtual, including the destructor.

Does it lead to problems? Surely. Should all metods be virtual by default? Probably. Should there be some keyword that indicates in derived class that a method intentionally shadows a non virtual method from the base class? Yes.

It's not a great human oriented design but it's consistent.

Apologies, I was referring to a "Rule of 7", but I more or less hallucinated it, since I'd heard the old "rule of 3" then "rule of 5" had been revised again, and thought they were maybe going with prime numbers?

https://en.cppreference.com/w/cpp/language/rule_of_three.htm...

The confusion kind of speaks for itself. The language is a construction set where the primary building block is razor blades.

It's important to notice that you can keep well out of trouble by sticking to the rule of _zero_, i.e. relying on the defaults for copy&move ctors, assignment operators and destructor.

So, the best advice is: Don't mess with the razor blades. And these days, C++ gives you enough in the standard library to avoid messing with them yourself. But since this is C++, you _can_ always open up the safety casing and messing with things, if you really want to.

I'll admit, the Rule of Zero is the kind of thing I've been wanting all along, but so much code out there seems obsessed with micro-managing its pointer and reference semantics, and one still learns of their mistakes through segmentation faults and linker errors, at least in those codebases.

Also, an artist friend tells me you can make some pretty keen sculpture with razor blades and a spot welder. Still recommended to use pliers and gloves tho.

Ten years ago I gave a C++ conference talk titled "The Rule of Seven (Plus or Minus Two)" — a reference to the "magic number seven" meme

https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus...

and alluding to the fact that besides the well-established "Rule of 5" (copy construction and assignment, move construction and assignment, and destruction) a C++ class author also needs to at least think about whether to provide: default constructor, ADL swap, equality comparison operator, and/or specialized std::hash. And maybe a few more I'm forgetting right now.

In hindsight (without rewatching it right now) I remember my thesis in that talk as erring too much on the side of "isn't this confusing? how exciting! be worried about the state of things!" These days I'd try harder to convey "it's not really that hard; yes there are a lot of customization knobs, but boring rules of thumb generally suffice; newbies shouldn't actually lose sleep over this stuff; just remember these simple guidelines."

I remeber that while learning Rust and writing fairly complex programs I had so many times when compiler was in my way, but once I finally figured out how to satisfy it, I saw that if I was writing in C++ I would just shoot myself in the foot in subtle hard to debug ways if I did what I tried to do and C++ compiler would happily let me.

I retired from wanting to write C++ when Scott Meyers retired from writing more Effective Modern C++.

scott could not have picked a better time to retire tbh. dude really sold the top.

I like working in C++ (I don't do it professionally though) and I just never bother to read up on all the weird semantic stuff. I think the more you look into C++ the more irrational it seems but I generally just program in it like it's any other language and it's fine. It's actually even somewhat enjoyable.

Reply on news.ycombinator.com