Comment by William_BB
3 days ago
You sound like you subscribe to "Orthodox C++".
Speaking seriously, I agree there's definitely a lot of bloat in the new C++ standards. E.g. I'm not a fan of the C++26 linalg stuff. But most performance-focused trading firms still use the latest standard with the latest compiler. Just a small example of new C++ features that are used every day in those firms:
Smart pointers (C++11), Constexpr and consteval (all improvements since C++11), Concepts (C++20), Spans (C++20), Optional (C++17), String views (C++17)
> I'm not a fan of the C++26 linalg stuff.
I don't agree at all. For most, linear algebra is the primary reason they pick up C++. Up until now, the best option C++ newbies had was to go through arcane processes to onboard a high performance BLAS implementation which then requires even more arcane steps such as tuning.
With C++26, anyone can simply jump into implementing algorithms.
If anything, BLAS support was conspicuously missing from C++ (and also C).
This blend of comments is more perplexing given that a frequent criticism of C++ is its spartan standard lib, and how the selling point of some commercial software projects such as Matlab is that, unlike C++, linear algebra work is trivial.
Except the devil is in the details as usual, the way linalg is specified doesn't guarantee numeric stability across library implementations or compilers.
Just like the std::random mess, most people are in for a surprise when they attempt to write portable numeric code with it.
> Except the devil is in the details as usual, the way linalg is specified doesn't guarantee numeric stability across library implementations or compilers.
I think this criticism is silly. You're complaining about the C++ standard not enforcing something that is virtually impossible and no implementation under the sun even suggests it would conceivably support. And we should just assume C++ would be able to force it across implementations, target platforms, and even architectures? Ridiculous.
> Just like the std::random mess (...)
The comments I've seen regarding std::random mainly refer to gotchas, such as std::rand returning values in [0, RAND_MAX] and the latter being a platform-specific constant.
There is a reason after all why you only throw vague complains of "mess" instead of pointing out specific concerns or grievances. You need to complain, regardless of merit.
Overall, this blend of criticism is no different than the cliche criticism targeting the STL. Sure, some niche applications can and do have better ways to scratch their niche itches. In the meantime the STL perfectly serves the need of 99.9% of all common usages. Is this not the point? Doesn't linalg and rand achieve this?
Of course vapid nitpickers can still pull out the last resort card of complaining that the implementation is too complicated, a grievance also directed at the STL. But that's just the extent where this silliness goes.
1 reply →
> I don't agree at all. For most, linear algebra is the primary reason they pick up C++.
Out of hundreds of hundreds of projects I've interacted with, maybe less than 1% have used linear algebra in any non-basic capacity (e.g. more than multiplying two 4x4 matrices) and had to use Eigen or BLAS
> Out of hundreds of hundreds of projects I've interacted with, maybe less than 1% have used linear algebra in any non-basic capacity (e.g. more than multiplying two 4x4 matrices)
Are you really trying to argue that if you ignore the bulk of applications that have linear algebra then only a few have linear algebra?
> and had to use Eigen or BLAS
What if I told you that if C++ provided basic support for linalg, your average C++ developer wouldn't ever have to hear about Eigen or blas?
It's perfectly fine if you want to use the likes of Eigen. It's also perfectly fine if any developer opts to ditch the STL and use any performance-oriented container.
But is it ok to force everyone to onboard a third party library just to be able to do very basic things like use a stack or do a dense matrix-vector multiplication? I don't think that leads to a good developer experience.
> This blend of comments is more perplexing given that a frequent criticism of C++ is its spartan standard lib
The frequency doesn't make the criticism more valid and those repeating it would be better served to let go of their fear of third-party libraries.
> The frequency doesn't make the criticism more valid (...)
The criticism is not valid. It's specious reasoning at best, fueled by a hefty dose of gatekeeing.
The only rationale that is relevant is whether the standard library provides a way to do a very basic and fundamental task instead of having to force anyone to onboard and manage third party dependencies. That's the whole point of a standard library, isn't it?
1 reply →