[HN Gopher] C++ Alternative Operator Representations
       ___________________________________________________________________
        
       C++ Alternative Operator Representations
        
       Author : signa11
       Score  : 40 points
       Date   : 2021-04-23 08:53 UTC (14 hours ago)
        
 (HTM) web link (en.cppreference.com)
 (TXT) w3m dump (en.cppreference.com)
        
       | TobyBrull wrote:
       | Please don't!
        
       | tirrex wrote:
       | What is the purpose of this? Does anybody find these more
       | readable?
        
         | WalterBright wrote:
         | 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.
        
         | detaro wrote:
         | > _What is the purpose of this?_
         | 
         | Its explained in the first two sentences of the page.
        
       | signa11 wrote:
       | to see what is possible, take a look at this:
       | https://coliru.stacked-crooked.com/view?id=4f9c171eb25285dc
        
         | tasty_freeze wrote:
         | That is exactly the example in the linked article.
        
       | [deleted]
        
       | joisig wrote:
       | 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 :)
        
       | nikhilsimha wrote:
       | This blew my mind. Mostly because I haven't come across this
       | during 8 years of c++ use for professional/competitive
       | programming.
        
         | WalterBright wrote:
         | 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.
        
           | jeffbee wrote:
           | 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.
        
             | WalterBright wrote:
             | 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.
        
       | wmu wrote:
       | I often use "not", "and", "or" to clearly express logical
       | conditions. Bit operations look better as cryptic symbols "&",
       | "|" and "~". :)
        
         | MaxBarraclough wrote:
         | 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...
        
         | usefulcat wrote:
         | I do this too, as I find it a bit more readable. Also, I find
         | it handy to reserve '&&' exclusively for rvalue references.
        
         | bombela wrote:
         | 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`
        
       | tyingq wrote:
       | In Perl, the english operators for and/or/etc have lower
       | precedence than the symbolic ones.
        
       | ncmncm wrote:
       | 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.
        
         | WalterBright wrote:
         | I prefer:                   if not nowhow not noway
         | ...
        
         | thestoicattack wrote:
         | You could also use std::bit_not
         | 
         | https://en.cppreference.com/w/cpp/utility/functional/bit_not
        
           | Koshkin wrote:
           | You could, but the raison d'etre of these operators-as-types
           | is their usefulness in metaprogramming.
        
       ___________________________________________________________________
       (page generated 2021-04-23 23:01 UTC)