> Not even those that have Android/Linux NDK builds, bother with porting to GNU/Linux.

It is a huge hassle to make a new build to a new platform. You double build system, release management, and testing. Compared to just one plat. Games are complicated, and testing all the dynamic behaviour is also complicated.

Making just a Win32 build really saves resources.

Also Win32 has been a stable api for a long time. Linux apis tend to change, and old games don't get re-built. The win32 build is therefore also provably a lot more long lived, compered to anything you build on linux.

Thats also important because of the Dont Kill Games effort and so on.

After all, if the Software does not work, its just a Paperweight

A tangent, but what is Obvious depends on what you know.

Often experts don't explain the things they think are Obvious, but those things are only Obvious to them, because they are the expert.

We should all kind, and explain also the Obvious things those who do not know.

Contrast this with ip6, which is a completely new system, and thus has a chicken and egg problem.

Neither of which is in EU, which is exactly the point. Should be an EU one which is usable...

   char buf[12];
   sprintf(buf, "%s%s", this, that); // or
   strcat(buf, ...) // or
   strncpy(buf, ...) // and so on..

says

> Increase the capacity of the vector (the total number of elements that the vector can hold without requiring reallocation) to a value that's greater or equal to new_cap.

I belive that the behaviour of reserve() is implementation defined.

After some pondering, and reading the rust documentation, I came to the conclusion that te difference is this: reserve() will grow the underlaying memory area to the next increment, or more than one increment, while reserve_exact() will only grow the underlaying memory area to the next increment, but no more than that.

Eg, if grow strategy is powers of two, and we are at pow(2), then reserve() may skip from pow(2) to pow(4), but reserve_exact() would be constrained to pow(3) as the next increment.

Or so i read the documentation. Hopefully someone can confirm?

The higher level the language, the less interest there is to manually manage memory. It is just something to offload to the gc/runtime/etc.

So, i think this is a no-go. The market wont accept it.

If the underlying resource can not behave like a class, it would be better to expose a free function style api, eg:

    Handle h = ResourceGet();
    ResourceDoSomething(h);
    h.release();

Should it not be std::array<>?