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

[Greg Chicares]

On 2018-08-27 23:13, Vadim Zeitlin wrote:
> On Mon, 27 Aug 2018 22:53:39 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> I have three types of questions:
> GC> 
> GC> (1) Vectors, excluding those constructed as
> GC>   v(number_of_elements, default_value)
> GC> The commit message suggests that you endeavored to avoid also
> GC>   v(std::vector<same_type> const&)
> 
>  No, I didn't, my commit message was just not formulated precisely enough.
> 
> GC> (because initializing them through an initializer-list would invoke
> GC> the copy ctor twice),
> 
>  I don't think so. The only potentially usable ctor for std::vector<T>
> takes std::initializer_list<T> and std::vector<T> itself is not convertible
> to T, so either "v_(v)" or "v_{v}" use the copy ctor. And I think the
> latter one is preferable for the reason previously discussed: this ctor is
> just a simple initialization and doesn't do anything special, so there is
> no need to make it stand out by using "()".

Okay, thanks--I had read your commit message carelessly, but now I understand.

x> GC> (2) Ctor invocations. Even if these do work, should they use '{}',
> GC> or would '()' be better?
> 
>  I don't know, it's a question of taste. Probably you're right and I might
> have got carried away a bit here. Would you like me to change those back or
> do you prefer to do it yourself?

I would prefer to use parentheses for invocations of ctors that take
arguments (other than copy ctors, as discussed above for vectors).
To me at least, that makes it explicit that a function is being
invoked:
  :another_class(arg0, arg1, arg2)
whereas using '{}' may suggest that the arguments constitute an
initializer-list.

I've committed a branch
  https://git.savannah.nongnu.org/cgit/lmi.git/commit/?h=odd/uniform_i12n
with my version of this changeset, including some comments in the
commit message. Please take a look and tell me what you think.
Perhaps I was overly cautious with a few product-editor files;
I wouldn't object to your changes there as long as you've tested
them to make sure they work.