stillwater-sc / universal / 34759491821

86%

master: 84%

push

github

refactor(einteger): split einteger into core / manipulators / iostream / debug (#1334) (#1457)

* refactor(einteger): split einteger into core / manipulators / iostream / debug (#1334)

First type of Phase 2 group 5b (#1455), the elastic types.

    core.hpp        55,183 lines / 284 headers / 0 I/O-family
    einteger.hpp    73,655 lines / 369 headers / 5 I/O-family  (was 94,467 / 395 / 5)

Zero I/O-family headers is met. Under-45,000 lines is not, and reporting the
number rather than moving the bar: native/ieee754_core.hpp is 43,486 lines on
its own (already 0 I/O), and einteger needs two functions from it --
extractFields and ieee754_parameter. The narrower header those live in,
extract_fields.hpp, is not self-contained; it leans on ieee754_core.hpp's
include order. That is the substrate's to fix, not this PR's.

The regex was the whole of the I/O problem

parse() classified its input with four std::regex patterns, compiled on every
call. <regex> alone is 78,114 preprocessed lines and pulls <sstream>, <istream>
and <ostream>. parse() cannot leave the core -- assign(const std::string&) is
built on it, the layer contract -- so the patterns became four hand-written
matchers in einteger_detail, each accepting exactly its pattern's language under
std::regex_match's whole-string semantics. None needs backtracking: a sign run
can never swallow the '0' after it.

That is also why the UMBRELLA dropped 20,812 lines: the regex is gone for every
einteger user, not only core users.

The proof is a new regression test, conversion/parse_grammar.cpp, which keeps the
original patterns as its oracle: every byte value 0..255 in 144 grammar contexts,
plus every string up to length 4 (level 1), 5, 6 and 7 (level 4) over a 19-symbol
alphabet covering each character class and its neighbours. Ten single-point
mutations of the matchers -- each range bound, the '0'-only decimal, the "0b"
minimum, 'X', the apostrophe, the sign set, the octal radix marker -- are all
caught at... (continued)

128 of 162 new or added lines in 3 files covered. (79.01%)

43285 of 50504 relevant lines covered (85.71%)

7163325.33 hits per line