4 ms·

Most features are very good. My favorite ones are range-based loops, lambdas, and strongly-typed enums. The things I dislike most are pairs and tuples. They ma

Most features are very good. My favorite ones are range-based loops, lambdas, and strongly-typed enums. The things I dislike most are pairs and tuples. They make the code enormously harder to read, understand and debug, compared to non-standard classes or structures with meaningful member names. Even this guide promotes them in “using Coordinate = std::pair<int, int>;” Please, never do that, create your own class with x/y or latitude/longitude instead.

jstimpfle 10y ago
Sometimes all the meaning is in the name of a thing (or in the name of a function returning such a thing) and member names dont help but hurt. x/y is a good example, why not a/b? I prefer not having to make these decisions. Also tuple assignment syntax is very nice from a usability standpoint (I don't think C++ has it, but e.g. Python has).
- lorenzhs 10y ago
  C++17 adds tuple unpacking under the name "structured bindings" auto [a, b] = function_returning_pair(); Of course, tuple unpacking was already possible before if the variables were already declared: int a, b; std::tie(a, b) = function_returning_pair();
- Const-me 10y ago
  Maybe sometimes, but not this time. The author named their pair "Coordinate". In math and in computer graphics there’s widely known convention the fields of Cartesian coordinates are named x/y and not a/b. When you’ll start writing code that use and/or modify those Coordinate values, meaningful names in C++ source and in the debugger help a lot.
lorenzhs 10y ago
Sometimes "using Coordinate = std::pair<int, int>;" does have upsides, though. One example would be when using a serialisation library that knows how to handle pairs. In that case you don't have to add (de-)serialisation code to every new class. It's also nice to be able to use std::tie for unpacking: "std::tie(x, y) = get_coords(blah);" If you use the members a lot, a struct with named members really is much easier to read, though.

jstimpfle 10y ago

Sometimes all the meaning is in the name of a thing (or in the name of a function returning such a thing) and member names dont help but hurt. x/y is a good example, why not a/b? I prefer not having to make these decisions. Also tuple assignment syntax is very nice from a usability standpoint (I don't think C++ has it, but e.g. Python has).

lorenzhs 10y ago
C++17 adds tuple unpacking under the name "structured bindings" auto [a, b] = function_returning_pair(); Of course, tuple unpacking was already possible before if the variables were already declared: int a, b; std::tie(a, b) = function_returning_pair();
Const-me 10y ago
Maybe sometimes, but not this time. The author named their pair "Coordinate". In math and in computer graphics there’s widely known convention the fields of Cartesian coordinates are named x/y and not a/b. When you’ll start writing code that use and/or modify those Coordinate values, meaningful names in C++ source and in the debugger help a lot.

lorenzhs 10y ago

Sometimes "using Coordinate = std::pair<int, int>;" does have upsides, though. One example would be when using a serialisation library that knows how to handle pairs. In that case you don't have to add (de-)serialisation code to every new class. It's also nice to be able to use std::tie for unpacking: "std::tie(x, y) = get_coords(blah);" If you use the members a lot, a struct with named members really is much easier to read, though.