[lmi-commits] [5043] Resolve several marked defects

[Greg Chicares]

Revision: 5043
          http://svn.sv.gnu.org/viewvc/?view=rev&root=lmi&revision=5043
Author:   chicares
Date:     2010-07-20 19:23:49 +0000 (Tue, 20 Jul 2010)
Log Message:
-----------
Resolve several marked defects

Modified Paths:
--------------
    lmi/trunk/ChangeLog
    lmi/trunk/ledger_invariant.cpp

Modified: lmi/trunk/ChangeLog
===================================================================
--- lmi/trunk/ChangeLog 2010-07-20 19:22:52 UTC (rev 5042)
+++ lmi/trunk/ChangeLog 2010-07-20 19:23:49 UTC (rev 5043)
@@ -26390,3 +26390,16 @@
   mec_input.cpp
 Update version timestamps in comments.
 
+20100720T1922Z <address@hidden> [693]
+
+  loads.cpp
+Terminate if untested premium-load amortization is used.
+
+20100720T1923Z <address@hidden> [689]
+
+  ledger_invariant.cpp
+Resolve several marked defects. DAC-tax load no longer depends on
+whether premium tax is tiered. One can follow Kernighan and Plauger's
+"Avoid THEN-IF and null ELSE" advice in TEoPS with any type of
+selection-statement.
+

Modified: lmi/trunk/ledger_invariant.cpp
===================================================================
--- lmi/trunk/ledger_invariant.cpp      2010-07-20 19:22:52 UTC (rev 5042)
+++ lmi/trunk/ledger_invariant.cpp      2010-07-20 19:23:49 UTC (rev 5043)
@@ -737,12 +737,6 @@
         {
         Smoker = (*b->Input_)["Smoking"].str();
         }
-    // TODO ?? Use a switch-statement instead. The original version of
-    // this code was just if...else, and silently deemed the convention
-    // to be smoker/nonsmoker if it wasn't specified as tobacco/nontobacco;
-    // but if it were neither, that was silently 'fixed' in a way that's
-    // not likely to be correct. If we later added 'cigarette/noncigarette',
-    // which some companies use, then we would have gotten smoker/nonsmoker!
     else
         {
         throw std::logic_error("Unknown oe_smoker_nonsmoker convention.");
@@ -760,8 +754,8 @@
     StatePostalAbbrev       = mc_str(b->GetStateOfJurisdiction());
 
     StatePremTaxRate        = b->PremiumTaxRate();
-    // TODO ?? Output forms presuppose that the premium tax load is a
-    // scalar unless it is tiered.
+    // SOMEDAY !! No output form uses this as of 2010-07; for now at
+    // least, it's assumed to be a scalar unless it is tiered.
     StatePremTaxLoad        = b->Loads_->premium_tax_load()[0];
     LMI_ASSERT
         (PremiumTaxLoadIsTiered || each_equal
@@ -771,20 +765,18 @@
             )
         );
     DacTaxPremLoadRate      = b->Loads_->dac_tax_load()[0];
-    // TODO ?? Output forms presuppose that the DAC tax load is scalar;
-    // and it seems odd that the DAC-tax load would have much to do
-    // with whether the premium-tax is tiered.
+    // SOMEDAY !! No output form uses this as of 2010-07; for now at
+    // least, it's assumed to be scalar.
     LMI_ASSERT
-        (PremiumTaxLoadIsTiered || each_equal
+        (each_equal
             (b->Loads_->dac_tax_load().begin()
             ,b->Loads_->dac_tax_load().end()
             ,b->Loads_->dac_tax_load().front()
             )
         );
-    // TODO ?? The database allows a distinct DAC tax fund charge, but
-    // it seems that output forms assume that the DAC tax premium load
-    // represents the entire DAC tax charge, so they're incorrect if
-    // the DAC tax fund charge isn't zero.
+    // SOMEDAY !! The database allows a distinct DAC tax fund charge,
+    // but it's not supported yet. Output forms must not assume that
+    // the DAC tax premium load represents the entire DAC tax charge.
     LMI_ASSERT(0.0 == b->Database_->Query(DB_DacTaxFundCharge));
 
     InitAnnLoanDueRate      = b->InterestRates_->RegLnDueRate