[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] Zeroing elements toward the end of a vector [Was: Add a cast to fi
[lmi] Zeroing elements toward the end of a vector [Was: Add a cast to fix compilation in 64 bits]
Mon, 13 Mar 2017 13:45:42 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
On 2017-03-13 04:36, Greg Chicares wrote:
> Okay, now that it compiles, how should we rewrite it for clarity?
> Even after all these years, I still think in APL, so my first idea is
> data ← original_length ↑ shorter_length ↑ data
> ledger_map_t const& l_map_rep = ledger_map_->held();
> using T = decltype(ledger_invariant_->InforceLives)::size_type;
> T original_size = ledger_invariant_->InforceLives.size();
> T lapse_year = T(0);
> for(auto const& i : l_map_rep)
> lapse_year = std::max(lapse_year, static_cast<T>(i.second.LapseYear));
Comparison to the original reveals that 'lapse_year' must be increased
by one at this point. I found that error in system testing, and I added
two instead of one, then retested--and it failed as expected, but I
wanted to know for sure. When I added one instead, all tests passed.
> if(lapse_year < original_size)
> (I don't see a much less annoying way to get size_type; ptrdiff_t isn't
> guaranteed to work forever, and I don't ever want to have to correct
> this type again.)
> Is that really likely to be far short of optimally efficient? resize()
> doesn't reduce the vector's capacity, so there's no memory allocation.
> Sure, we're destroying the last (original_size-lapse_year) elements
> and default-inserting the same number, but notionally at least that's
> no more complicated than explicitly zeroing the elements.
I demoted the severity of the "TODO" comment. The system testing
described above shows that this code does something needful. It
is not clear whether there exists any better way to do this, so
it is too harsh to label it as a defect.