[lmi] Delegating ctor uncalled for? [Was: master 6335e9a 1/4: Render comprehensible]

[Greg Chicares]

On 2017-01-26 02:43, Greg Chicares wrote:
[...]
> As for me, I look at
>   $grep 'TODO ??' input_seq* |wc -l
> and see an opportunity to remove 26/422 = six percent of lmi's marked
> defects.

Postponing the title question for a moment...

$grep 'TODO ??' input_seq* |wc -l
5

So far, 21/422 = five percent. Of the five that remain, I understand two,
and three are in the recursive-descent parser, which I haven't touched
yet...but I should, because it contains stuff like:

    std::string s;
    s += static_cast<char>(t);
    return s;

and

    // COMPILER !! 21.3/6 gives push_back() as a member of the
    // string class, and Stroustrup uses it in 6.1.3 of TC++PL3,
    // whence this and other ideas are borrowed, but gcc-2.95.x
    // seems not to support it

which suggest opportunities for simplification.

> Perhaps this class really wants delegating ctors: there's common
> post-initialization in realize_vector().

Vadim, tell me if you disagree, but I don't think that's a good idea
after all.

AIUI, delegation is most appropriate when there's one "complete" ctor
that initializes everything--then simpler ctors can delegate to it
(e.g., with some arguments defaulted) to make sure no initialization
step is skipped.

In this case, however, the InputSequence ctors take disjoint sets of
arguments. One takes only a single std::vector<double> argument with
one value for each year, and turns it into an InputSequence: it just
performs run-length encoding. Another takes numerous arguments that
represent the full context used in the GUI, but that one includes no
std::vector<double> argument. Therefore, any target ctor we might
write for this class would be a new, least-complete ctor consisting
only of this single line, which is the common initialization today:
    realize_vector();
and delegation would amount to nothing but elaborate syntactic sugar.