question on pair in <utility>

[subramanian100in]

Suppose left and right are two pair<T1, T2objects.

Then
'left < right'
returns
left.first < right.first || !(right.first < left.first) && left.second
< right.second.

Suppose left.first is NOT less than right.first.

Then isn't the subexpression '!(right.first < left.first)' equivalent
to 'left.first == right.first' ?

Is there any reason for mentioning like '!(right.first < left.first)'
instead of
'left.first == right.first' ?

Kindly clarify.

Thanks
V.Subramanian

[Jeff Schwab]

su**************@yahoo.com, India wrote:

Suppose left and right are two pair<T1, T2objects.

Then
'left < right'
returns
left.first < right.first || !(right.first < left.first) && left.second
< right.second.

Suppose left.first is NOT less than right.first.

Then isn't the subexpression '!(right.first < left.first)' equivalent
to 'left.first == right.first' ?

Is there any reason for mentioning like '!(right.first < left.first)'
instead of
'left.first == right.first' ?

operator< is generally the first operator defined for a given type,
since the standard containers and algorithms default to std::less.
operator==(a, b) is then defined as !(a < b) && !(b < a). Using
operator< in the first place will therefore tend to be a little more
efficient.

[Jeff Schwab]

James Kanze wrote:

On Feb 4, 5:45 am, Jeff Schwab <[e-mail]:

>[e-mail], India wrote:

>>Suppose left and right are two pair<T1, T2objects.

>>Then
'left < right'
returns
left.first < right.first || !(right.first < left.first) && left.second
< right.second.

>>Suppose left.first is NOT less than right.first.

>>Then isn't the subexpression '!(right.first < left.first)' equivalent
to 'left.first == right.first' ?

Not if one of the types involved doesn't define an operator==.

>>Is there any reason for mentioning like '!(right.first < left.first)'
instead of
'left.first == right.first' ?

>operator< is generally the first operator defined for a given
type, since the standard containers and algorithms default to
std::less. operator==(a, b) is then defined as !(a < b) &&
!(b < a). Using operator< in the first place will therefore
tend to be a little more efficient.

For many types, an operator== can be implemented at far less
runtime cost than an operator<.

I didn't say it couldn't be, just that it often isn't. operator== can
be defined in terms of operator<, but the reverse is not true; so, if
you need both, you either have to define operator== in terms of
operator<, or you have to implement them both manually and be careful to
keep them in sync. While the (typically) constant-factor speed-up
*might* be worth the increased risk of bugs, I would certainly wait for
a profiler to tell me so.