MSVC removes hash_map in 14.51

MSVC 14.51 removes the long (10 years, apparently) deprecated non-standard extension `hash_map` (see here, “by design”).

Suggestions:

  • Change the USE_HASHMAP and NO_STL defines to not be hardcoded.
  • Replace hash_map with unordered_map.
  • Don’t guard the vector include, it’s used several times in the header in unguarded contexts.
  • Also it seems like someone just pasted the hold cpp file into the header to avoid a compilation unit. The only reason this isn’t getting multiple definition errors is because the header is only included in one file in the engine. Maybe this is by design.
    • The header also includes itself.
// Culprit lines: Engine\Source\ThirdParty\nvtesslib\inc\nvtess.h:146

#define USE_HASHMAP 1
#define NO_STL 1

#if USE_HASHMAP
#if PLATFORM_MAC || PLATFORM_LINUX
#include <unordered_map>
#include <vector>
#else
#include <hash_map>
#endif
#else
#include <map>
#endif

[Attachment Removed]

Steps to Reproduce

  1. Install MSVC with toolset >=14.51
  2. Compile Editor target.
  3. Compile failure in `Engine\Source\ThirdParty\nvtesslib\inc\nvtess.h`

Full error:

> C:\tide\ue5.8\Engine\Source\ThirdParty\nvtesslib\inc\nvtess.h(154,1): fatal error C1083: Cannot open include file: ‘hash_map’: No such file or directory

Culprit

// Engine\Source\ThirdParty\nvtesslib\inc\nvtess.h:146

#define USE_HASHMAP 1
#define NO_STL 1

#if USE_HASHMAP
#if PLATFORM_MAC || PLATFORM_LINUX
#include <unordered_map>
#include <vector>
#else
#include <hash_map>
#endif
#else
#include <map>
#endif



[Attachment Removed]

Reasonable work arounds:

Hello!

We recommend using the 14.44 (VS2022) or 14.50 (VS2026) toolsets with version 5.8. The information can be sourced from Engine\Config\Windows\Windows_SDK.json.

UnrealBuildTool will try to use one of the PreferredVisualCppVersions or default to the latest version of the toolchain installed if none are available.

As far as the removal of hash_map, we have addressed the problem in the main stream (CL54453441) but our hotfix rules are preventing us from updating version 5.8. Going back to 14.50 is the best workaround as this is the toolset that we used during the mastering phase of version 5.8 and will stick to it unless major security issues are uncovered. We do test our code with the newest and beta toolchain but we also have to settle on a widely available version when we enter our release cycles so we often ship a couple of version behind VS’s latest.

I’ll add this note on the forum to clarify the situation with the general public.

Regards,

Martin

[Attachment Removed]

I’ll check out that CL then, thank you.

[Attachment Removed]