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

[Vadim Zeitlin]

On Mon, 27 Aug 2018 22:53:39 +0000 Greg Chicares <address@hidden> wrote:

GC> That's a good idea. I saw many ctor-initializer blocks and decided just
GC> to 'shift-V' and then repeat a ":'<'>s" command with '@@' because the
GC> total number of changes didn't seem to justify my figuring out anything
GC> much fancier than that.

 FWIW I think a quick "nmap" and/or "vmap" pays for itself pretty quickly.
The good thing about Vim is not it's powerful -- plenty editors are -- but
that its power is simple to use, as with "q" macro recording command or
the various "Xmap" variants.


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 "()".

GC> but are you sure about the following changes
GC> marked with '<---' in the right margin, which seem to copy vector
GC> arguments? (That would be just a pessimization, not an error.)

 Yes, I think they're fine.

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?

GC> (3) Conversion to bool:
GC> 
GC> 'interest_rates.cpp':
GC> 
GC>     ,NeedSepAcctRates_   {v.Database_->Query(DB_AllowSepAcct) != 0.0}
GC> 
GC> I did the same thing, but without the '!= 0.0', and it compiled and
GC> passed the full nychthemeral test suite, notably without any warning
GC> about a narrowing conversion. I would understand if gcc warned on
GC> such lines; what I don't understand is why it didn't warn.

 I'm almost sure that it's a bug in gcc, although I haven't bothered to
report it yet (I probably will...). It somehow compiles the following
program

---------------------------------- >8 --------------------------------------
     1  double foo() { return 17.0; }
     2  
     3  int main()
     4  {
     5      bool b{foo()};
     6      return b;
     7  }
---------------------------------- >8 --------------------------------------

just fine while clang doesn't compile it with the following error:

init.cpp:5:12: error: type 'double' cannot be narrowed to 'bool' in initializer 
list [-Wc++11-narrowing]
    bool b{foo()};
           ^~~~~
init.cpp:5:12: note: insert an explicit cast to silence this issue
    bool b{foo()};
           ^~~~~
           static_cast<bool>( )

which seems more correct to me.

 Of course, in practice I found this while using MSVS which (correctly,
IMO) also gives an error for this:

init.cpp(5): error C2397: conversion from 'double' to 'bool' requires a 
narrowing conversion

 And this is why I'd really like to keep the explicit comparison.

 Thanks for looking at this,
VZ

P.S. This email doesn't break any promises as it's already tomorrow here.