Range Checking

MtxVec has its own range checking system, independent of the Delphi/C# compiler.

How it works:

• MtxVec methods validate all index/length parameters before processing
• Violations raise EMtxVecRangeError with a descriptive message
• This checking is controlled by Assertions, not by the compiler range-check flag

Enabling/disabling:

Setting	Effect	Use case
Assertions ON	Full range checking, object cache disabled	Debug builds
Assertions OFF	No range checking, object cache active	Release builds (fastest)

In Delphi: Project → Options → Compiler → Assertions. In C#: MtxVec range checking is always active (not controlled by compiler flag).

Important: MtxVec's index validation is Assertions-based and entirely separate from the Delphi compiler's {$R+} switch — see "Delphi {$R+}" below for how the compiler's own checks can still fire on MtxVec data. Access sub-ranged data through the Values property, which honours the sub-range window:

var a, b: TVec;
begin
    CreateIt(a, b);
    try
        a.LoadFromFile('data.vec');
        b.SetSubRange(a, 2, 10);     // b is a view of a[2..11]
        b.Values[0] := 1.0;          // writes to a[2]
        b.SetSubRange;               // release view
    finally
        FreeIt(a, b);
    end;
end;

Recommendation: Use Assertions ON during development, OFF for release.

Delphi {$R+} — why it can still fire on MtxVec data:

{$R+} makes the compiler emit bounds checks into your code, tested against the bounds the compiler can see. Those bounds do not describe MtxVec's storage: a sub-ranged vector is a window onto another object's memory, and a matrix is addressed as a 2-D view over one flat block. The compiler therefore compares an index against the wrong extent and can report a range error for a perfectly valid access.

Because those checks are generated in your own unit, this happens even when MtxVec itself was compiled without {$R+} — the library's build setting cannot remove a check the compiler placed in your code. Working with matrices is the most common way to hit it.

The library source can itself be built with {$R+}, and false positives are not excluded there either — the library's own tests account for that discrepancy. When you use the library in source form, do not build with {$R+}, and switch it off locally with {$R-} around code that indexes vector or matrix elements.

None of this affects MtxVec's own range checking: it is Assertions-based and validates every index and length argument regardless of the {$R+} setting.

No special handling is needed for SetSubRange in C#.