27 comments

[ 4.0 ms ] story [ 75.4 ms ] thread
Essential!

"If new true friend not protected for explicit private union, break case and try using this."

I often write

  if (not ... 
for emphasis. The "bitand" etc. are similarly useful where the operator might otherwise be mistaken for "&&" or, particularly, "||".

The only one that is an unfortunate choice is "compl", which just looks strange. When I feel a need to call attention to use of "~", I define a lambda "bitwise_not(bool)". But rarely.

(comment deleted)
I often use "not", "and", "or" to clearly express logical conditions. Bit operations look better as cryptic symbols "&", "|" and "~". :)
I do this too, as I find it a bit more readable. Also, I find it handy to reserve '&&' exclusively for rvalue references.
Same. `a and b or c` reads nicer than `a && b || c` to me.

And I find its harder to typo and misread it:

`a && b || c` vs `a & b | c`

`a and b or c` vs `a & b | c`

A valid opinion for language design, but when writing real C++ code, I'd stick to the usual way of doing things.

English language keywords aren't always great for readability in my opinion. Ada's and then / or else syntax, for instance. They're the short-circuit syntax, whereas and and or give eager evaluation. [0] You can't determine that just from the syntax though, so it ends up being no less cryptic than using strange symbols the way C++ (typically) does.

[0] https://en.wikibooks.org/wiki/Ada_Programming/Operators#Shor...

What is the purpose of this? Does anybody find these more readable?
> What is the purpose of this?

Its explained in the first two sentences of the page.

It's like Van Halen and the brown M&Ms thing. It determines if the author of a C++ lexer, syntax highlighter, etc., read the Standard. Try splitting a digraph with \ and a newline.
I like the use of "not" because it stands out more clearly than "!". "if (not (x and y))" seems more readable to me than "if (! (x && y))".
I agree, “!” is something easy to miss. I prefer “!=“ mostly for this reason.

I am just surprised I’ve never seen this in any code base before.

In Perl, the english operators for and/or/etc have lower precedence than the symbolic ones.
Back in 2009 or so, I and a few others ran a Google-internal April Fool's prank based on this.

We auto-generated a humongous pull request for the Chromium source code and sent it out for review by all the various source code "owners" (super reviewers) who would need to sign off.

The change used the alternate encoding for curly and square brackets, claiming the original characters were inaccessible on an Icelandic keyboard layout (which is half true, and there were quite a few of us Icelanders around) and that therefore, to be inclusive, we would like to standardize on the alternative representation.

Good fun, although I don't remember if a single one of the reviewers was fooled :)

This blew my mind. Mostly because I haven't come across this during 8 years of c++ use for professional/competitive programming.
I've never seen anyone use these since they appeared in the spec decades ago. They're as pointless as trigraphs, which I've never seen in the wild either.
Ever seen a real use of `operator"" _X`, the C++11 feature that lets you declare a literal constant like this?

  int operator"" _km(unsigned long long);
  auto distance = 42_km;
The breadth of crazy features in C++ is really huge, when you dig in.
The equivalent thing in D is, but without a special feature:

    template _km(ulong v) { enum _km = inKilometers(v); }
    auto distance = _km!42;
It's used by the Sargon library to create a halffloat type:

https://digitalmars.com/sargon/halffloat.html

I haven't seen it used in C++, though my C++ experience post this feature is limited.

All the time,

    "A safer string"s
Declares a std::string constant.

While I agree C++ is huge, I doubt anyone would survive a Python, Java, C#, VB.NET, JavaScript, Typescript, Fortran, Ada, Common Lisp, COBOL, C pub quiz, based on the very latest language versions.

One thing is, for the longest time MSVC did not support them (against the spec like always) so they could not be used if you wanted cross-platform code.