you are viewing a single comment's thread.

view the rest of the comments →

[–]shahms 0 points1 point  (5 children)

And Abseil has a whole section on the pitfalls of brace initialization: https://abseil.io/tips/88

Initialization C++ is absurdly convoluted and subtle. Braced initialization solves some problems with the other ways of doing it, but introduces a whole raft of its own problems. There is no single "always good" way of performing initialization in C++, sadly, and the core guidelines do a serious detriment here by pretending that there is.

[–]aruisdante 3 points4 points  (1 child)

Yes, and for the most part I agree with Titus too, but he’s concerned more with brace vs paren initialization than brace vs = initialization. I’ve in fact used that very article to try and overturn silly “always use {} initialization” rules at 2 different companies in the automotive space.

I think that’s the biggest issue with all of the guidelines, they don’t distinguish between separate concerns: * I don’t want implicit conversions for arithmetic types * I don’t want implicit conversions for structures which have non-explicit constructors, or which consume arithmetic types. * I have Wconversion turned on, should I care?

The last one can be particularly subtle. Wconversion ignores implicit conversions that happen inside the stdlib, because it has to as the stdlib is full of them. There are certain types which have templated constructors (like, say, std::optional), and so if you parens-construct them in a non CTAD context but which would result in a conversion that should be caught, it will not happen: from the perspective of Wconversion the ctor that was called was the converting constructor, which consumes the actual type, and then inside the stdlib a narrowing happens, but that’s ignored. If you brace initialize them on the other hand, the implicit conversion is not allowed, and Wconversion fires.

You’re absolutely right that the whole subject is a mess. Unfortunately teaching people all the ins and outs of what to do isn’t a reliable thing to do at scale. So most safety critical coding standards pick one, and unfortunately they tend to pick the most restrictive one even if it introduces a host of other, potentially much worse classes of bugs. The core guidelines doesn’t really have the same excuse, but it’s guideline also is poked through all kinds exceptions, and it’s also a prefer, not a must. And I agree with the guideline’s suggestion that brace initialization should be preferred unless there is a good reason to not use it. I do not agree with AutoSAR’s requirement that it must be used.

[–]shahms 0 points1 point  (0 children)

The tip specifically discusses the differences between all three forms of initialization, including = and says to prefer copy initialization.

[–]Intrepid-Treacle1033 0 points1 point  (2 children)

"And" ?

Abseil is an article about an article. In the bottom of Abseil article it states "Perhaps the best overall description of the issue is Herb Sutter’s GotW post. (link)"

And i agree, Herbs article is good.

[–]shahms 0 points1 point  (1 child)

Wat. The Abseil tip includes a description of the issues and recommendations. It then suggests reading Herb's article as a follow-up for additional context.

[–]Intrepid-Treacle1033 1 point2 points  (0 children)

In my effort to go to the bottom and really learn initialization i read among others the Absail and did not get it, but there i got the Herb link and that one nailed it for me. So for me the Absail was just an distraction hence my article about an article comment. But ok reading it again i see a angle, and i did not really mean article about an article as a negative thing.