Hacker News Reader

Comment by verytrivial | Hacker News Reader

I've been a C++ programmer for 20 years. Having just seen the example of template arguments in lambda functions:

1) I am reminded of this Larson cartoon: https://imgur.com/gallery/4gR7tX7

2) I have a palpable urge to learn Go.

The more I program in Go, the more retroactively irritated I get at C++. A buddy of mine did a few 'brown bag' sessions on advanced C++ templating and my jaw just dropped further and further at each one. Who has the energy for this? It's hard to write, it's hard to read, it's hard to debug.

For someone who a) knows what they're doing and b) really needs to squeeze every last millisecond out of the code I suppose they could be useful. It made me want to send Rob Pike a thank you card.

IMHO if you're messing with templates in C++ you've probably over-engineered your solution.

There are a few cases where they can make sense, like in the standard library, but most of the time without them your code will be cleaner and you'll never actually run into the case where they pay off.

I've run into cases where templates pay off once or twice. I was once able to refactor 1000+ lines of code into about 150 lines using a template class. However, I've tried more than once to learn "advanced" meta-programming techniques, and I've yet to find a use case that makes any sense.

I wrote a library a few years back to do in-place non-square transposition in the GPU register file. The algorithm had a lot of math that needed to be computed for every size matrix. I wrote it in C++03, before any constexpr, so the metaprogramming is intense. One of these days I'll rewrite it in C++20 and most of the code will go away. This code is still in use by the way.

https://github.com/bryancatanzaro/trove

If you need compile-time stuff that constexpr can't do, then you have little choice. Of course, in reality, its very rare that you "need" compile-time stuff.

It is not rare at all to want your program to handle generic output. Templates might not be the cleanest syntax but they do address a real need.

I wasn’t referring to genetics or saying that templates aren’t necessary or useful, or even that they aren’t common. Those uses of templates are relatively straightforward most of the time. Where templates, IMHO, become unwieldy is when trying to compute things at compile time. In many cases constexpr works here, but my point was that the remaining cases are relatively rare, certainly when you need it (as opposed to just wanting it, eg for performance).

Well, features like exceptions and classes don't improve performance. You could write the same code as fast in C, even if it would perhaps be more cumbersome and error prone to read and write. You save perhaps development and maintenance cost, but not runtime cost. Features like lambdas don't improve performance either, they rather make the language easier to write and even more hard to read (think of the name of a function as part of the documentation).

In theory the higher abstraction of C++ provides for optimization opportunities for a sufficiently smart compiler. I have yet to see such though.

Write the little bits which need to be fast in C and the gross in a sane language mere mortals can read (e.g. no 'most vexing parse').

C++ templates can indeed get crazy, but I miss them in every other language I use. For example, I recently wrote some code in which I needed to know whether or not a member existed in a class, at compile time. Turns out, there's a way to do that in C++ using templates and overload rules:

https://en.wikibooks.org/wiki/More_C++_Idioms/Member_Detecto...

Yes, conceptually it's a bit nuts, but the fact that you can do stuff like this makes it unlikely that you'll ever get completely stuck trying to implement something.

I personally love C++ because it's just a giant bag of tools, even if one of those tools is a footgun.

Having experienced similar "ah thank god C++ allows me to do [ridiculous template magic]" moments, 99% of the time it is because the language is forcing you (or leading you) into some kind of design that would have never been necessary in a different language. I have seen many hours/days wasted on using esoteric C++ features in order to get around a language limitation/quirk.

So I am going out on a limb here and assuming that your needing to know whether or not a member exists in a class at compile time is simply something you would never need in a different language because the language would allow you to design for something simpler that satisfies the same requirements. As someone who writes both C++ and C# daily, I often end up comparing the two and most of the time I end up thinking "it's cool that you can do that in C++ but this would have been half the lines and cleaner code in C#".

In my case, I needed to know whether or not a member exists in order to implement object tracking. I basically have a macro that inserts a member into a class, and calls that member's constructor with the "this" pointer of the tracked class. A different function needs to know, at compile time, whether or not a class is tracked, as the way memory is allocated differs.

I didn't want to use inheritance, as tracking is disabled in a shipped build, and I want it to have as little effect on the codebase as possible. So, the simplest option seemed to be to check whether or not the member exists (and assume the name is unique enough an untracked object will not contain it). This was good enough for my purposes.

I'm not as familiar with C#, but attributes seems like a potential alternative, though I'm not sure they can be fully removed from a release build. And, of course, C# is garbage collected, which is not ideal for all types of software. If there is a better alternative, I'd be interested in hearing it though!

Don't get me wrong, I'd absolutely love a "better" C++. Rust is a great language, but I personally don't feel that the safety guarantees are worth it for every class of software. If a video game crashes, the world isn't going to end.

C++ and Go are different languages with different goals.

Why would a C++ programmer learn Go? They should learn Rust since it is pretty much a cleaned up, modernized C++.

> Why would a C++ programmer learn Go?

Perhaps to find a new reason to hate a programming language thanks to Go's GOPATH.

rust is just new, not too bloated, YET. long way to go until it can be seen as a "better C++".

