fastrtps fails to compile on greater than or equal to msvc version 19.38.32926.95

[jimwang118]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

No error

Current behavior

Hello, I'm a member of Microsoft VCPKG, when I built this port in an internal version of MSVC, it failed with following errors:
E:\Jim\vcpkg\buildtrees\fastrtps\src\v2.11.1-d9ab4e5ea6\include\fastrtps/utils/TimedMutex.hpp(177): error C2065: '_Thrd_success': undeclared identifier

Steps to reproduce

Build with MSVC 19.38.32926.95 and above, _Thrd_success is modified to _Thrd_result::_Success since microsoft/STL#3897, it's an upcoming release.

Fast DDS version/commit

2.7.0. For details, see: fastrtps/vcpkg.json

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

Default configuration, UDPv4 & SHM

Additional context

Windows
Visual Studio
The STL developers suggest that we should not be using internal STL identifiers. Also practice STL developer if you have other questions.

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[jimwang118]

cc @StephanTLavavej

[jimwang118]

cc @MiguelCompany. _Thrd_success and _Thrd_result::_Success are identifiers that belong to the STL, the STL developers suggest that we should not be using internal STL identifiers.

[StephanTLavavej]

Yes - according to the C++ Standard, _Leading_underscore_capital names are reserved for use by the compiler and Standard Library, so third-party libraries should not be mentioning these identifiers. This rule exists so the STL can avoid stomping on third-party libraries and vice versa, so it is important to follow.

The rename from _Thrd_success to _Thrd_result::_Success is backwards-incompatible so if you want to continue this non-Standard, technically-forbidden practice, you would need to check _MSVC_STL_UPDATE to detect the specific version of MSVC's STL being used. Alternatively, you could static_cast<int> the value and compare it to 0 which is the successful value; this will remain unchanged for the life of the "v14" binary-compatible release series (VS 2015/2017/2019/2022 and probably the next major version at least).

[jimwang118]

@MiguelCompany, Do you fix this by comparing the STL version, or by comparing with 0?

[jimwang118]

@StephanTLavavej @MiguelCompany The functions _Mtx_timedlock, _Mtx_init, and _Mtx_destroy are deleted in PR 3912 of STL. Are there other functions that can replace these functions?