Re: [lmi] Switch to using C++11 uniform initialization in the ctor initializer lists?

[Greg Chicares]

On 2018-08-22 21:35, Vadim Zeitlin wrote:
> 
>  I now hesitate every time when initializing a member or a base class in
> the ctor initializer list in lmi code as I'm not sure whether we're
> supposed to use "uniform initialization" syntax for it, i.e. braces, or the
> old-style parentheses.

I myself also hesitate. In practice, I look at 'input_sequence_parser.hpp',
where we chose a style deliberately after much discussion, and just try to
follow that:

  class SequenceParser final
  {
...
      token_type current_token_type_               {e_startup};
      double current_number_                       {0.0};
      std::string current_keyword_                 {};
      int current_duration_scalar_                 {0};

although probably I often forget to do so and just write
  foo::foo(int xyz) : xyz_(xyz)
out of habit. And I'm not sure we ever did come up with a general style
for this, one that answers all questions--e.g., in the
  foo::foo(int xyz) : xyz_(xyz)
example, should the header have something like
  int xyz_ {};
or
  int xyz_ {0};
even when a ctor initialization list would always change the value?

Is there some recent example in your work or mine, or some older example
from anywhere in lmi, that we could go over in full detail with the goal
of establishing the One True Way?

> On one hand, I think we should use braces because
> this is consistent with member initialization in their declarations and,
> also, because it's safer (value-changing conversions are not performed by
> this kind of initialization), but OTOH almost all the existing code, with
> the exception of the html::text class I wrote, uses parentheses.

Let's see...

namespace html
...
class text
{
  public:
    // This type has value semantics.
    text() = default;
    text(text const&) = default;
    text(text&&) = default;
    text& operator=(text const&) = default;
    text& operator=(text&&) = default;

Those are all defaulted, so you must mean this private one:

    // This move ctor is private and does not perform any escaping.
    explicit text(std::string&& html)
        :html_{html}

, right? So your exact question is whether I agree that
        :html_{html}
is perfectly fine, and needn't be changed to something like this:
        :html_(html)
, right? Sure, I don't see any objection to that.

I'm using {} a lot more these days. I'm still not sure when to use
({}) instead. To illustrate my uncertainty, compare:

$git show 4d5025d2

    Use terser syntax in unit test
    
    Even denser would be
    -    std::vector<int> const expected = {3, 4, 5};
    -    BOOST_TEST(widths(v) == expected);
    +    BOOST_TEST(widths(v) == std::vector<int>({3, 4, 5}));
    but writing the parentheses that the preprocessor then requires is
    too high a price to pay.

to this later commit:

$git show 27d79e25

+    // Set boolean vectors so that some columns get none.
+    BOOST_TEST(std::vector<int>({0, 5, 0}) == apportion({0, 1, 0}, 5));

where '({})' didn't seem "too high a price to pay". In the former case,
I thought it was a preprocessor workaround, hence distasteful. In the
latter case, I thought it was a C++ language requirement, hence tasteful.
Perhaps I was correct in one of those cases, but I don't know which.

>  So I wonder about what of the following would you prefer:
> 
> 0. Keep using parentheses in any new code.

That would imply that 'html.?pp' as quoted above should be changed, but
I don't think it should be changed.

> 1. Use braces in the new code and replace neighbouring parentheses with
>    the braces in this code only.
> 2. Replace all the existing parentheses with braces and use only the latter
>    ones in the future.
> 
> (I omit the variant "�. Use braces in the new code without changing
> anything else" as having different kind of parentheses in the same file is
> just too inconsistent to be acceptable IMO).

Number two. Only number two produces global consistency.

Unless we discover cases where number two doesn't work.