-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
<variant>
: visit()
combinatoric catastrophe
#2770
Comments
|
Evaluate as a tree instead of a single enormous pack expansion. Fixes microsoft#2770.
Evaluate as a tree instead of a single enormous pack expansion. Fixes microsoft#2770.
Evaluate as a tree instead of a single enormous pack expansion. Fixes microsoft#2770.
While this argument still seems perfectly reasonable, we have empiric evidence that disagrees. 🤷♂️ |
Reported by @xiangfan-ms:
MSVC accepts this due to the compiler's type trait optimizations, but it still takes a significant amount of time to compile:
Clang rejects this, because
<variant>
massively exceeds the compiler's template limits:This is the code that's responsible:
STL/stl/inc/variant
Lines 1662 to 1675 in 17fde2c
STL/stl/inc/variant
Lines 1502 to 1532 in 17fde2c
As @CaseyCarter explained,
variant<char, int, long, long long>
has 5 possible states (includingvalueless_by_exception
), sovisit
ing 5variant
s will examine 5^5 = 3,125 combinations of argument types.I (@StephanTLavavej 🐱) wonder whether we could use tree-like expansion instead of linear pack expansion to avoid the length limits here. (We'd still be doing the same amount of work, just not with huge type lists.) However, I am uncertain whether the actual visitation would also need to be changed:
STL/stl/inc/variant
Lines 1677 to 1678 in 17fde2c
The text was updated successfully, but these errors were encountered: