Re: [lmi] [lmi-commits] master b518132 4/4: Remove the latent defect just added

[Vadim Zeitlin]

On Fri, 7 Sep 2018 00:45:38 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-09-06 01:04, Vadim Zeitlin wrote:
GC> > On Wed,  5 Sep 2018 20:56:27 -0400 (EDT) Greg Chicares <address@hidden> 
wrote:
GC> > 
GC> > GC> branch: master
GC> > GC> commit b518132022d0dab59226f584778973265b71e532
GC> [...]
GC> >  I've read the entire explanation, but this still looks weird to me. 
AFAICS
GC> > all this was done just to avoid dividing by potentially 0 lines_per_group_
GC> > (please correct me if I'm wrong).
GC> 
GC> Yes, that's exactly the goal. And yes, looking back at it a day later,
GC> it is rococo, so I've reverted that last commit and used a different
GC> technique instead in commit ad23b9ee.

 Thank you in advance (as I don't see this commit on Savannah yet...)!

[...]
GC> And I plan to grow the ctor-initializer:
GC> 
GC>     ,quotient    {b / a}
GC>     ,remainder   {b % a}
GC> 
GC> and would prefer not to write both safe_divide() and safe_remainder()
GC> when all that's needed is one safe denominator.

 Yes, this is an even better objection to safe_divide().

GC> > This would seem to be much simpler and avoid the need
GC> > for a clumsy (IMHO) ctor_args_are_sane_ field.
GC> 
GC> Yes, thanks for challenging that. I hope you'll find commit ad23b9ee
GC> less obtrusive.

 I almost certainly will.

GC> > It is also arguably safer
GC> > because if you always use safe_xxx() when dividing integers, you don't 
have
GC> > to check that you had checked preconditions at some previous moment.
GC> 
GC> I would hesitate to provide a generally-available utility function
GC> for that purpose because it's hard to track down where an exception
GC> was thrown when a messagebox just says "Cannot divide by zero".

 Yes, indeed. This could be solved by passing a message to use when the
precondition is violated to safe_denominator() however, couldn't it?

 Thanks again for revisiting this,
VZ