make_pair(T1, T2) in <utility>

[subramanian100in]

Given two types T1 and T2, we can create

pair<T1, T2> p(value1, value2);
where value1 and value2 are of types T1 and T2 respectively.

Suppose we want to assign a new pair<> value to p. We can do it as
p = pair<T1, T2>(value3, value4);
where value3 and value4 are of types T1 and T2 respectively.

The last statement can also be written as
p = make_pair(value3, value4);

My doubt is that, when we can do it with pair<T1, T2>(value3, value4)
itself, what is the need for providing make_pair(value3, value4);

That is, make_pair is considered as an alternative to pair<T1,
T2>(T1_val, T2_val).

Why is make_pair provided in the library ? I am unable to understand
the reason.

Kindly clarify.

Thanks
V.Subramanian

 

[gnuyuva]

Why is make_pair provided in the library ? I am unable to understand
the reason.

Just to make the construct elegant.

consider
struct my_long_struct_1 {};
struct my_long_struct_2 {};

so its quite difficult (irritating) to write these struct names each
time you make a
new pair. So, make_pair solution is elegant.

template <typename T1, typename T2> makepair(T1& v1, T2& v2)
{ return std:air<T1, T2>(v1, v2); }

It deciphers T1, T2 for you which is so nice. But watchout for stuff
related to
inheritance.

struct A {};
struct B {};
struct C : public A {};

std:air<A, B> p_ab;
C c1; B b1;
p_ab = std::make_pair(c1, b1); // this is not elegant, and intelligent
though.
Ofcourse, the above statement is not common, but just in case.

 

[Ian Collins]

Given two types T1 and T2, we can create

pair<T1, T2> p(value1, value2);
where value1 and value2 are of types T1 and T2 respectively.

Suppose we want to assign a new pair<> value to p. We can do it as
p = pair<T1, T2>(value3, value4);
where value3 and value4 are of types T1 and T2 respectively.

The last statement can also be written as
p = make_pair(value3, value4);

My doubt is that, when we can do it with pair<T1, T2>(value3, value4)
itself, what is the need for providing make_pair(value3, value4);

The answer to your question (it is a question, not a doubt) is parameter
matching. The compiler can deduce the types for a function template,
but not for a class template constructor.

 

[kwikius]

Given two types T1 and T2, we can create

pair<T1, T2> p(value1, value2);
where value1 and value2 are of types T1 and T2 respectively.

Suppose we want to assign a new pair<> value to p. We can do it as
p = pair<T1, T2>(value3, value4);
where value3 and value4 are of types T1 and T2 respectively.

The last statement can also be written as
p = make_pair(value3, value4);

My doubt is that, when we can do it with pair<T1, T2>(value3, value4)
itself, what is the need for providing make_pair(value3, value4);

That is, make_pair is considered as an alternative to pair<T1,
T2>(T1_val, T2_val).

Why is make_pair provided in the library ? I am unable to understand
the reason.

Kindly clarify.

This is essentially a workaround for the fact that you cant construct a
templated type without explicitly stating the template parameters.

Say you have a function that takes a tuple ( to extend the issue with pair)
argument

template < typename T1, typename T2, typename T3, typename T4 typename T5>
void fun(tuple<T1,T2,T3,T4,T5> const & seq);

invoking the function can be tedious if you need to construct a temporary
tuple as you have to each template parameter.

fun(
tuple<my::type1,your::t2,std::vector<my::type1>,your::t4,her::t5>(v1,v2,v3,v4,v5)
);

However a template function can deduce its arguments, so by providing
overloaded make_tuple functions the programmers life is made easier and you
don't need to be explicit for the types of v1.. v5 etc, which the compiler
knows already

fun(make_tuple(v1,v2,v3,v4,v5) );

make_pair is exactly the same.

Incidentally it would be interesting to come up with a mechanism where
certain types could be constructed without specifying the parameters, though
using a function does work it means having to write a separate function, so
it would be interesting to see if there is a way to automate it.

regards
Andy Little