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.
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.