Esoteric C++ Contest 2018 | Hacker News Reader

Esoteric C++ Contest 2018

zygoloid.github.io

98 pointslelf40 comments

It looks like nobody managed to beat this one from 2015 yet:

http://b.atch.se/posts/non-constant-constant-expressions/

"Implementing f() to make the following snippet compile without the static_assert being fired looks impossible, doesn't it?

   // <insert solution here>
   int main () {
     constexpr int a = f();
     constexpr int b = f();
     static_assert (a != b, "fail");
   }

We all "know" that an expression that is usable in a constant-expression can neither depend on, nor change, the global state. This lack of dependency must inherently mean that it will yield the same value upon each invocation having the same set of arguments... right?

Up until about a week ago I "knew" this to be true, and I honestly thought the above was not possible to implement without triggering undefined-behavior (ie. writing a program that the ISO C++ Standard would consider ill-formed).

As it turns out, I was very wrong."

Some of these are hilarious. I'm always astounded how easy it is to shoot yourself in the foot with C++.

It's such a important, transformative and widely used language, but due to the age and the "let's put everything in without ever removing anything because backwards compatability!" mentality has created a monster.

Oh, they remove stuff. See "Deprecating Vestigial Library Parts in C++17" [1].

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p017...

To be fair, how many languages are as old and as widely used as C++?(Only one: C)

Anybody can create a some shiny new language or maintain a beautiful unused language.

Common Lisp :)

Fortran. Ok, maybe not as widely used :)

COBOL

It's not just the number of things, but the way they combine, as in the rules for argument-dependent lookup (not to be mistaken for unqualified name lookup or template type deduction.) When you have pointers and two or arguably three types of references, and arrays that decay to pointers in some cases, there's a lot of different cases to be considered. It's quite an achievement that it often works the way you want.

https://en.cppreference.com/w/cpp/language/adl

> Esoteric C++ Contest 2018

http://ericniebler.com/2018/12/05/standard-ranges/

I think this fits the definition of esoteric more than anything that was submitted.

I've read the criticism of that post ( http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/ , discussed previously at https://news.ycombinator.com/item?id=18777735 ) but not the original, and now that I did, I have that strange feeling of not knowing whether it was satire or not --- and am unfortunately leaning towards the latter.

I made another comment here on this item, that it feels like a lot of the recent developments in programming languages are more along the lines of showing off how much complexity you can add, rather than solving the real problem itself. It's a "do less with more" mindset, the complete opposite of what I believe in.

Somewhat off-topic, but how do you publicize your competitions better?

The author promised an iPad for the winner and got 40 entries.

What fraction of the money set aside for a competition should be spent on publicity and how much on the prize? Talking about programming/related competitions here.

Within C++, there is a much smaller and cleaner language struggling to get out. Stroustrup, Bjarne. The Design and Evolution of C++. pp. 207..

That wouldn’t be so bad. The problem is that it’s five or six smaller and cleaner languages all struggling to get out.

Yeah I agree that nobody could agree on a single subset of C++.

I think that Bjarne might mean "modern C++", but I'm more a fan of "C with classes", and I think the latter is more appropriate for many domains. I would say those are the two main dialects (with modern C++ being split being library writers using templates and library consumers.)

The old Google C++ style guide is good, but it seems to be morphing more into modern C++ lately. It's basically C with:

- The ability to add methods to structs

- Basic single inheritance.

- Collection and string classes

- Scope based resource management.

https://stackoverflow.com/questions/3073642/official-c-langu...

No exceptions, no IO streams (except in one place), no implicit constructors, no operator overloading, multiple inheritance, etc.

So I woudn't say there are 5 or 6 languages, but it definitely feels like that sometimes. I think the lack of a single string type, single error handling mechanism, and single deallocation mechanism are the things that make it feel like more than one language in a single codebase.

with the exception of scope-based resourcing, that basically describes Go.

Yes I've heard people remark that Go is basically Google's C++ style guide distilled into a new programming language... It's not 100% true but there's definitely some truth to it :)

Not having exceptions is a big similarity. Go slices and StringPiece are essentially the same idiom. There's a lot of vector<> and map<> which leads to builtin arrays and maps, rather than having arbitrary user-defined data structures (i.e. no operator overloading). gofmt was definitely inspired by Google's code review process.

I agree, I'm definitely not a fan of the "Let's replace a simple and straightforward way with something that looks simpler at first but actually invokes a bunch of hidden complexity that's harder to debug and generates 10x more inefficient code. Why? Because that's the more 'modern' way." type of thinking I've seen from a lot of the "modern C++" advocates. They seem to be more interested in solving hypothetical or artificial problems that they themselves created, than the actual problem which needs to be solved.

Template libraries work well, until they don't, at which point you get many pages of confusing error messages containing absurdly long identifier names; and the cause is often something as simple as one missing, wrong, or extra character. Sometimes it even crashes the compiler...

