[PATCH] Update the coding standards to provide some guidance for a few constructs in C++11

[Matt P. D.]

Hi Chandler!

Chandler Carruth <chandlerc at ...> writes:

> On Tue, Mar 4, 2014 at 2:25 AM, Matt
<matdzb at gmail.com> wrote:
> Hi!
> Out of curiosity, I'm wondering about the upsides/downsides of following
the Scott Meyers' advice in this context.
> // "Develop the habit of using brace initialization without “=“.
> In: "Overview of the New C++ (C++11)"; http://www.aristeia.com/C++11.html
> In "Uniform Initialization Syntax" he provides an example where the
alternative would fail:
> ```
> const float * pData = new const float[3] = { 1.f, 2.f, 3.f }; // error
> const float * pData = new const float[3] { 1.f, 2.f, 3.f }; // ok
> ```
> 
> 
> 
> The guidelines specifically recommend this type of thing -- here we have
an aggregate being initialized in the only way that makes sense.

> Similarly, another example shows that `T var = expr` syntax can’t call
explicit constructors; adopting from the example (slightly simplifying,
changing `Widget` to `struct`) therein:
> ```struct Widget
> {
>         explicit Widget(int);
> };
> Widget w1(10); // okay, direct init: explicit ctor callable
> Widget w2{10}; // ditto
> Widget w3 = 10; // error! copy init: explicit ctor not callable
> Widget w4 = {10}; // ditto```
> Or, is disallowing the above the actual intent?
> 
> 
> 
> Yes, disallowing this was the intent. If the constructor is 'explicit'
then this is not merely converting one value to another or doing something
like aggregate initialization. It is calling a very specific constructor
explicitly with a specific argument. That's what it says on the tin. I would
like for explicit calls to a specific constructor to look like *calls*
rather than like aggregate initialization, or worse, some strange block
scope. So instead, write 'Widget w1(10);' and everything is fine.


Never got the chance to thank you for the advice given in the guideline--
and have just run into the issue with my own code which has shown that brace
initialization can indeed get tricky.

This has surprised me (even though I've been reading about this dozen+ times
by now, including the discussions involving the proposals to change this
behavior in the new standard):

std::vector<double> v;
// ... later ...
auto w{v}; //  std::initializer_list<std::vector<double>>
// whereas
auto u = v; //  std::vector<double>

So, might as well use this opportunity to say thank you -- and you were right!

Best,

Matt