[StephanTLavavej]

Fixes #1250.

I'm the primary maintainer of MSVC's C++ Standard Library. We build popular open-source projects, including cryptopp, with development builds of our toolset in order to find and fix regressions in the compiler and libraries before they can ship and cause trouble for you. This also allows us to provide advance notice of breaking changes, which is the case here.

Long ago, we used to emit incredibly obnoxious warnings about using raw pointers as output iterators, which could be avoided by using our non-Standard stdext::checked_array_iterator or stdext::unchecked_array_iterator. Those warnings were removed in VS 2017 15.8, released in August 2018.

Later, we deprecated these stdext iterators for C++17 and later in VS 2022 17.8 in November 2023, as reported by #1250. We then strengthened the deprecation to be unconditional (i.e. also C++14 mode) in VS 2022 17.11 in August 2024.

They're still present (and deprecated) in the MSVC Build Tools 14.50 which will be shipping in VS 2026 18.0. However, I've completely removed them in the MSVC Build Tools 14.51 (with microsoft/STL#5817), which will ship in a future update to VS 2026 18.x.

Now that the stdext iterators are no longer needed to avoid obnoxious warnings, their usage can simply be removed, calling Standard algorithms with raw pointers directly.

I also took this opportunity to remove a strange-looking call to stdext::unchecked_mismatch that appeared to be used for only certain old versions of MSVC, although I don't understand what was happening there (I've worked on the STL since 2007 and I've never seen such an algorithm in the stdext namespace). In any event, calling Standard mismatch is the right thing to do.

[irwir]

According to the crypto++ site, the current version 8.9.0 could be built with Visual Studio 2003 - 2022.
The issue #1250 makes references to much older #123 and #496.
Building with Visual C 6.0 is not supported now, but VS 2005 still is allowed and might need those stdext workarounds.
Therefore, the suggestion is to keep conditional compilation blocks, only add upper limit for the version. For example:
integer.cpp

#if (CRYPTOPP_MSC_VERSION >= 1500) && (CRYPTOPP_MSC_VERSION < 1938)
		std::reverse_copy(encodedInteger, encodedInteger+byteCount,
			stdext::make_checked_array_iterator(block.begin(), block.size()));
#else
		std::reverse_copy(encodedInteger, encodedInteger+byteCount, block.begin());
#endif

zdeflate.cpp

#if defined(_STDEXT_BEGIN) && !(defined(CRYPTOPP_MSC_VERSION) && (CRYPTOPP_MSC_VERSION < 1400 || CRYPTOPP_MSC_VERSION >= 1600)) && !defined(_STLPORT_VERSION)
				stdext::unchecked_mismatch
#else
				std::mismatch
#endif
#if (CRYPTOPP_MSC_VERSION >= 1600) && (CRYPTOPP_MSC_VERSION < 1938)
				(stdext::make_unchecked_array_iterator(scan)+3, stdext::make_unchecked_array_iterator(scanEnd), stdext::make_unchecked_array_iterator(match)+3).first - stdext::make_unchecked_array_iterator(scan));
#else
				(scan+3, scanEnd, match+3).first - scan);
#endif

This code compiles quietly in the current VS 2022 17.14.19.

[StephanTLavavej]

Sure, an upper limit to the MSVC version would be entirely reasonable.

[weidai11]

Thanks for the PR, Stephan. Since you agree with irwir's proposal to add an upper limit to the MSVC version, could you please go ahead and update this pull request with those changes?

[StephanTLavavej]

Pushed. I've retained my unconditional use of std::mismatch because I cannot possibly believe that stdext::unchecked_mismatch existed in my product without me knowing. (std::mismatch is obviously always available, and giving it my unchecked_array_iterators always avoided the "deprecation" warnings, so this will compile cleanly even in those old versions.)