Try raja, or any pile of templated mess. I hate templates so much.

I googled RAJA and found it was a HPC (High performance computing) library for running GPU code in C++. This couldn't be that bad, right? Turns out I was terribly wrong.

Behold, I present you this fucking monstrosity (Directly from the RAJA matrix multiplication tutorial):

  using EXEC_POL9 =
    RAJA::KernelPolicy<
      RAJA::statement::CudaKernel<
        RAJA::statement::Tile<1, RAJA::statement::tile_fixed<CUDA_BLOCK_SIZE>, RAJA::cuda_block_y_loop,
          RAJA::statement::Tile<0, RAJA::statement::tile_fixed<CUDA_BLOCK_SIZE>, RAJA::cuda_block_x_loop,
            RAJA::statement::For<1, RAJA::cuda_thread_y_loop, // row
              RAJA::statement::For<0, RAJA::cuda_thread_x_loop, // col
                RAJA::statement::Lambda<0>,   // dot = 0.0
                RAJA::statement::For<2, RAJA::seq_exec,
                    RAJA::statement::Lambda<1> // dot += ...
                >,
                RAJA::statement::Lambda<2>   // set C = ...
              >
            >
          >
        >
      >
    >;

And that's just for matrix multiplication. I cannot imagine how fucking terrifying it will to write something more complicated than that. If I were to write (and debug) this mindfucking mess of templated code, I would rather escape this trainwreck and go back to writing CUDA/OpenCL code...

And I was dumb enough to accept an independent study to add openacc support to the library.

> Behold, I present you this fucking monstrosity

It's just a Lisp-like language with a slightly different syntax for S-expressions. Ugly, like all Lisps, but nothing 'monstrous'.

How far down the rabbit hole must one be to not think that is monstrous?

The cognitive dissonance required to believe that C++ templates are 'monstrous' while Lisp S-expressions are awesomely useful and productive is enormous.

C++ templates are far from user-friendly, but they're literally (literally) just Lisp S-expressions with a Lisp syntax and semantics.

The semantics of template resolution are important, and unlike anything I'm aware of in Lisp.

Short of writing your own DSL, how would you solve the problem the above code snippet is attempting to solve in C++?

I understand complaining about templates like the ranges example also posted in this thread, but I am curious to hear what you think is the alternative for this specific example.

Take a look at C++ AMP https://docs.microsoft.com/en-us/cpp/parallel/amp/cpp-amp-cp.... It’s smooth as melted butter.

That's .. not actually too bad. Obviously it's going to generate a lot of code, but I can almost understand what it's trying to do and it doesn't look like it relies too heavily on type resolution surprises.

If you want a template challenge, try (without looking it up) writing your own iostream class. iostream is one of those things that's present in even beginner examples but when you look at how it works a whole load of complexity unravels.

Why hate templates?

Compilation times? Obfuscation? Bloat? I like them but these are valid negatives.

Those are problem only if templates are misused (imho).

Which is pretty much anything outside of the STL library's basic usage.

Yes I agree. I would not have been so down-voted so much if I had said the use of templates in the std:: libraries and some others, not all, is fantastic. But, the use of templates to make generic code when it does not need to be leads to the same functionality as specialised classes with longer compile times and obfuscation.

I agree that putting templates where they not belong causes problems (even more than just longer compile times and obfuscation).

However, properly designed templates with enough attention put into exposing functionality beat non-templated approaches right off the bat.

Example: http://eigen.tuxfamily.org/dox/TopicInsideEigenExample.html

I think templates are fine as long as they're not abused. Unfortunately, since C++ templates are Turing complete, people will inevitably go overboard with them.

My personal rule is to never nest more than two templates. You can have a template inside a template, but anything deeper than that should be refactored or at least split up into typedefs for readability.

The answer to C++ cruft always seems to be use the "modern" subset of the language. But there are three issues with that:

1. You have to interface with older libraries that overuse terrible behavior.

2. The hallmark of a junior developer is an overuse of features. Using a subset takes discipline.

3. Some things are just permanently broken or so hidden you don't even realize you are using a "feature".

That's why I'm just going to stick with Rust. I have no interest in the "let's put a wig and lipstick on the C++ pig" train.

We really don't need a rust comment on every c++ submission.

Knowing Rust, Go and Kotlin that's what we're going to get sadly.

An atheist, a vegan, and a Rust programmer walk into a bar. I only know because they told everyone within two minutes.

P.S. I'm an atheist.

C++ is easily the next Perl:

With a cocktail of alphanumeric overloadable operators, lambdas, variadic templates and small identifiers, all badly spaced, It would not be difficult to achieve super unreadable code with it.

They just need to figure out a way to add implicit arguments like $@, $?, @_ and we'll get a more esoteric C++. Note that $_ is a valid identifier in C++.

Reply on news.ycombinator.com