Yes. Over 15 years ago I proposed a library for Vec2, Vec3, and Vec4 to the C++ standards committee. It's the one from Graphics Gems, but rewritten as all inline.[1] The C++ standards people wanted more usage of templates.

A few academic projects use that code.

[1] http://www.animats.com/source/index.html

Just adding a new header-only library for vector arithmetic isn't something that needs to be in the language standard (library), there are lots of options for that already (such as glm[1]).

I've been using vector extensions for my 3d graphics and physics stuff for years now and it works great. There are some pain points, but it already covers most of what I need. As a bonus, it can be used in plain C and you get all the usual math operators (+, -, /, etc) for free. There are minor incompatibilities between GCC and Clang, but nothing a few #ifdefs won't solve.

Here's a quick introduction in a few lines of code:

    typedef float vec4f __attribute__((vector_size(16)));
    vec4f a = { 1, 2, 3, 4 }, b = { 5, 6, 7, 8 };
    vec4f c = a + b;
    vec4f d = (a + b) * c; // with --ffast-math, you will get fused multiply-and-add (MAD)

If anyone is interested, some of my math routines are bundled in this github repo [2]. It's incomplete, undocumented, not well tested and there are known issues I haven't gotten around to (e.g. quaternion products give wrong results).

If anyone thinks this is useful and is interested in contributing/collaborating, leave a comment.

[0] https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

[1] https://glm.g-truc.net/0.9.9/index.html

[2] https://github.com/rikusalminen/threedee-simd

Making your vec4f type a SIMD register type is not a good way to make use of SIMD hardware. The best approach is generally an SoA (Struct of Arrays) rather than an AoS (Array of Structs) and the best CPU programming model for that is something like ispc[1].

Nathan Reed has a good summary of why "naïve" SIMD libraries after not the way to go for short vector math: http://www.reedbeta.com/blog/on-vector-math-libraries/#how-t...

On some platforms alignment issues become a big problem for naïve vector math libraries too, though this is less of an issue on current generation x64 hardware.

[1] https://ispc.github.io/ispc.html

I like that GCC defined their own way to declare these that is independent of x86, ARM, and Altivec intrinsics so your code is portable (so long as you use GCC). Geometrically relevant vectors are common enough to be native types, let's get there.

Or Clang!

There are only minute differences between vector extensions in GCC vs. Clang. Little things like __builtin_shuffle vs. __builtin_shufflevector.

SDL2 doesn't have a 2D graphics API in the traditional sense. It has a basic bitmap software blitter designed for debugging and bootstrapping. SDL2's main forte is just a being a cross-platform wrapper around the HW-accelerated APIs like OpenGL and Direct3D.

> to one in QT, GTK, Cairo

While Qt does indeed have QPainter, it is switching away from QPainter towards OpenGL with QtQuick. GTK+ uses Cairo (with plans to switch to OpenGL/Vulkan as well). So so far, our list is down from 4 to 2.

> and then the more proprietary ones

I'd list it as: GDI+ (Microsoft), Quartz 2D / CoreImage (Apple), Skia (Google) and Cairo (X.org). HTML5's <canvas> API is taken from Quartz but is often backed by the others.

So there are not that many choices for a modern 2D vector graphics library. My main issue with the 2D proposal is that hardware acceleration and modern graphics just flat out doesn't work the way the 2D API expects it to. You can be very good at pretending, but at some point you'll have to grow up, put on your big boy clothes, and use learn how GPUs work. Hence why there's the heavy migration away from the others. Direct2D has a good example here of a good API, even if the implementation is a bit wacky. Pathfinder 2 is similar.

This is actually incorrect. The SDL Render API does use GPU acceleration.

I'd be happy to see vec2/vec3/vec4 style APIs in the C++ standard, too. P0267/io2d does have some support for this, although I think it could certainly stand to get some love + attention!

It's probably a far safer bet that algebra won't be changing very often, much less so than any graphics pipeline!

I think they would be wise to think a little beyond beginners though. Algebra does not have to be always complicated, but it definitely needs to be open-ended to extend its usefulness.

The standard has been burned by short-sightedness before.

A graphics API won't replace all the custom-made graphic APIs, just as std::string didn't replace all the custom-made string libraries. Nevertheless, it's great to know you have something readily available.