Discussion
Fucked C++ question:
I have a struct B, defined by me. I had the code
auto &b = bees.emplace_back(); //vector
b.value = 3;
A change *ELSEWHERE IN THE CODE* caused this to suddenly start failing with
"auto cannot be inferred"
changed the line to
B &b = bees.emplace_back();
The error became ("bees" underlined):
"initial value of reference to non-const must be an lvalue" (??)
Replaced the whole thing with
B b;
b.value = e;
bees.push_back(b);
The compiler allows this.
C++17.
wha ??? ?? ?????
@mcc this smells like a reference constness issue in a temporary, but it's hard to diagnose without seeing the full code.
@nyanpasu64 the error was more bizarre than we could have expected
We had a std::pair<X, Y>
It turned out there were two identical definitions of struct Y in the codebase, one commented with // TODO: Can we remove this?
It was a very straightforward error complicated only by C++ turning it into a hundred like template error with many red herrings
@mcc Not at all sure but it sounds a bit like you clobbered the name resolution of `bees`, similar to what happens when you write `get<string>(myVariant)` in a member function (intending for it to be resolved to `std::get` via `using namespace std`) and then later add a member function called `get` to that same class
Or the incomprehensible errors you get if Windows' `near`/`far` macros clobber anything unexpected
@AminiAllight no, this is a typo in my post. The class is not named B and the vector is not named bees. I have edited the post to be more correct.
@mcc Oh sorry, I didn't mean the inconsistent symbols in the post, I assumed those were a typo already
I was suggesting that your distant code change somehow altered how the real name of `bees` (whatever it may be) was resolved by the compiler such that it pointed to something other than what you intended
@mcc a change to B making it no longer MoveInsertable / EmplaceConstructible ?
@porglezomp Very interesting.
Do you believe my push_back implementation will have move semantics, or do you believe I have just created a copy?
@mcc I’m not confident about when copies happen in C++, I’m so frustrated that there is very little way to tell the difference, since moves silently become copies if anything is slightly odd.
My suggestion is really just from long ago experience with the types of spooky action at a distance, and looking at the cppreference documentation of emplace_back to see what requirements it imposed on the types.
We are seeing at least three cases where what looks like a totally normal emplace() or emplace_back() call is failing, in code which previously worked, with baffling errors. One place is claiming that std::pair does not have any constructors that take two arguments.
???????
(before you ask "did you #include <utility>": yes I did)