A lot of things suck (closures, generator functions, first order functions all suck in c++), but oh my does it all run fast when you get it working; plus wrapping it with Rcpp or Lua is easy as pie.
Take this snippet of an API call[1] that parses ISO strings to chrono::time_point using date[2]:
std::istringstream in(iso_string);
in >> date::parse("%FT%TZ", tp);
The function is constructing a temporary object and reading into that object. The object includes a reference to a named tp object, and the temporary parser object is parsing from the input stream, which writes the data into the tp object.
> but... I still don't understand all of the technical reasons behind that decision.
Because he wants to support input from an istream, and inputting from a istream necessarily means overloading '>>'. That's just how things are done in C++; if you want to support reading from or writing to an istream/ostream, you overload the '>>' and '<<' operators.
It's a trade off; he could have designed it so that the constructor of tp simply accepts the format string and the istream as parameters. But that has the downside of not looking like idiomatic istream code.
I personally think that the way iostreams are implemented in C++ was a mistake. (because I don't like the way idiomatic istream looks, and I think friend functions are generally smelly.) Unfortunately, it's something like 35 years too late to correct it. (I'm aware that C++ is only 33 years old; iostream.h and cout << "blah" << endl; and cin >> foo; preexist C++) But here's the thing: it's badly designed iostreams that make the linked code confusing, not operator overloading.
I never grasped the hate iostreams get, as they are type safe and composable in ways that FILE will never be.
Sure they might be a couple of ms slower than stdio calls, but unless I would be writing a HPC trading application communicating over stdio, I hardly see the relevance.
And for the operators, oh well, as long as they are consistent.
Then again, it might just be my biased background as I got introduced to them.
a.) It was not a const overload. b.) Inside said overload, it modified FOUR member variables. c.) The 'new' keyword was used twice inside said == overload. d.) I learned when gdb fails, to grep the codebase for the 'operator' keyword.
I am not a fan of operator overloading. If the SW enginner in question had instead written a equals(<type> rhs) function, I'd have saved myself a lot of headache.
In the named case, it's obvious the other programmer may be doing something nefarious.
In the operator case, you learn much more, like how to grep, really work gdb, etc.
Same thing. Weird at first every C++ programmer should be familiar with it now.
I pronounce << and >> as 'goes to' and 'comes from' or something similar.
cin >> foo(x); $ cat test.cpp
#include <iostream>
#include <string>
template <typename F>
auto pass_func(F func) {
return func();
}
auto return_func() {
std::string test = "Hello World!";
return [=](){ return test; };
}
int main() {
auto func = return_func();
std::cout << pass_func(func) << std::endl;
}
$ clang test.cpp -lstdc++ -std=c++14 -o test
$ ./test
"Hello World!"