Discussing the article: "The MQL5 Standard Library Explorer (Part 18): Building a Multi-Symbol Indicator Cache"

Check out the new article: The MQL5 Standard Library Explorer (Part 18): Building a Multi-Symbol Indicator Cache.

The article introduces a centralized cache that serves indicators to multiple strategy nodes. It encodes full indicator identity in keys, stores Standard Library objects in CArrayObj entries, reuses matching instances, verifies readiness, refreshes data, and deletes each indicator on final release. Readers gain a predictable resource lifecycle and reduced duplication in multi‑symbol Expert Advisors.

In Part 17 of the MQL5 Standard Library Explorer, we replaced duplicated multi-symbol variables with independently owned strategy nodes coordinated by a portfolio manager. That structure exposes the next practical problem. In multi-symbol Expert Advisors, indicator objects are frequently created and managed inside every strategy module: each consumer repeats the same handle creation, BarsCalculated() checks, Refresh() calls, buffer reads, error handling, and release logic. This is acceptable while requests remain unique, but when several nodes request the same indicator type, symbol, timeframe, and inputs, it becomes inefficient and error-prone. Duplicate calculations, repeated readiness code, and unclear resource ownership make safe shutdown and partial initialization difficult.

This article implements a shared indicator cache that centralizes creation, readiness checking, buffer refresh, lifetime ownership, and final release. A consumer describes the indicator it needs; for the supported MA and ATR objects, the cache builds a key from every parameter accepted by the corresponding builder, returns an existing entry on a hit or creates one on a miss, applies the BarsCalculated()+Refresh()+GetData() readiness boundary, and manages lifetime with reference counting and a Release(entry&) contract. Strategy nodes keep their independent signal and position state, but they acquire and return cache entries instead of managing indicators directly. The result is a predictable, reusable resource layer suitable for adding future signal, risk, reporting, and visualization modules.


Author: Clemence Benjamin