Thanks for the video. I implemented GCC's field-suggestion feature, I meant it for handling misspellings. Clearly we shouldn't be offering *these* fields as suggestions. I've filed this bug as gcc.gnu.org/bugzilla/show_bug.cgi?id=85515 and am working on a fix.
I believe, if you wrote __for_begin = std::prev(__for_end);, it would work. Your attempt failed because of another "++__for_begin" statement at the end of iteration, which caused __for_begin to go past __for_end, and made the "__for_begin != __for_end" condition to start failing forever.
Both if your examples are infinite loops because, in both of them, you are skipping the end iterator, so the loops keeps iterating. Basically you jumped over the flag pole. I think what you meant to do was: __for_begin = __for_end - 1 That way, when the for loop increments the iterator, it will increment to be equal to __for_end and quit with a sum of 1. Similarly, since you have an odd number of values, if you increment by 2, you will skip the end, which is [5] and you are in the same boat. For that one, add a 6th element and it will sum every other value. I might make a macro that enables deletion and insertion in for range loops by manipulating __for_begin. Thanks for this.
I know of another leaky abstraction around lambdas: lambdas without captures can be converted to function pointers. GCC implements this by calling the lambda's operator() with this == nullptr. However, if you use GCC 6 (it's been fixed later) and turn off -fsanitize=undefined, it complains about this being null (which is UB), *even in this case where it's GCC's code*. That's been fixed later, but I was confused for a while about why this was undefined.
Why are the members coming from capture (or whatever the proper term is) public? And could the solution be as simple as generating private members for them? How does Clang and MSVC do it?
Doesn't matter, you still can use tricks to access private class members without modifying the original class. If you are accessing that field you are kind of doing it on purpose. Not sure why you would worry about that.
Nerd Nazis worry about everything man. Check out all the party poopers in the comments crying about the idea of using these leaks. Like the compiler is gonna change and go “gotcha” and delete your hard drive one day. If you are gonna do wacky and fun stuff like this. Just write a unit tester that complains if you upgrade to a compiler in which these tricks stop working. These are the type of people that tell the teacher when they forgot to assign homework.
In case you are interested in some ideas for videos: I think -fno-strict-aliasing / aliasing rule would be very interesting. Or other "fun" flags that can give you a terrible time such as "-fshort-enums" in gcc
Jason: it is very important that you see cppinsights.io/ There you will see what the compiler really is doing. This can explain all problems you are talking about here. Remember also that variables starting with double underline are reserved to the language.
The range based for seems to be handled in [gcc-master\gcc\cp\parser.c] line 11915 I'd say the ranged syntax gets straight replaced by it's proper c++ equivalent before compilation? We could check the preprocessed source to see if it is. Also, it'd be fun to check other compilers source to see if they are doing the same and what names are giving to the iterators to see if those leak too. ^_^
von nobody Define valid code. As it isn't in the standard, I wouldn't be comfortable calling this valid, but if you are coding specifically for GCC (and on a fixed version, seeing as they can modify behaviour in later versions) then I guess you can get away with it - it certainly isn't unheard of for people to abuse compiler specific behaviours for in-house, limited-scope applications.
My question was different, image you try write valid program that follow standard (do not use names and macros like `__foo`, getting address of std function, etc.) and is possible to do write it in that way that you will see difference caused by this leak? Example could be if you define variable `__for_begin` outside of loop and try alter in inside, but this is not allowed because of naming convention.
Honestly I'd be real skeptical of any programmer who did this sorta thing. It's one of those cute obscure tricks being used for no reason aside from being cute and obscure. It's easy enough to do pointer manipulation in C++ as it is using a generic for loop, so the for loop example is easy enough, and having alterable lambda variables is trivial with the use of pointers and references.
Too many leaks: you sink. This is scary but fascinating. The standard does not mention anything on 'leaky' implementations for these C++ standard syntatic contructs and their defined semantics.
The standard does say that identifiers beginning with a double underscore are reserved. This is, to the best of my knowledge, all perfectly legal. GCC could also create an __do_not_set flag, and if your code ever runs __do_not_set = true, it formats your hard drive. This would be a bad idea but would be allowed by the C++ standard.
Correct. But the C++ standard does not adjudicate on the issue of the visibility of these implementation constructs: client code can access these 'public' variables and in so doing can alter the semantics of standard language features such as the for range as exemplified in the above video. The least that can be said is that it is not portable C++ code.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Thanks for the video.
I implemented GCC's field-suggestion feature, I meant it for handling misspellings. Clearly we shouldn't be offering *these* fields as suggestions.
I've filed this bug as gcc.gnu.org/bugzilla/show_bug.cgi?id=85515 and am working on a fix.
Dave Malcolm Haha leave it like this its cool :))
Thanks for the feature btw - it's really useful.
I believe, if you wrote __for_begin = std::prev(__for_end);, it would work.
Your attempt failed because of another "++__for_begin" statement at the end of iteration, which caused __for_begin to go past __for_end, and made the "__for_begin != __for_end" condition to start failing forever.
Both if your examples are infinite loops because, in both of them, you are skipping the end iterator, so the loops keeps iterating. Basically you jumped over the flag pole. I think what you meant to do was:
__for_begin = __for_end - 1
That way, when the for loop increments the iterator, it will increment to be equal to __for_end and quit with a sum of 1.
Similarly, since you have an odd number of values, if you increment by 2, you will skip the end, which is [5] and you are in the same boat. For that one, add a 6th element and it will sum every other value.
I might make a macro that enables deletion and insertion in for range loops by manipulating __for_begin. Thanks for this.
Odd number of elements starting from 5 cause the infinite loop.
gcc 8.2 is the latest compiler that has this leaky abstractions for interested people :)
Not really. Compiler doesn't suggest you that __val exists, however you can still access it even on GCC 12 or trunk.
I know of another leaky abstraction around lambdas: lambdas without captures can be converted to function pointers. GCC implements this by calling the lambda's operator() with this == nullptr. However, if you use GCC 6 (it's been fixed later) and turn off -fsanitize=undefined, it complains about this being null (which is UB), *even in this case where it's GCC's code*. That's been fixed later, but I was confused for a while about why this was undefined.
Why are the members coming from capture (or whatever the proper term is) public? And could the solution be as simple as generating private members for them? How does Clang and MSVC do it?
Doesn't matter, you still can use tricks to access private class members without modifying the original class.
If you are accessing that field you are kind of doing it on purpose. Not sure why you would worry about that.
Nerd Nazis worry about everything man. Check out all the party poopers in the comments crying about the idea of using these leaks. Like the compiler is gonna change and go “gotcha” and delete your hard drive one day. If you are gonna do wacky and fun stuff like this. Just write a unit tester that complains if you upgrade to a compiler in which these tricks stop working. These are the type of people that tell the teacher when they forgot to assign homework.
In case you are interested in some ideas for videos: I think -fno-strict-aliasing / aliasing rule would be very interesting. Or other "fun" flags that can give you a terrible time such as "-fshort-enums" in gcc
That sounds like a great video!
Oh boy strict aliasing is a fun one
Jason: it is very important that you see cppinsights.io/
There you will see what the compiler really is doing. This can explain all problems you are talking about here.
Remember also that variables starting with double underline are reserved to the language.
Very cool - thanks for the link.
The range based for seems to be handled in [gcc-master\gcc\cp\parser.c] line 11915
I'd say the ranged syntax gets straight replaced by it's proper c++ equivalent before compilation? We could check the preprocessed source to see if it is. Also, it'd be fun to check other compilers source to see if they are doing the same and what names are giving to the iterators to see if those leak too. ^_^
Here's a Compiler Explorer link with an early parsed tree version of the code: godbolt.org/g/mfG3WC
clang seems to be generating something of the sorts, but it doesn't seem to leak into your own code
(clang.exe -cc1 -ast-dump):
-DeclStmt 0x26744a0
| | `-VarDecl 0x2674258 col:23 implicit used __end 'int *':'int *' cinit
| | `-BinaryOperator 0x26743e8 'int *' '+'
| | |-ImplicitCastExpr 0x26743d0 'int *'
| | | `-DeclRefExpr 0x26741b0 'int [6]' lvalue Var 0x2673f68 '__range' 'int (&&)[6]'
| | `-IntegerLiteral 0x26743a8 'long long' 6
| |-BinaryOperator 0x2674538 'bool' '!='
| | |-ImplicitCastExpr 0x2674508 'int *':'int *'
| | | `-DeclRefExpr 0x26744b8 'int *':'int *' lvalue Var 0x26741e8 '__begin' 'int *':'int *'
| | `-ImplicitCastExpr 0x2674520 'int *':'int *'
| | `-DeclRefExpr 0x26744e0 'int *':'int *' lvalue Var 0x2674258 '__end' 'int *':'int *'
| |-UnaryOperator 0x2674588 'int *':'int *' lvalue prefix '++'
| | `-DeclRefExpr 0x2674560 'int *':'int *' lvalue Var 0x26741e8 '__begin' 'int *':'int *'
| |-DeclStmt 0x2673f18
| | `-VarDecl 0x2673eb8 col:21 used v 'const int':'const int' cinit
| | `-ImplicitCastExpr 0x2674688 'int'
| | `-UnaryOperator 0x26745e8 'int' lvalue prefix '*'
| | `-ImplicitCastExpr 0x26745d0 'int *':'int *'
| | `-DeclRefExpr 0x26745a8 'int *':'int *' lvalue Var 0x26741e8 '__begin' 'int *':'int *'
| `-CompoundStmt 0x26747d8
| `-CompoundAssignOperator 0x26747a0 'int' lvalue '+=' ComputeLHSTy='int'
Anything user code involving assignments to variables whose names containing "__" is active marauding. Leaking has nothing to do with it.
You are confused.
Sounds like you could really bork stuff up hard with these hacks!
This guy is insane.
Great catch :D only question is could you encounter this in any valid code?
von nobody Define valid code. As it isn't in the standard, I wouldn't be comfortable calling this valid, but if you are coding specifically for GCC (and on a fixed version, seeing as they can modify behaviour in later versions) then I guess you can get away with it - it certainly isn't unheard of for people to abuse compiler specific behaviours for in-house, limited-scope applications.
My question was different, image you try write valid program that follow standard (do not use names and macros like `__foo`, getting address of std function, etc.) and is possible to do write it in that way that you will see difference caused by this leak? Example could be if you define variable `__for_begin` outside of loop and try alter in inside, but this is not allowed because of naming convention.
Honestly I'd be real skeptical of any programmer who did this sorta thing. It's one of those cute obscure tricks being used for no reason aside from being cute and obscure. It's easy enough to do pointer manipulation in C++ as it is using a generic for loop, so the for loop example is easy enough, and having alterable lambda variables is trivial with the use of pointers and references.
Cool!
I hope lambda have capture by constant reference.
Yeah its called capture a const object by reference.
Type it into here: cppinsights.io There should be a way to dump out this content via compiler flag.
Fixed here, gcc.gnu.org/bugzilla/show_bug.cgi?id=85515
As of this reply, the error message was fixed. However, if you type l.__val, the code still compiles.
Feels like I never learned c++
That means you are not a real programmer. Most aren’t. Start now. C++ is the only true language besides assembly.
Too many leaks: you sink. This is scary but fascinating. The standard does not mention anything on 'leaky' implementations for these C++ standard syntatic contructs and their defined semantics.
The standard does say that identifiers beginning with a double underscore are reserved. This is, to the best of my knowledge, all perfectly legal. GCC could also create an __do_not_set flag, and if your code ever runs __do_not_set = true, it formats your hard drive.
This would be a bad idea but would be allowed by the C++ standard.
Correct. But the C++ standard does not adjudicate on the issue of the visibility of these implementation constructs: client code can access these 'public' variables and in so doing can alter the semantics of standard language features such as the for range as exemplified in the above video. The least that can be said is that it is not portable C++ code.