Re: [lmi] () or {} in initializer lists

[Vadim Zeitlin]

On Sun, 26 Feb 2017 18:44:46 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-02-22 18:16, Vadim Zeitlin wrote:
GC> > On Wed, 22 Feb 2017 17:30:13 +0000 Greg Chicares <address@hidden> wrote:
...
GC> > GC> but the inconsistent use of () vs. {} looked ugly, so I tried this
GC> > GC> (bear in mind that years_to_maturity_ is an int, whereas the other
GC> > GC> two are vectors):
GC> > GC> 
GC> > GC>  InputSequence::InputSequence(std::vector<double> const& v)
GC> > GC> -    :years_to_maturity_(v.size())
GC> > GC> +    :years_to_maturity_{v.size()}
GC> > GC> +    ,number_result_    {v}
GC> > GC> +    ,keyword_result_   {}
GC> > GC> 
GC> > GC> which of course warns of a narrowing conversion on size(),
GC> > 
GC> >  I know it's annoying, but is hiding the implicit conversion really 
better?
GC> > As changing years_to_maturity_ to be size_t seems to be a bad idea (it
GC> > would probably have cascading effects on other variables...), I'd write
GC> > "{static_cast<int>(v.size())}".
GC> 
GC> A safe cast that throws on actual narrowing would be a better choice
GC> here IMO (I'm planning to work on it, but haven't made the time yet).
GC> I would object to "{static_cast<int>(v.size())}" because it doesn't
GC> resolve the problem that "{}" is trying to tell us about--it merely
GC> tells the compiler to ignore it.

 I think it's, unfortunately, the lesser evil we need to live with in C++.
We know fully well that we won't have vectors of the size greater than
INT_MAX here because they wouldn't fit in memory anyhow (even in 32 bits,
let alone 64 bit ones) and the cast is just the unavoidable consequence of
the clashing conventions between the standard library, which uses size_t
for sizes and indices, and lmi, which uses int.

 If you remember, in our discussion of unsigned types some time ago, this
was one of the reasons I gave for preferring them in the application code
as well. But if/as we don't want to do this, it seems we need to just
accept such casts.

 Of course, in principle the proposed int_cast() throwing if passed a value
outside of the int range would be even better, but it's not really going to
change anything during run-time and will (slightly) hurt the code clarity,
so I'm not sure if it's really worth it.

 Regards,
VZ