cppwin32 VS EA Standard Template Library

I would imagine something like https://github.com/microsoft/cppwin32 would maybe be an easier way forward for that?

no, Microsoft has rewritten the windows API in C++ I think https://github.com/microsoft/cppwin32

An official work in progress Windows binding, still far behind of what C# existing bindings are capable of, or legacy toolkits like MFC.

Also given how the team has managed C++/CX transition to C++/WinRT with lesser tooling stuck on C++17, dropped Modern C++ bindings [0][1], before going into other shinny thing, I wonder how long they will keep at it.

[0] - https://blogs.windows.com/windowsdeveloper/2021/01/21/making...

[1] - https://github.com/microsoft/cppwin32

If you want to use the old tooling, your C++ is going to be very "C with classes," and it's going to use a lot of weird datatypes that don't feel very C++ at all. Microsoft had a project for wrapping the Windows API in idiomatic C++, but appear to have abandoned it. If you choose to go down this road, Charles Petzold's Programming Windows is the book to get. Yes, it's 25 years old, but all the new stuff is just new COM controls (which you can look up in the API documentation)--the fundamentals of making a Windows API program work seriously have not changed.

Even Rust has a native projection of the windows API (which is actually pretty usable). This projection has the same roots as the C++ projection mentioned by u/amnesiac0x07C5. So I don't believe macros are a blocker here.

See : https://github.com/microsoft/cppwin32

Microsoft have recently put decent effort into making the Windows APIs more accessible to C++ users. One of these efforts is called C++/WinRT, and it specifically targets applications intended for "modern" Windows (Windows 8 and later). There's another effort underway at Microsoft for making the older Win32 API more C++-friendly, but it isn't documented nearly as well.

There is a similar project for C++, but it sadly seems to be dead already. The last commit was one year ago.

not that hard to wrap windows.h and undef the annoying stuff, and only a handful of files in your codebase will include it anyway. on the other hand stuff like this looks extremely worse and exactly like the kind of c++ that is hard banned in gamedev codebases

They are, actually, it's linked from the article: https://github.com/microsoft/cppwin32

> you can still use it with smart pointers provided by any other library

Is the point of having a kitchen-sink library like this not that you dont have to reach for a 3rdparty library for things that you need 'all the time'?

Certainly, not everyone needs it.

...but, not everyone needs threads either. Not everyone needs an http server; and yet, if you have an application framework that provides them, when you do need them, it saves you reaching for yet-another-dependency.

Was that no the point from the beginning?

unique_ptr is a fundamental primitive for many, as you see from some other frameworks (1), and implementation is not always either a) trivial, or b) as simple as 'just use std::unique_ptr'.

This does seem like a very opinionated decision with reasonably unclear justification.

[1] - eg. https://github.com/EpicGames/UnrealEngine/blob/release/Engin..., https://github.com/electronicarts/EASTL/blob/master/include/...

Can I introduce you to EASTL

For games focused stuff have a look at EASTL https://github.com/electronicarts/EASTL also perhaps some of the Data Oriented Design stuff (see Mike Acton's CPP Con Talks). This also have loads of good stuff https://www.dataorienteddesign.com/dodbook/

C++, but generally treat it as C. STL is pretty slow while debugging so we avoid it and write our own replacements. If you don't want to drive that deep use something like EASTL: https://github.com/electronicarts/EASTL

In my experience game devs don't eschew the STL because of compile times, but because (a) its memory management is not sufficiently tunable and (b) it uses exceptions heavily which many game engines disable entirely due to perceived performance problems. For this reason, some of the engines I've worked on have used their own forks of the STL in the spirit of EASTL to rectify these issues. Others like my current project just don't use the STL at all (outside of some third-party library code) and use custom libraries for everything.

In my opinion, you should also benchmark it against something like boost::container::flat_set or eastl::vector_set and you should expect the same performance as with your ordered functionality. Another interesting idea for organization of such flat and sorted container can be found here.

finally, if you're worried about performance (a lot of aspiring game programmers seem to be, even though for anything but high-end engines the STL is likely fine if you know what you're doing..) you could look into the EA STL or other STL replacements..

check it out: https://github.com/electronicarts/EASTL

I just took a look at their atomic.h and wow, "well-documented" is an understatement !