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 C++: the index and length checks of the indexed methods (Sin(X, XIndex, Len, DstIndex) and the like) are always active and raise EMtxVecRangeError. The element accessors (Values, Values1D, SValues, CValues, ...) are inline functions in the headers and check the index and the storage precision only when MTXVEC_RANGE_CHECKING is defined. Because the define changes inline code, define it for the whole build — your code and the MtxVec sources alike. It does not switch off the object cache.

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:

// C++: b->Values(0) is checked only when MTXVEC_RANGE_CHECKING is defined.
// SetSubRange works the same as in Delphi and C#.
TVec* a = nullptr;
TVec* b = nullptr;
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
}
catch (...)
{
    FreeIt(a, b);
    throw;
}
FreeIt(a, b);

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

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#.