Comment by motorest
3 days ago
> 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.
Not silly at all, if it can't be enforced in a standard portable way, its place doesn't belong in the standard, at all.
I would have voted SA on this matter, if I had a life that would allow me to go around voting at WG21 meetings.
We have vcpkg and conan now, the standard library cannot be a distribution vehicle for organisations that refuse to adopt C++ package managers.
> 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?
No the point of a standard library is to provide vocabulary types (so that third-party libraries can interoperate) as well as basic operations that are essentially set in stone. Anything beyond that needs to have its usefulness weighted against its maintenance burden, which for a standard library that is serious about backwards compatibility is enormous. C++ is already also heavily criticized for being complex with many problems having multiple outdated solutions that you're not supposed to use.
"Onboarding" a third party library isn't this herculean task that you make it out to be but is in fact a very basic part of software development that almost any project will have to deal with anyway unless you are into reinventing the wheel - even excessively bloated standard libraries don't manage to cover everything.