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

[Greg Chicares]

On 2018-08-23 12:39, Vadim Zeitlin wrote:
> On Thu, 23 Aug 2018 00:48:49 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC>         :html_{html}
> GC> is perfectly fine, and needn't be changed to something like this:
> GC>         :html_(html)
> GC> , right? Sure, I don't see any objection to that.
> 
>  I thought we already agreed that "{html}" was fine, so the question was
> rather whether you agreed that its advantage was sufficient to justify
> changing the existing code and replacing all "(html)"s with "{html}".
> You seem to have already answered it affirmatively below, but let me just
> show what kind of changes I'm speaking about:
> 
>       https://github.com/vadz/lmi/compare/uniform-init?expand=1

That looks great. The only thing I'd change is whitespace, e.g.:

-        :image_{image}
-        ,src_{src}
-        ,scale_factor_{scale_factor}
+        :image_        {image}
+        ,src_          {src}
+        ,scale_factor_ {scale_factor}

to facilitate reading it as two columns.

[quoting out of order for clarity]
>  OK, I'll extend the Github commit shown above to cover all the files then.
> Just a word of warning: it would be best to apply it relatively quickly, as
> such global changes will very quickly get out of date and result in
> conflicts if you try to apply it later. Would you be ready to apply such
> (mostly purely mechanical) patch now? If not, please let me know and I'll
> delay it.

Yes, I stand ready to do that, with only these qualifications:

- I'll be unavailable for about twenty-four hours in the next
seventy-two due to a family obligation.

- I'm working intensively on these files:
    report_table*.?pp wx_table_generator.?pp
and would prefer to modify those myself in order to avoid a merge.

>  It only won't work if there is a narrowing conversion. In this case we can
> still perform the conversion explicitly or try to get rid of it. And either
> would be an improvement compared to an implicit conversion IMHO.

Any narrowing conversions might pose unexpected challenges, but
AFAICS that's only if they reveal unrecognized implicit conversions,
which may reasonably be regarded as defects anyway.

> GC>     -    std::vector<int> const expected = {3, 4, 5};
> GC>     -    BOOST_TEST(widths(v) == expected);
> GC>     +    BOOST_TEST(widths(v) == std::vector<int>({3, 4, 5}));
> GC>     but writing the parentheses that the preprocessor then requires is
> GC>     too high a price to pay.
> 
>  It should be possible to avoid the extra parentheses with the variadic
> macros, shouldn't it?

Maybe I'm missing something good, but I haven't tried to learn anything
about preprocessor improvements since approximately C89.

> GC> +    // Set boolean vectors so that some columns get none.
> GC> +    BOOST_TEST(std::vector<int>({0, 5, 0}) == apportion({0, 1, 0}, 5));
> GC> 
> GC> where '({})' didn't seem "too high a price to pay". In the former case,
> GC> I thought it was a preprocessor workaround, hence distasteful. In the
> GC> latter case, I thought it was a C++ language requirement, hence tasteful.
> 
>  I must be missing something, but why did you think this in the latter
> case?

Insufficient time to study--no other reason.