C++ Insights – See your source code with the eyes of a Compiler

126 points by rramadass a day ago on hackernews | 25 comments

[OP] rramadass | a day ago

The tool can be found at - https://cppinsights.io/

StilesCrisis | 7 hours ago

I wish the readme example showed a lambda capture. Now that's where compiler magic REALLY shows up.

mrlonglong | 6 hours ago

I second this.

[OP] rramadass | 6 hours ago

[OP] rramadass | 6 hours ago

You can see it by typing in the sample code in the tool here - https://news.ycombinator.com/item?id=49928362

sltkr | an hour ago

C++ lambdas are just structs that overload operator(); once you realize that they become a lot less mysterious. But it's a great example of how this tool is useful to learn about those things (of course you could also read the C++ standard but who has time for that?)

Here's an example: https://cppinsights.io/s/f04b6896

(That also shows how C++'s range-based for-loops work, which is similarly some syntactic suger for a fairly mundane for-loop, but details are interesting: unlike a typical for-loop, the loop variable is declared inside the loop body.)

alankarmisra | 7 hours ago

Ooo I love these things. I wrote a C++ -> Clang -> JS transpiler so I could show value change states on top of the C++ source code in html and allow people to step through the whole state change. They can also vary the input and see the values change cause the JS layer could recompute the values - which is why I bothered with the transpiling - otherwise I could have just output the state changes and parsed them as CSV for the steps. Fun project!

https://youtu.be/ZPGysUX62OY

jsrcout | 5 hours ago

Definitely trying this out. I've always had the problem of "but what is the compiler thinking?" with C++ in particular.

IshKebab | 5 hours ago

This is what let me understand lambdas. Great tool.

drysine | 2 hours ago

Good for C++'s coroutines too

pjmlp | 2 hours ago

It also helps to know the .NET model, as C++20 co-routines were inspired by how they work and related magic methods on awaitable types.

f1shy | 5 hours ago

I must be the only one who (while I like the tool) feel a little strange, somewhere between sad, angry, annoyed and disappointed (can’t really express it), that a language needs (or at least is of good use) such a tool.

Like: I wish what is the first interpretation of my code to be obvious. Is not about advanced optimization, or nitty gritty compiler tricks, is about the language. This tool is useful in any C++ compiler. How did we end with such a complex language?

I mean (sorry, very personal take) the programming language is for me a tool to help me think about a problem and its solution. In this era of LLM more than before, is not a tool to get the machine to do something, is a language for formalizing ideas, problems and solutions, like math. Should not be so obscure, that you need to be a lawyer to understand it, right? Or I am very much old and totally in the weeds with my ideas?

rs545837 | 5 hours ago

I don't think it's only C++ though, Python decorators, Rust macros, almost every language's compiler write code you never see. C++ just does more of it and makes it harder to guess. Being able to look at the expanded version is useful in any language that does this.

kccqzy | 5 hours ago

No a language doesn’t need it. It’s an educational tool for those new to the language or new to a particular language feature. With practice language features just become automatic so you don’t think about them when thinking about a problem.

In the README example, the C++ practitioner just doesn’t think about those automatically synthesized copy constructors and such for POD types, nor do they think about the fact that assignment is desugared to operator= or that an assignment can involve a static_cast.

f1shy | 4 hours ago

>> needs (or at least is of good use) such a tool.

Of course there are people who do not need that tool. The thing is, other languages doesn’t need such an explanation tool at all, is very much enough with reading a small book. I personally would like C++ to not really need it, but clearly as I stated: maybe “the only one”

drysine | 2 hours ago

>other languages doesn’t need such an explanation tool at all

Are you sure about that?

kccqzy | an hour ago

> other languages doesn’t need such an explanation tool at all

Plain old C has -E to expand macros. Rust has cargo expand. Haskell has -ddump-simpl. Common Lisp has macroexpand. Any language that has a complicated syntax or allows the user to customize the syntax needs such a tool. Whether such a tool actually exists reflects more on popularity and community desire.

esikich | 5 hours ago

In what language is compiling simple? Do you not like compiled languages? I'm not sure what you're complaining about here.

f1shy | 4 hours ago

Lisp is simple to compile. Even C (at the level this tool works anyway), also basic, and maybe other 100 languages (again, not the whole compiler, but what this tool shows).

Compilation per se is not difficult. Doing it with good error recovery, good feedback in case of error, and the optimization is difficult.

This tool does not tell me those parts (for that is gotbolt) this is about how the first layer of interpretation works, and not for making compilers, but for understanding what the code actually means, because is not obvious at first sight.

dasyatidprime | 2 hours ago

I agree with an overall thrust of “C++ is overcomplicated and has many moving parts and a lot of implicit stuff happening in the background that makes it difficult to understand”. But I do want to briefly note that Lisp environments have macro expansion steppers for a reason too.

pjmlp | 2 hours ago

Classical Lisp 1.5 yeah, modern Lisps not so much, hence why there are famous publications like Lisp In Small Pieces.

Only if you mean K&R C or the early C89/90 compilers, before the extension explosion, newer language standards, and modern ISAs.

[OP] rramadass | 3 hours ago

You have misunderstood the language and the tool.

Compilers for all languages have the concept of "lowering" the level of source-language abstractions from high-level to low-level viz. Written Source -> Simpler Source -> AST -> IR -> Machine Code. One type is "desugaring" i.e. transforming complex syntax to simpler ones so that the following stages of compilation have to operate only on a smaller and hence more manageable language subset.

This tool shows both desugaring and other lowering (eg. implicit transformations, type deductions etc.) within the C++ source language by regenerating the source from the AST thus giving you full visibility until that stage in the compilation process.

PS: Explanatory video presentation by the author - https://www.youtube.com/watch?v=VJ6ZvDRYzNE&t=558s

tweedler290 | 3 hours ago

thats crazy. i made this https://github.com/oooscoos/Benzi which does the same thing but is language agnostic (supports 9 other languages). urs probs goes in deeper into c++ than mine tho

abbefaria27 | 3 hours ago

This is very different and doesn’t relate to what the linked repo does.

kvemkon | 42 minutes ago

> See your source code ...

What I'd like to see, is how much time is spent to compile each block of C++ code (sliced as fine as possible).