Possible Duplicate:
What is the difference between using a struct with two fields and a pair?
Dear all,
I have a little question about pairs and struct. Is there any advantage to use a std::pair instead of a struct with two cells ? I have used pairs for a while but the main problem is readability : If you want to represent for example a duple (int "label", double "value") you can use either a :
typedef std::pair<int,double> myElem;
or a
typedef struct {
int label;
double value;
} myElem;
The code becomes more readable if your statements have a "semantic" sense (you will always know what x.label is. that's not the case with x.first).
However, I guess there is an advantage using pair. Is it more performant or something else?
In terms of performance: it's unlikely to change anything, you're just sugar coating it.
In terms of usability, I would rather use a custom struct, which can be declared this way (by the way):
struct MyElement
{
int label;
double value;
};
I am a strong proponent of strong typing, and I much prefer a "real" structure (and better yet, class) than an ad-hoc tuple whenever it's more than a fleeting thing.
Mainly because:
first
and second
don't carry much meaningstd::pair
std::pair
All in all, I really think that maintenance benefits from using a custom dedicated structure that a one-size-fits-them-all tuple.
A pair
is implemented as a templated struct
. It provides you with a shorthand for creating a (typically heterogenous) pair. Also, there are some constraints on the types that you can use with a pair
:
Type requirements
T1 and T2 must both be models of Assignable. Additional operations have additional requirements. Pair's default constructor may only be used if both T1 and T2 are DefaultConstructible, operator== may only be used if both T1 and T2 are EqualityComparable, and operator< may only be used if both T1 and T2 are LessThanComparable.
(from SGI STL std::pair
documentation)
Defining your own POD may make sense if the types do not follow any of these constraints or if you do not care about them.
Finally, I guess it is a matter of personal choice/coding style.
Its primary advantage is that it's generic. For example, when you retrieve something from an std::map
, you get the key and the associated value as the first and second items in an std::pair
.
Likewise, when you use std::equal_range
to find a set of equal values in a collection, you get iterators to the beginning and end of the range as the first and second items in an std::pair
.
It's hard to imagine meaningful labels that would apply to both of these, so they settled for a couple that don't mean very much, but at least aren't misleading. Using 'key' and 'data' would work for std::map
, but be misleading for std::equal_range
(and if you switched to something like lower_bound
and upper_bound
to make them more meaningful for std::equal_range
, it'd be equally wrong for items in std::map
).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With