Re: [lmi] Numerics

[Vadim Zeitlin]

On Mon, 9 May 2016 04:04:10 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-05-08 22:59, Vadim Zeitlin wrote:
GC> [...moving the big questions to the top (terse answers elaborated below)...]
GC> > 0. Whether you're sure we don't need ctor from dollars+cents.
GC> 
GC> Yes, I am sure we don't need that.
GC> 
GC> > 1. What would you prefer to call units/subunits.
GC> 
GC> Dollars and cents.

 OK, thanks for confirming this, I'll update the class soon.

GC> > 2. What API for rounding would you like to see.
GC> 
GC> No rounding API at all.

 I'll reply to this part separately as I don't have time to do it now.


GC> A masked edit control makes sense for mixed-base systems, but aside from
GC> calendar dates, who uses them any more?

 FWIW I did see them used for currency values. Admittedly, this is (much?)
more rare than just having one field accepting values with the decimal
point, but it does happen.

GC> (you wouldn't give your height as two meters and five
GC> centimeters--you'd say 2.05m, right?)

 No, unless I was feeling pretty boastful. But I would say 1 meter 94
centimeters, normally.


GC> > GC> Can the "using" typedef and the "constexpr" things be made private?
GC> > 
GC> >  They could, but I think they should be public because it can be useful to
GC> > this class clients. The constants probably won't be that much if the ctor
GC> > from dollars+cents doesn't exist any more, but the underlying type still
GC> > seems to be useful.
GC> 
GC> Are you arguing against premature encapsulation--preferring to keep these
GC> implementation details public until the interface is settled and we can be
GC> sure that we won't have to un-hide them in order to implement some function
GC> we haven't thought of yet? If so, okay...but when the design is complete,
GC> wouldn't we want to hide these details?

 The number of decimal points/cents can be useful for validating the user
input: even if we use a single control for currency entry, we still want to
limit the fractional part to 2 digits, I think, don't we? So I don't think
this should be hidden.

 The underlying type is an implementation detail but it may be useful to
the class users too. Also, as long as we provide total_cents() method, this
type is the type of its return value anyhow, so we can't really hide it.

GC> Okay. It's certainly not confusing. It's just that when I see a comment,
GC> I try to replace it with an assertion. Alternatively, if the comment
GC> doesn't say anything that isn't obvious, I tend to remove it. Renaming
GC> will make it obvious:
GC>   static constexpr int cents_per_dollar = 100;
GC> and I think that line needs no comment

 OK, I'll remove it.

GC> > GC> I think these functions should be private:
GC> > GC>   amount_type units() const
GC> > GC>   int subunits() const
GC> > 
GC> >  Again, for me these methods are useful for a GUI showing the amount in
GC> > dollars and cents.
GC> 
GC> Well...I suppose they might be useful in check-writing software that needs
GC> to form strings like "One hundred twenty-three dollars and forty-five 
cents".
GC> But...no, in that contrived case, natural language must replace digits. Do
GC> you see any concrete use case that is really plausible?

 Any presentation not using simple strings. E.g. if we wanted to use a
"LED" widget to prominently display some amount. Or maybe if we wanted to
format the currency in some fancy way (use slightly larger font for the
dollar part than for the cents? or underling the latter?) in PDF output.
I don't know how plausible is this...

GC> > GC>   amount_type total_subunits() const
GC> > 
GC> >  This one is admittedly mostly an implementation detail but it seems 
pretty
GC> > harmless to have and it makes writing tests much simpler. Could we please
GC> > keep it?
GC> 
GC> If you really want to keep it, could it be private (with the unit-test class
GC> declared as a friend)?

 I should have been more precise, it's convenient for the tests but it's
not only useful for them. It would also be needed for serializing the
object in a binary form, for example. It looks unnecessarily petty to hide
it, after all this class basically exists solely in order to have this
"total_cents" member, why not allow accessing it?

GC> > FWIW I think it's a good idea to always provide default initializers for
GC> > all non-object fields in C++11, even if there is just a single ctor
GC> > initializing them anyhow because it makes it impossible to leave a field
GC> > uninitialized, e.g. by adding another ctor later.
GC> 
GC> And in C++11, as a corollary, is it a recognized "best practice" not to
GC> re-specify them in any ctor that uses the same default value?

 I am not an authority on the subject of C++11 best practices, but I do
think so, yes.

[...snip rounding behaviour discussion...]

 I'll have to reread this and think about it more before replying to it,
I'll try to do it a.s.a.p. but probably tomorrow.

 Regards,
VZ