Obscure C++ Features

http://madebyevan.com/obscure-cpp-features/

by burke_holland • 13 years ago

126 53 13 years ago

madebyevan.com

wereHamster2• 13 years ago

Dark font on dark background. Unreadable.

alexchamberlain2• 13 years ago

There are some advantages to the company firewall blocking style sheets.

laumars• 13 years ago

Sorry, I know I'm drifting massively off topic now, but why on earth would any company adopt such a policy? It's not even as if CSS files can carry executable code (sure, they can reference such content, but then block that stuff instead of the style sheets themselves).

papsosouid3• 13 years ago

Don't the mainstream browsers support custom styling yet? Like say, a high contrast style?

ycombobreaker2• 13 years ago

In Opera, "Page > Style > User Mode" does the trick. I know FF and IE have similar functionality, but I don't know the shortcut.

Luyt• 13 years ago

Indeed. In Firefox I do View -> Page Style -> No Style.

Alas, this site is not an exception. Many websites sacrifice readability to some graphic designers' whim.

alexchamberlain2• 13 years ago

Are these really obscure? I've used most of them.

vinkelhake• 13 years ago

I was going to say the same thing. I guess I've been doing C++ for too long to consider these obscure. Any nontrivial C++ codebase is likely to have several of these.

nawitus2• 13 years ago

Obscureness is subjective. In my opinion this article would be worse if 50% of the least obscure features were not presented.

scott_s• 13 years ago

That's what I thought, but then that last one... I had no idea.

wereHamster2• 13 years ago

"Alternate operator tokens" - there are more tokens you can use instead of []{} etc. See http://en.wikipedia.org/wiki/Digraphs_and_trigraphs

rhapsodyv• 13 years ago

Here: http://www.cppgm.org I'm learning a lot of this features!

olliej• 13 years ago

The behavior of [] is from C -- it's not a bizarro C++ feature.

The "redefining keywords" is the pre-processor. That's what it does. There isn't anything magic here. Strictly speaking it can be run entirely ahead of the C/C++ compiler, on any file you want. There's no requirement that it is C/C++ - you could use it on a python script (as long as you weren't using # comments anywhere :D )

dljsjr• 13 years ago

Definitions of obscure:

1. Not easily distinguished

2. Not readily understandable/expressable

3. Not commonly known

I didn't see the author use the word "bizarro" anywhere, nor make any claims about any of this stuff being weird. He actually presented almost everything in a fairly neutral tone, except when he said that using the preprocessor to override keywords was dangerous (which could be construed as opinion).

bcoates• 13 years ago

It's not an opinion, it's forbidden by the language specification so it's not portable.

pubby• 13 years ago

There is somewhat of a requirement with the preprocessor - if you redefine a keyword and then include a standard library header it's considered undefined behavior. Maybe that's what the author meant.

nawitus2• 13 years ago

>The behavior of [] is from C -- it's not a bizarro C++ feature.

I'd say that a feature of C++ is still a feature of C++ even if the same feature is in C.

_pmf_• 13 years ago

The point was probably that it is not obscure; it's what you had to learn when using plain C in the first week.

qb45• 13 years ago

Moreover, 3[a] appears to be supported solely for backwards compatibility with C since it works only for pointers - you can't do this with classes which define operator[](int).

ori_b• 13 years ago

That's because operator overloading in C++ isn't commutative in general. For integers, 'a + b' is the same as 'b + a', but it's not the same in C++.

For example, I could do:

    class MyClass {int operator+(int a) { return a; }};

    MyClass x;
    x + 1;  // Valid.
    1 + x;  // Type error.

EDIT: My mistake. C++ requires these operators to be nonstatic member functions:

     = -> [] ()

Which, annoyingly enough, means that you can define '+' over types that you haven't implemented, but you can't define [] or =.

hamidr• 13 years ago

Obscure? You may think so but sometimes these things buy you lots of time.

gensym• 13 years ago

Yes. Time in a rubber room.

usefulcat• 13 years ago

Re. the "redefining keywords" trick. I know this works with at least some versions of g++. However when I tried doing it in MSVC 2008 I ended up with link errors between the library object files (compiled without the redefinition trick) and the app executable that did use the trick. It looked like MSVC was encoding the visibility in the mangled method names.