Agreed, it is lacking tooling support and many other things, but it is a cleaner C++. That plus the borrow checker are its two major features. Otherwise, nobody would use it and their designers would have done a pretty bad job given the 30 years of experience they had from C++!

There are a million things. Fast compile times, UTF8 strings by default, easy concurrency, great standard libraries.

And the most important thing - I can easily read and understand the code written by others.

> It made me want to send Rob Pike a thank you card.

Do it, it'll make his day.

Maybe I should!

I sometimes feel like sending one to Bjarne Stroustrup too, because C++ is still an incredible language. I see Rob and Ken talking about how they hate C++ and I worry about poor Bjarne's feelings.

> A buddy of mine did a few 'brown bag' sessions on advanced C++ templating (...) Who has the energy for this? It's hard to write, it's hard to read, it's hard to debug.

C++ programmers who dedicate themselves to template metaprogramming are like stunt performers. You see them get on their shiny bikes and flashy costumes, you clinch your fists in a mix of fear and awe when they showcase their skills, but in the end it might be entertaining but it has virtually no real practical use beyond extremely niche applications.

I'm afraid you've describe my friend to a T. Ah well, it takes all types. If we couldn't work with some strange personalities, we wouldn't make it far in this business.

I've programmed in C++ off and on for the last 25 years. I keep wondering if I should spend the time to level up on modern C++ (C++11,14,17,20) or if I might be better off to just chuck it all and dive into Rust and/or Zig and place my bets there instead.

Go with Golang if you want simplicity. Go with Rust if you want a complex but still neat programming language. Rust is much better than C++ in my humble opinion. I use these programming language as a hobby and I don't think I will ever use c++ on a new project again.

I've never been that impressed with Go - it seems to be missing a lot of modern features. To me, Zig looks nice from a simplicity standpoint and it fits in the systems programming space.

Everything Go is missing is what makes C++ complicated.

That is by explicit design.

I don’t mean this as an insult: Pike is quite open about choosing a different region of the design space; he had good reasons for it, they just happen not to work for me.

I off and on wonder if Net Core is going to eat golangs lunch outside of google.

Read this before you go with Go: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

Go is not a replacement for C++ or Rust. It is not an actual systems programming language.

If you learn Rust or C++20, the marginal cost of learning the other should be trivial.

After writing a bunch of Rust, I recently had to learn C++. I've been storing C++ in my brain as "Rust + delta of dubious ideas", which, not to start a flame war, has easily been a better compression algorithm for my brain than storing C++ in isolation.

For example:

- C++, const is part of the type. Clearly wrong.

- Rust, mut is property of variable, or & vs &mut. Correct, but lack of & with mut-polymorphism just causes needless suffering.

- Rust construction: good, Rust destruction: bad

- C++ destruction: bad, basically like Rust's. C++ construction: bad, matches C++ destruction.

