Let’s start with some standardese:
Picture 1. N4606As you can see, the alternative tokens are defined to behave exactly the same as their counterparts. So the following code is perfectly well-defined and legit, despite the opinion of your fellow reviewer
A few weeks ago Gynvael Coldwind announced a contest (I’m sorry, the link is in Polish) related to his excellent OS dev streams (again, in Polish, but if you do understand it, definitely consider watching them). The task was simple: make a BIOS-bootable diskette image with the prettiest graphical effect; all in 16-bit text mode, with binary size limit of 512 bytes.
I was investigating a crash in my application recently. Despite working in the production environment, I was able to launch the debug version in a debugger (yay). Soon enough, I got a promising SIGSEGV in the expression implementing the erase-remove idiom:
vec.erase(std::remove_if(vec.begin(), vec.end(), [&orig](auto const& msg){ return orig.id == msg.id; })); |
Can you spot the bug already?
Hello, everyone. It has been a while since my last post.
While watching CppCon 2014 I found this little gem being described by Scott Meyers.
Consider the following code:
decltype(auto) foo() { static int Foo; return Foo; } decltype(auto) bar() { static int Bar; return (Bar); } int main() { decltype(auto) a = foo(); decltype(auto) b = bar(); a++; b++; cout << foo() << ", " << bar() << endl; } |
Would you expect this to print 0, 0? Well, not so fast. decltype(auto) is just a nicer syntax for decltype(name), where name is “unparenthesized id-expression or an unparenthesized class member access”, as described here. Therefore it follows the same rules.
That’s another corner case to remember, but I guess it could also make a nifty party trick, if one can find the right party.
According to grammar rules defined by the C++ standard (and C as well) the following code is valid:
switch(i) i++; |