klodolph• 13 years ago

If I remember correctly, it's undefined behavior if you redefine keywords anywhere, not just for library headers as the article suggests.

atesti• 13 years ago

The first review I read about the StarOffice source code (now OpenOffice, LibreOffice) back then when it was open sourced was that it was full of #define private public lines

bnegreve2• 13 years ago

C++ contains a syntactical shorthand for simultaneously declaring a variable and branching on its value.

    if (MouseEvent *mouse = dynamic_cast<MouseEvent *>(event))

I think it is a complicated description and a complicated example for saying that the assignment operator (=) returns the value that was assigned.

minasss• 13 years ago

for example int a = b = c = 0;

danbruc• 13 years ago

It is more like int a = int b = int c = 0;

ben0x5392• 13 years ago

The noteworthy bit is that declarations are valid in the conditional "expression" of if-statements and evaluate to the declared variable. It's imo not obvious that declarations are expressions sometimes.

Sharlin2• 13 years ago

To be precise, declarations are never expressions - there are two forms of if and while statements in the grammar, one taking an expression and the other a declaration.

jomar• 13 years ago

If this were just

    if (mouse = dynamic_cast<MouseEvent *>(event))

then it would indeed just be an if condition expression that happened to be an assignment.

But the variable is being declared as well, so what's actually going on here is a declaration and an initialiser expression. There is actually new functionality here that needed a bit of language design thought, e.g., the declared variable's scope is the whole if statement, not just the condition expression.

kelnos• 13 years ago

I see this as no different than being able to do

    for (int i = 0; i < len; ++i) { }

Ives• 13 years ago

There are some problems with that method though.

If, for example, you'd like to reverse the condition, you can't write

    if (!(MouseEvent *mouse = dynamic_cast<MouseEvent *>(event)))
    {}

because a definition is not a general expression, but was only added as an "extra" to allow its use in some cases in conditionals.

bnegreve2• 13 years ago

Oh, ok I didn't know. So it is indeed a syntactical shorthand for simultaneously declaring a variable and branching.

Sharlin2• 13 years ago

The '=' above is not an assignment operator, as there is no assigment, it is a declaration. Yes, the following is also valid:

    MouseEvent *mouse;
    if(mouse = dynamic_cast<MouseEvent *>(event)))

but it is not the same thing.

ben0x5392• 13 years ago

My favorite is that these are indeed "alternate operator tokens" an so you can use `compl` in place of ~ to name a destructor. Like, for explicit destruction:

    MyType* foo = ...;
    foo->compl MyType();

duskwuff• 13 years ago

If there is ever an IOC++CC (International Obfuscated C++ Code Contest), I imagine that this technique will show up all over the place.

Bonus: Can you paste together the "compl" token with preprocessor macros?

asveikau• 13 years ago

I think the only thing "obscure" in this list is the "pointer-to-member" syntax. It's conceptually simple but the syntax is pretty bizarre, hard to remember even when you're searching for it, and probably a lot of C++ programmers working professionally will not recognize it.

I remember a few years ago I was writing some code where using pointer-to-struct-member made lots of sense to me. Doing a code review I was asked politely by a peer to rewrite without them. I disagreed but didn't mind doing so, if it made people on the team happier about readability.

coolwanglu• 13 years ago

Oh I just love C++ better!

pasquinelli• 13 years ago

i didn't find any of these things obscure. that tells me that the road to recovery for ex-c++ programmers is a long one. one day at a time.

PySlice• 13 years ago

Perl eats C++'s "most vexing parse" for breakfast.

kyberias• 13 years ago

Dark gray text on black background. Really?

erlkonig• 13 years ago

Although the article's interesting (hardly new info, but concisely described), the ghetto antialiasing, - or whatever excuse the CSS-writer had in mind for gray-on-gray text - really hurts legibility. Seriously, high contrast is the answer - look at 95%+ of all books (white on black is high contrast but costs a lot more in ink, so books only typically have white on black).

Back to the content, C++ syntax has always been a bit nasty, and the try/catch for constructor initializers adds yet another wart. It makes me miss LISP again.

Obscure C++ Features

Related Stories