(I've been saying for years that drop needs to consume, not borrow the thing to be destroyed, but no uptake :(.)

What's the issue with Rust/C++ destruction? What do you mean by consume instead of borrow?

`drop(&mut self)` means, strictly going by the types I could call drop twice! We want an `&own` that is like C++'s rvalue references (so we can still drop DSTs) so we can have `drop(&own self)`.

This correctly prevents one from calling Drop::drop twice without extra hacks, and demonstrates that the location is completely deinitialized and can be reinitialized to anything.

It is also dual to how, seemingly magically,

    let x;
    x = foo();

works without Rust thinking there is an old value of `x` to get rid of.

> `drop(&mut self)` means, strictly going by the types I could call drop twice!

Wouldn't calling a destructor on an object twice will also compile in C++? I don't really see this as an issue in either language; the solution is "don't ever call `drop`/destructors manually"

To be clear, it won't compile in Rust either; you cannot invoke Drop::drop yourself:

    fn main() {
        let mut v = vec![1, 2, 3];
        
        v.drop();
    }

building:

       Compiling playground v0.0.1 (/playground)
    error[E0040]: explicit use of destructor method
     --> src/main.rs:4:7
      |
    4 |     v.drop();
      |       ^^^^
      |       |
      |       explicit destructor calls not allowed
      |       help: consider using `drop` function: `drop(v)`
    
    error: aborting due to previous error

std::mem::drop, which it refers to, does take by owner.

Your parent's point is that this is kind of a weird corner case that only applies to drop.

Oh, interesting! I had never tried to call it manually, so I didn't realize that it wouldn't let me.

> C++, const is part of the type. Clearly wrong.

It’s pretty hard to express that an object must be invariant without a thing like that. You can’t do so with the storage itself as the object may be passed to a function.

But if something is passed by value, the caller should never care whether the callee mutates its (shallow) copy. It's purely an unobervable implementation detail of the function.

Call by value is not that common any more in C++ except with scalars.

Although there are legit cases for what you describe, it’s a pretty uncommon case.

Not passing things around by value doesn't solve the problem. For example, template machinery has worry about absurd things like `const .. &&`.

Does anyone actually use Zig in production? I've only ever read about it here on HN.

There's no avoiding Rust. It's becoming the jQuery of systems programming.

C++ has lost the plot in some respects but you don't, and probably won't ever, end up using all of it. A lot of it is to make it easier to write things like the STL, not your typical end-user program. Learn up to 17, there's some good stuff in there. If someone in an interview gives you some highly complex templatey code snippet to analyse just tell them to go fuck themselves.

> Does anyone actually use Zig in production?

Likely not, or at least they shouldn't, as it still has yet to have a 1.0 release and is undergoing constant changes in syntax and API.

However, that doesn't mean one can't take the time to learn it right now. Zig shows a lot of promise for being a real contender in this space once it does have a stable release.

> Does anyone actually use Zig in production?

As I'm mostly retired at this point, I don't really care how marketable skills are anymore. I go for what looks interesting.

Lucky you!

I agree that C++ has lost the plot, but I find that it's a very good language for code generation. I don't write it directly, but I use its incredible compilers and ecosystem, including multiple profiling and debugging tools (uftrace is a nice one that even dynamic languages seem to lack).

I'm translating a subset of statically typed Python to C++:

http://www.oilshell.org/blog/2020/05/translation-progress.ht...

http://www.oilshell.org/blog/2020/01/parser-benchmarks.html

I use very much a "pidgin" subset of the language -- one that is easy to step through in the debugger! The problem with all these fancy new features is that you're more likely to trip over bugs in the debugger, e.g. incorrect line number information and stack traces.

So the generated code doesn't even use operator overloading, which e.g. C++ 11 range for loops require. I want to be able to see everything. Yet I also want to use features like templates, virtual methods, and strict enums, which C doesn't have.

-----

Another "modern" project that does this is the Souffle datalog compiler, which generates "monolithic" C++ programs with heavy use of C++ templates:

https://souffle-lang.github.io/translate

(I heard about it due to its role in prototyping Rust's type system)

C++ templates are not fun to write but they have some interesting properties for code generation.

-----

So I would happy if we stopped writing C++ by hand. But I do not like the alternative rewriting inferior versions of existing programs/libraries in entirely new languages. They often have new bugs, are slower, and have fewer features.

I really like what Zig is doing to reuse existing code (i.e. bundling a C compiler). I think that both Rust and Go ecosystems have led to a lot of fragmentation and redundant efforts.

addendum: So I think there is also room for more languages that compile to C++, and live within its ecosystem rather than fragmenting it.

The "History of Clojure" paper has a nice view on that. Why Clojure is tied to the JVM. So it's part of the ecosystem rather than fragmenting it.

Thought experiment: What feature additions would modern C++ need to be a good Clojure compile target? Besides the obvious GC.

> Does anyone actually use Zig in production?

Zig is cool but still very much unstable, running it in production is very much not recommended and/or insane. There's still quite a lot of compiler/stdlib bugs, design edge cases, and breaking changes including introduction of new bugs.

But it's amazingly refreshing for hobby stuff!

> There's no avoiding Rust. It's becoming the jQuery of systems programming.

I'm not sure if that's meant as a good thing or a bad thing. Given the target audience, I expect a good thing, as for people not entirely immersed into JavaScript and web development at the time (which I expect most people reading about C++ features here were not), jQuery was a godsend. It gets kind of a bad wrap these days, but from my perspective, JavaScript just adopted all the paradigms it encouraged into the language so it's no longer needed. Hard to argue with that success, IMO.

jQuery was undermined not because it wasn't a good idea or it was poorly designed, but because it matured early on and Javascript evolved rapidly enough that the technical premises it was built on no longer applied.

A more concrete example of this is Windows and Java's use of UCS-2 as their character type. That was a forward thinking move which then became a painful legacy issue when Unicode changed.

That's inevitably going to happen to Rust to some extent, but it's targetting a realm that is far slower to evolve and it seems like they are very mindful of history and theory.

I did this a few years ago: picked up C++ 17 after a 25 year hiatus by treating it as a brand new language (and by treating its connection to C as you would Java’s connection to C: a distant ancestral relative).

Modern c++ is a powerful, expressive language. It’s not a “object oriented” language in the fetishistic sense — I don’t write that many classes comparatively. A lot of generic programming and functional algorithms in my case. And I can couple directly to the iron as needed.

Yes there are some unfortunate syntactic issues due to it having evolved from C but that’s how the world works.

I keep wondering if I should spend the time to level up on modern C++ (C++11,14,17,20)

Yes, absolutely. I (somewhat recently) did that, and I find modern C++ to be almost like a new language. The "modern" features are very useful and powerful.

Learning up to C++20 if you are an experienced C++ programmer is easy as long as you only use whatever features you learn or make sense for your project.

Studying everything new is, of course, a much more ambitious goal.

I think unambiguous parsing drives the chosen syntax more than pleasing aesthetics.

Other languages manage to be parsable without the syntactic aesthic getting Lovecraftian. I think the other factor in C++ is the how much has been added to the language while maintaining backward-compatibility.

It's new feature for a standard that's not even out yet. It doesn't matter how long have you been learning C++, unless you are invested in the language design and read proposals.

Reply on news.ycombinator.com