Hacker News new | past | comments | ask | show | jobs | submit login

Sadly, the thing that stood out the most to me is the sentence We attempt to make the compiler generate the most sensible error message, followed by an incomprehensible error message completely unrelated to the problem.

C++ should really get proper metaprogramming, with support for user-defined error messages. All this template stuff always seemed like an awful hack to me: Fighting the compiler instead of being the compiler.




It is a hack, but what else is there eh?

Going from templates to constexpr is like moving from a war zone to a forest. It's still scary and dark, but at least you know what hit you. static_printf is coming soon.

The error message looks incomprehensible, but the last couple of lines give you enough information - the error string and the line number - it looks much better on the console since its colorized


    > It is a hack, but what else is there eh?
The non-hacky way to do this sort of thing in both C and C++ is to just use less clever two-phase compilation as part of your build process.

I.e. you'd have your template compiler extract the HTML from your source (or more easily, dedicated template files), parse, validate and compile them. The end result of that would then be embedded in your binary somehow.

The gettext set of tools are a good example how how this works in another related domain. You extract strings from your program, they and the contents of corresponding .po files are validated, then compiled to efficient .mo binary files for runtime use.


Why rely on an external tool?

All someone has to do here is #include my header and write their templates with a small suffix and prefix.

No need to install, configure, script and so on.

Your argument is similar to saying "Why should an IDE parse your code and underline errors? We can run make everytime"

Another advantage of my approach is that you have access to the parsed template as a data structure - that you can compose or modify as you wish.

The only other way to do this is to parse at runtime - which is definitely slower


Most people using gettext get it via their package system. Your library is also an external tool they need to similarly fetch & install.

And no, my argument is not similar to your IDE comparison. You'd get the exact same thing, parsing / compiling when you compile your project. You'd just offload slightly more work to make & the linker.

You can also get access to the parsed version as a datastructure. This is what the gettext library does with its compiled *.mo files.

Anyway, I don't think your thing is a useless approach. It's very hacky in C++ but this sort of thing is the best way to do something like this in many other languages.

I was just pointing out that there's decades of precedence for achieving the same results in C, i.e. parsing some custom language out of the project at compile-time and shipping it with the binary. Which you (with your "what else is there" question) seemed to be unaware of.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: