> proof that the person saying that does not understand the C++ language. This was followed by several "I am a C++ standard library implementer and everyone I know calls it the STL". Things deteriorated from there.
It feels natural to assume that the implementers and long time WG21 members must understand the language, but this is not true. C++ spiralled well beyond the capability of a person to actually understand it years ago.
Maybe that's unfair, but it's unusual. This is a constructed language, its syntax and semantics matter greatly and yet in practice our grasp of its meaning is more akin to that for say, English, than for Perl or Rust.
There are contradictory style guides, people with well meant rules of thumb contradicted by a world of real usage, numerous dialects, not to mention people who strongly believe other users of the language are "doing it wrong" and yet what they're doing works fine.
Compare the C++ code samples with the Modern C++ usually talked about C++ conferences.
This is why I keep saying I only see such high bar code on conference slides, and my hobby projects, those DirectX code samples are much more closer to daily C++ written in big corporations, ironically even those that are C++ compiler vendors with seats at WG21.
On the other hand, there are many industries where I don't see Rust taking anything meaningful away from either C or C++, regardless of how much we complain about them, or how much better Rust happens to be over them.
Microsoft's DirectX C++ example code needs to interact with DirectX' C APIs. That will easily lead to "C with classes" C++ when most of the code is interacting with foreign APIs, like these API demos do.
I think open-source software like https://github.com/microsoft/WSL is probably more representative of what modern C++ companies look like. Plenty of files that just interact with OS C APIs, but no shortage of modern C++ features in use.
I would not call that example production quality code.
CreateFileA API thing is only available for compatibility with prehistoric software written for Win9x from the nineties. Also, the SDK comes with CAtlFile class which wraps CreateFileW / ReadFile / CloseHandle and guarantees closing handle in the destructor.
They are using a raw pointer in OMMSet structure which leaks memory. I would replace the raw pointer with std::unique_ptr<D3D12_RAYTRACING_OPACITY_MICROMAP_HISTOGRAM_ENTRY[]>
As for the _alloca, I think it’s OK however I usually assert() the size being allocated is reasonable, like under 256kb.
That particular class doesn’t depend on the COM-related pieces of the ATL library. It can be used in any C++ project which targets windows desktop platform. I think since VS2015 ATL is available even in the freeware community edition of the IDE. Before that, it required a commercial edition.
About non-Unicode WinAPI functions, I don’t use them at all in the software I’m developing, nor the TCHAR conditional typedef. VC++ compiler defines wchar_t as a built-in type for the UTF16 strings used in WinAPI functions.
> It can be used in any C++ project which targets windows desktop platform.
Any project which only targets Windows, or at least it can only be used in Windows-specific code. Even if you currently only target Windows, baking platform-specific types into your core is foolish.
It feels natural to assume that the implementers and long time WG21 members must understand the language, but this is not true. C++ spiralled well beyond the capability of a person to actually understand it years ago.
Maybe that's unfair, but it's unusual. This is a constructed language, its syntax and semantics matter greatly and yet in practice our grasp of its meaning is more akin to that for say, English, than for Perl or Rust.
There are contradictory style guides, people with well meant rules of thumb contradicted by a world of real usage, numerous dialects, not to mention people who strongly believe other users of the language are "doing it wrong" and yet what they're doing works fine.