Cleanups 7: Unnecessary guard around new_handler
#2679
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This removes the (very strange) guard
#if !defined(_INC_NEW) || !defined(_MSC_EXTENSIONS)
around thenew_handler
typedef.It appears that this guard may have been intended to avoid duplicate typedefs because
<new.h>
can include<new>
(weirdly). However, duplicate typedefs have always been possible - if<new>
was included first,!defined(_INC_NEW)
would be true, so<new>
would emitnew_handler
. Then if<new.h>
is included, with the default of/Ze
,#if defined _MSC_EXTENSIONS && !defined _CORECRT_BUILD
would be true, so it would also emitnew_handler
withinnamespace std
. (SeeC:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\new.h
.) There's no conflict as long as the typedefs are identical.With this removal, there is no conflict regardless of inclusion order or
/Za
:This also removes an unnecessary comment (that essentially repeats the type; it's not like the comment alone would teach people how to use this machinery).