C++ : if constexpr isn't broken • Hacker News Board

Re: C++ : if constexpr isn't broken

#81

Post by carlmr » Thu, Jan 17, 2019, 8:17 AM UTC

neutronicus wrote: post #17

nivexous wrote: post #15

Earlier quoted context omitted.

In Bitcoin SV, there is a saying "devs gotta dev" to refer to the mass of crypto developers that add unnecessary complexity to their coins to solve minor or even nonexistant problems while not seeing the bigger (usually economic) picture. Everyone wants to make their mark on the space and there aren't enough leaders to direct the energy. C++ looks to be doing the same and not able to see the impact this will have on…

I disagree - I work in high-performance computing and I think in our case the complexity of C++ is actually mirroring that of the problem domain. Nothing else gives us the level of abstraction that C++ does, while still offering convenient ways to specify low-level performance semantics . I think for a while Fortran was pulling ahead for large-scale numerical computing, but the mess of different options for paralleli…

I agree that in your case C or C++ is probably the way to go (I usually favor C, because while it affords less options for abstractions it also doesn't give so many possibilities to shoot yourself in the foot in unimaginable ways (still enough mind you)).

Your parent poster is also right. Rust offers a lot of safety guarantees, a modern, well-designed language around it, package management, test and benchmarking integration, and extremely good type safety, while still mostly having zero cost abstractions for many things. If your goal is performance, control and safety, Rust is a much better choice than either C or C++. I'm still hopeful that it shall become the next big embedded language (mostly processor support missing here, but thanks to LLVM there's hope), especially since we haven't seen any other good attempt at GCless computing (no GC is pretty important for real-time systems).

But I must admit that with C++ you can probably eke out a few % more performance. The thing is though that with Rust, for 99% of projects where performance and no-GC is important, will be fast enough, especially due to safe abstractions, often faster than C++.

One example is if you have a lot of text processing to do. Often you can reuse a lot of the strings. In Rust you can safely handle this due to the borrow checker. Avoiding allocation of new strings is pretty much the biggest performance problem for most string processing.

Rust gives you a lot of safety when it comes to multithreading as well. It's perfect for creating little servers and using all your processors for performance.

These two together, and the lack of 2-3 day debugging sessions where you trace down that one tiny memory bug in C++, make Rust the biggest contender to replace C++. Of course if you only care about performance. C or C++ is probably still a slightly better choice, slightly.

Re: C++ : if constexpr isn't broken

#82

Post by cjhanks » Thu, Jan 17, 2019, 9:48 PM UTC

renox wrote: post #72

cjhanks wrote: post #9

I agree with this blog writer. Allowing typedefs to cross static if boundaries would be a major change to the way I read code. Unless there's a more substantive example demonstrating why using the existing metaprogramming is insufficient, its benefits are imo outweighed by its cost.

Well you already have to remember that 'if' introduces a scope but '#if' doesn't..

I guess that's true. But I can't remember the last time I have used `#if` aside from header guards and optimization paths. So they do exist, but I almost never do this.

Re: C++ : if constexpr isn't broken

#83

Post by jupp0r » Wed, Jan 23, 2019, 10:20 PM UTC

ska wrote: post #29

jupp0r wrote: post #19

Earlier quoted context omitted.

Isn't every developer in a non-trivial software project a library developer? As soon as you have a common piece of functionality you want to reuse - that's a library.

I understand this sentiment but think it is problematic. In fact, I think it is part of the reason a lot of libraries aren't very good. Working in a large project, as you note, naturally leads to many conversations about sharing code and/or functionality. So you bundle something together or add an access point, call it "library X" and you are done, right? Any problems can be patched around later as you are working on…

It wasn't my intention to say that writing a library in C++ is trivial. Just that it's inevitable in non-trivial projects. So I agree that lot's of knowledge and thought have to go into API/ABI design, versioning etc. On the other hand, only because C++ gives you lots of choices that other languages don't, it doesn't mean that only a hand full of "library developers" will have to make those choices. Almost everybody has to make them, coincidentally or consciously.