Obscure C++ Features | Hacker News Reader

Obscure C++ Features

madebyevan.com

17 pointsadgasf19 comments

Made even more obscure by using dark grey on black.

I didn't know you could overload the comma operator that way. The comma operator was for use in C macros, for when multiple expressions were necessary. It should have been deprecated in C++.

The comma operator has different precedence inside and outside square brackets.

   tab(1,2)

is a function call with two arguments.

   tab[1,2]

is an invocation of the comma operator. You can't overload "operator[]" with multiple arguments and simulate multidimensional arrays.

Placement new isn't obscure or strange, it's in all those red books.

You may not use it, but you can appreciate it's very useful if you want that fine grained control that you're using c++ for in the first place.

Most of the other examples are just pure weirdness that you should never use. The kind you find in online employment exams.

Meh. Some of these are no longer problematic in recent versions of the language. Braced initialization obviates the most vexing parse, for example.

That is true, but there is still some ambiguity with initializer lists[1]

[1] http://scottmeyers.blogspot.com/2016/11/help-me-sort-out-mea...

Discussion on hackernews about that blog post by Scott Meyers: https://news.ycombinator.com/item?id=13014429

Some decent discussions there, I missed them before, thanks for pointing them out.

Overall I disagree with some of the commenters who take one look at {{}} and cue the syntax bashing. I've found that many of the new syntactic conveniences in the language have brought a net positive to expressiveness and elegance.

Don't get me wrong. I agree that the new syntactic conveniences have improved the overall developer experience of using C++. I know how difficult it is to improve things in C++ while still maintaining backward compatibility with the huge history it has. C++11/14 was a step in the right direction and i'm looking forward to what will come with the new, more rapid release cycles they are trying to adopt.

These are features covered in every C++ book and if you don't know them you can hardly call yourself a C++ programmer.

Furthermore, the first 'C++ feature' is not even a feature. It is merely the result of the preprocessor translating a[b] to *(a+b). C has it too.

Idk, I knew most of these, but the alternate operator tokens, ref-qualifiers, comma operator overloading, and function try-blocks were all new to me. What book do you know that covers those?

Am I the only one that just cringed reading the keyword replacement section? To me the example given seemed absolutely crazy. Can anyone validate this usage of the "feature"? It just seems so off.

It's kinda useful for testing private functions and accessing private variables during testing. However using something like the `GOOGLE_FRIEND_TEST` marcro in Google Test is probably a better way to get around private functions/members.

Wouldn't testing the public interface that calls the private code, be enough in most situations? If they are few and simple I test them indirectly by testing the public interface that makes use of them, otherwise they can factored out to a new class/module where they can be tested directly.

I can't think of situations where i'd ever resort to doing this (But then, maybe I haven't been using C++ long enough to come across this in a codebase that I work with). I just think that doing this can break things and make it _really_ difficult to debug.

Of course, the example given is insane, like most example of obscure features that should never be used in real code.

It works though, "works" as in "it will compile".

> Can anyone validate this usage of the "feature"?

It's considered bad practice, yep. I would absolutely reject any code review that abused the preprocessor like that.

The only legitimate way to use it I've seen is for "white box" testing... when you have a nontrivial amount of private helper code and you want to be able to test it. Then defining "private" to be "public" for only that test compilation cuts down on the amount of work needed with basically no risk.

That being said, I prefer refactoring out all that private data and code into utilities and such. There are other ways to get good encapsulation in C++, if that's the concern.

>Accessing an element of an array via ptr[3] is actually just short for (ptr + 3). This can be equivalently written as (3 + ptr) and therefore as 3[ptr], which turns out to be completely valid code.

C++ standard defines the syntax of a postfix expression as this

  postfix-expression:
      primary-expression
      postfix-expression[expression] 
      postfix-expression[braced-init-list]

[expression]primary-expression is not valid

Avoid using these whenever possible. Readability is more important than WoahNeat Factor.

You don't think "bitand" is more readable than &?

Only if I haven't programmed in any other language before.

More eadable as in "I can read english"? Yes.

More readable as in "I want to read code fast"? No.

I much prefer C style languages over Pascal style languages.

Reply on news.ycombinator.com