Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Retiring a favourite C++ joke

ignition-training.com

Post reply on HN
Print view View original

111–120 of 151 posts

Re: Retiring a favourite C++ joke

#111

Post by tempodox »

tialaramex wrote: post #102
planede wrote: post #57

Earlier quoted context omitted.

An other one from the standard: void trex(volatile short left_arm, volatile short right_arm); // deprecated https://eel.is/c++draft/depr.volatile.type#example-3

This is one of the surviving improvements from JF Bastien's P1152 which was initially successful in deprecating most of the spurious use of volatile from C++ with a view to some day getting in there and actually doing MMIO properly. Unfortunately too much of this will be unwound in C++ 23 because WG21 voted to un-deprecate all the volatile compound operators despite knowing nobody could even offer a rationale for why…

I think [1] explains well why this will be un-deprecated.

[1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p23...

Re: Retiring a favourite C++ joke

#112

Post by [deleted] »

jb1991 wrote: post #109
kps wrote: post #106

Earlier quoted context omitted.

std::unique_ptr is reference counted, it's just that the count only goes up to BOOL_MAX instead of LONG_MAX.

I think you’re making a joke, but reference counting is different than what a unique pointer does. (a destructor is not the same thing as a reference count, even if that reference count is limited as you suggest.)

[deleted]

Re: Retiring a favourite C++ joke

#113

Post by Joker_vD »

jb1991 wrote: post #109
kps wrote: post #106

Earlier quoted context omitted.

std::unique_ptr is reference counted, it's just that the count only goes up to BOOL_MAX instead of LONG_MAX.

I think you’re making a joke, but reference counting is different than what a unique pointer does. (a destructor is not the same thing as a reference count, even if that reference count is limited as you suggest.)

No, I don't think it's a joke. It's just that when your counter is limited to values of 0 and 1 only, you can optimize it so heavily it almost looks like a different thing entirely: binary semaphores are usually called mutexes, but they're still semaphores.

Re: Retiring a favourite C++ joke

#114

Post by kps »

Joker_vD wrote: post #113
jb1991 wrote: post #109

Earlier quoted context omitted.

I think you’re making a joke, but reference counting is different than what a unique pointer does. (a destructor is not the same thing as a reference count, even if that reference count is limited as you suggest.)

No, I don't think it's a joke. It's just that when your counter is limited to values of 0 and 1 only, you can optimize it so heavily it almost looks like a different thing entirely: binary semaphores are usually called mutexes, but they're still semaphores.

It was a joke and not a joke, a joke with a kernel of truth.

But I only now just discovered that C23 is genuinely adding `BOOL_MAX`, which reminds me of the classic Fortran —

> The primary purpose of the DATA statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable PI can be given that value with a DATA statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change.

Re: Retiring a favourite C++ joke

#115

Post by jb1991 »

Joker_vD wrote: post #113
jb1991 wrote: post #109

Earlier quoted context omitted.

I think you’re making a joke, but reference counting is different than what a unique pointer does. (a destructor is not the same thing as a reference count, even if that reference count is limited as you suggest.)

No, I don't think it's a joke. It's just that when your counter is limited to values of 0 and 1 only, you can optimize it so heavily it almost looks like a different thing entirely: binary semaphores are usually called mutexes, but they're still semaphores.

But it’s not counted, that’s my point.

It’s getting quite pedantic to talk about ones and zeros in this context anyway.

Re: Retiring a favourite C++ joke

#116

Post by cozzyd »

ddulaney wrote: post #86
klodolph wrote: post #35

Earlier quoted context omitted.

The old MPW compiler had some gems: https://www.cs.cmu.edu/~jasonh/personal/humor/compile.html > This label is the target of a goto from outside of the block containing this label AND this block has an automatic variable with an initializer AND your window wasn't wide enough to read this whole error message

On template expansion failures, I'd love a modern GCC reporting "your window wasn't tall enough to read this whole error message"

"this error message will take over 200 lines, would you like me to order you a coffee?"

Re: Retiring a favourite C++ joke

#117

Post by AnIdiotOnTheNet »

akhosravian wrote: post #48
sacnoradhq wrote: post #27

#include using namespace std; class BadProgrammer { public: void yep() { delete this; } }; int main() { auto x = BadProgrammer{}; x.yep(); cout g++ -Wall -Wextra -Wpedantic main.cc # compiles just fine clang++ -Wall -Wextra -Wpedantic main.cc # also compiles just fine

FWIW the behavior of delete on a pointer that isn’t either null or returned from new is undefined. So a conforming C++ compiler doesn’t have to diagnose this mistake, and similarly the compiled program doesn’t have to do anything meaningful either. For example, just ignoring the delete and printing the message is as valid a result as the more useful crash at the site of the bad operation.

That this situation is "working as intended" and there are programmers who do not see a problem with that is... well it makes me despair.

Re: Retiring a favourite C++ joke

#118

Post by kps »

ddulaney wrote: post #86
klodolph wrote: post #35

Earlier quoted context omitted.

The old MPW compiler had some gems: https://www.cs.cmu.edu/~jasonh/personal/humor/compile.html > This label is the target of a goto from outside of the block containing this label AND this block has an automatic variable with an initializer AND your window wasn't wide enough to read this whole error message

On template expansion failures, I'd love a modern GCC reporting "your window wasn't tall enough to read this whole error message"

“I have a truly marvelous proof that your code is incorrect…”

Re: Retiring a favourite C++ joke

#120

Post by tialaramex »

tempodox wrote: post #111
tialaramex wrote: post #102

Earlier quoted context omitted.

This is one of the surviving improvements from JF Bastien's P1152 which was initially successful in deprecating most of the spurious use of volatile from C++ with a view to some day getting in there and actually doing MMIO properly. Unfortunately too much of this will be unwound in C++ 23 because WG21 voted to un-deprecate all the volatile compound operators despite knowing nobody could even offer a rationale for why…

I think [1] explains well why this will be un-deprecated. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p23...

Note that P2327 is not what was actually done.

P2327 would be in my "not angry just disappointed" category. Of course WG21 think rotten archaic C code should be valid C++ 23 and the belief from embedded devs who write this stuff that it's probably all fine despite no evidence whatsoever should be enough to sail through committee.

WG21 voted to amend the draft to un-deprecate all of the volatile compound assignments instead, at Kona IIRC.

Post reply on HN