You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR resolves compilation errors in pre-C++11 compilers (such as VC6) caused by the >> token sequence in nested template declarations.
Instead of restructuring the code with typedefs, the issue is addressed by safely separating the consecutive closing angle brackets with an empty comment: >/* */>. This prevents the compiler from misinterpreting the sequence as a right-shift operator while preserving the original code structure and type definitions intact.
Key Details:
Scope: A total of 68 instances of nested templates (found by searching for > >) were updated using this pattern.
Edge Cases & Comments: Nested templates located within code comments were intentionally left unchanged.
This PR applies a mechanical refactoring across 48 files to replace the pre-existing > > whitespace separator in nested template declarations with an empty C-style comment >/**/>, targeting pre-C++11 compiler compatibility (specifically VC6, which could misparse >> as the right-shift operator).
68 instances updated consistently across typedef declarations, class base specifiers, using declarations, and function return types in both the Generals and GeneralsMD codebases.
The approach is syntactically valid: a block comment between the two closing angle brackets is sufficient to prevent the tokenizer from interpreting them as >>. This is an established alternative to the > > whitespace workaround already present in the original code.
Confidence Score: 5/5
Safe to merge — all 68 changes are mechanical token-level substitutions with no runtime behavior impact.
Every change replaces an existing > > whitespace separator with an equivalent >/**/> empty-comment separator inside template angle brackets. Neither form affects generated code; both prevent the >> right-shift ambiguity in pre-C++11 compilers. The transformation is applied consistently across the entire codebase and introduces no new logic, types, or dependencies.
No files require special attention. The changes in AudioEvents.h touch using declarations where the original > >:: pattern was already unambiguous, but the substitution is still syntactically correct and harmless.
Does clang-format preserve the space when the clang format language is set to c++98 ? Or will this cause other issues then (such as failing to recognize constexpr, override, etc)?
xezon
changed the title
refactor: Fix pre-C++11 nested template parsing
chore: Prevent conflict between clang-format and pre-C++11 nested template parsing
Jun 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RefactorEdits the code with insignificant behavior changes, is never user facing
3 participants
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 PR resolves compilation errors in pre-C++11 compilers (such as VC6) caused by the
>>token sequence in nested template declarations.Instead of restructuring the code with
typedefs, the issue is addressed by safely separating the consecutive closing angle brackets with an empty comment:>/* */>. This prevents the compiler from misinterpreting the sequence as a right-shift operator while preserving the original code structure and type definitions intact.Key Details:
> >) were updated using this pattern.