[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] Don't help the compiler!
From:       Nicola Gigante <nicola.gigante () gmail ! com>
Date:       2015-01-26 15:41:26
Message-ID: C9B33A6E-7664-4D10-84D8-628B7585B513 () gmail ! com
[Download RAW message or body]


Hi.

> Il giorno 26/gen/2015, alle ore 10:15, David Chisnall <David.Chisnall@cl.cam.ac.uk> \
> ha scritto: 
> The latter form seems less readable.  The fact that a floating point literal is a \
> double unless suffixed with f is something that is rarely important for developers \
> to remember, so this extra piece of information increases the cognitive burden when \
> reading the code. 
> The goal of the former form is not to 'help the compiler', it is to help the poor \
> sap who has to maintain this code in a couple of years. 

While this might be true, the point of std::make_pair is to deduce the type of the \
arguments. If one wants to explicitly specify the types, he can simply do:

auto p = std::pair<int,double>(42, 3.14);

or

std::pair<int,double> p{42, 3.14};

which are also a few less keystrokes. It doesn't need make_pair, which is perfectly \
redundant if you don't want it to deduce the types.

Also in general, explicitly specifying the types of arguments of a template function \
which is designed with deduction in mind, seems to me bad practice, because it's \
fragile if one change the arguments but not the types of vice-versa, and could break \
or slowdown things when perfect-forwarding comes in the mix.

This example exacerbates the issue:
auto p = std::make_unique<T, ArgT1, ArgT2, ArgT3>(arg1, arg2, arg3); // Please don't.

So IMHO a check to tell the inexperienced user about this redundancy is very helpful.

> David


Bye,
Nicola
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


[prev in list] [next in list] [prev in thread] [next in thread]