I'd just call it a union. Since it's a union of two integers.
Than name of the variables should tell you about what the data means.
The data structure should tell you how it's organized in memory.
Edit: You can also abstract the data type from the union. You can have unions of other types as well so why have 30+ union types. You can also have unions of more then a single pair.
Also I feel that rather then having the data structure represent the meaning, variable-based meaning is the best way to go as it will lead to clearer names.
union_t<int> location_coordinate = {
x = 0;
y = 0;
};
This would be accessed by:
location_coordinate.x; // == x
location_coordinate.y; // == y
Rather then
location_t position = ...;
I personally like longer variable names as it makes it explicitly easy to see exactly how it's expected to behave.
Suppose you have two "add" functions: one for fractions, one for points:
Fraction add(Fraction a, Fraction b)
{
Fraction result;
result.num = a.num * b.denom + b.num * a.denom;
result.denom = a.denom * b.denom;
return result;
}
Point add(Point a, Point b)
{
Point result;
result.x = a.x + b.x;
result.y = a.y + b.y;
return result;
}
How would you write this in C++?
Obviously the code below won't do:
union_t<int> add_fractions(union_t<int> a, union_t<int> b);
union_t<int> add_points(union_t<int> a, union_t<int> b);
Because you now just lost type safety (i.e you can add fractions with points).
To get back strong type safety, you could write:
struct Fraction : public union_t<int> {};
struct Point : public union_t<int> {};
At this point, you're mostly back to square one, except that Fraction users must use members named "x" and "y" ...
(and I'm not even talking about operator overloading)
(By the way, "union" is an unfortunate choice of words, as the language already defines it to mean something completetly different. Maybe "pair" is more appropriate?).
Than name of the variables should tell you about what the data means.
The data structure should tell you how it's organized in memory.
Edit: You can also abstract the data type from the union. You can have unions of other types as well so why have 30+ union types. You can also have unions of more then a single pair.
Also I feel that rather then having the data structure represent the meaning, variable-based meaning is the best way to go as it will lead to clearer names.
This would be accessed by: Rather then I personally like longer variable names as it makes it explicitly easy to see exactly how it's expected to behave.