It's an educational problem, Chandler Caruth of LLVM gave a really good talk on POD type slicing and how useful it can be. More to the point that for PODs it's supported in the standard. I do agree on the abuse of pair... pair is there for implementers primarily and shouldn't be used outside of deliberately templated code. Ditto tuple.
That said... with C++17 destructuring... it's a lot less painful since you can do the equivalent to a std::tie in a single line.
What was the title of the talk?
Re:Code Smells: Iteration
by throwaway613834 on Wednesday August 23, 2017 @03:04PM
(#15084192)
One problem in C++ is if you define a struct then you have to define a bunch of operators yourself (operator<, etc.) which gets annoying after you've realized you've needed them a bunch of times.
Re:Code Smells: Iteration
by marcosdumay on Wednesday August 23, 2017 @04:13PM
(#15084638)
Does C++ Pair<> define operator< and operator>?
That's surprising, and for me looks completely uncalled for.
EDIT: Just looked into Haskell (because it's easier), and tuples do derive Ord there. Is there some universal convention I'm missing?
Re:Code Smells: Iteration
by throwaway613834 on Wednesday August 23, 2017 @05:34PM
(#15085394)
> Is there some universal convention I'm missing?
Tuples are always compared lexicographically, is the universal convention. Not sure if that's what you might be missing?
> Does C++ Pair<> define operator< and operator>?
It does.
std::sort(pairarray.begin(),pairarray.end()) works about how you'd expect, as long as operator< is defined for the constituent types of the pair.
In C++ we see quite a bit of abuse of std::pair<> instead of just making a fucking struct to hold 2 properly named, easy to read pieces of useful data. Nope! Apparently calling all your data members "first" and "second" is better to some people.
I don't know if it's an educational problem, a language issue, or something else, but I see it so frequently that there must be some common underlying cause (or set of causes).