Object Pool Allocator

Calling `new` and `delete` inside OnTick() on every price update is a common source of slow, gradually fragmenting long-running EAs - a session that runs for weeks accumulates enough churn that allocation itself starts costing measurable time. An object pool fixes this by allocating everything once, up front, and handing out the same objects again and again. MQL4 has no templates, so a pool that hands back "any type the caller likes" cannot be written the generic way a C++ or MQL5 pool would be. This header uses the same workaround MQL4 code reaches for wherever a function pointer or a template would normally go: an interface. Every object the pool manages derives from CPoolable and implements OnPoolReset(); the pool itself only ever stores CPoolable pointers, and Acquire() calls OnPoolReset() before handing an object back, so no state from a previous borrower leaks into the next one. The MQL5 port deliberately keeps this same interface-based design rather than rewriting it as a template<typename T> pool - MQL5 does support templates, but a template rewrite would change the public API (and every call site) into a genuinely different, MQL5-only design rather than a straight port of this one. Anyone who wants a templated pool on MQL5 can write one directly; this submission's job is to be the same header on both platforms. Ownership is deliberately never the pool's. The caller `new`s each object exactly once and registers it; the pool's whole job is recycling that pointer afterwards. Clear() forgets the objects rather than deleting them, because a pool with no templates has no way to know how to construct a replacement of an unknown type - it can only ever manage pointers it was handed. Release() refuses anything that is not a currently-checked-out member of the pool, so a stray pointer or an accidental double-release cannot silently corrupt the free/in-use bookkeeping. The header is self-contained. No dependencies, no DLLs. Notes and limitations - Acquire() and Release() are linear scans over the pool's capacity, not O(1). This is the right trade for the pool sizes this header targets - tens of reusable buffers or chart-object wrappers - not thousands of tiny per-tick allocations, where a purpose-built allocator would be worth the extra complexity. - The pool never allocates or deletes the objects it manages. The caller creates every object with `new` before registering it, and is responsible for deleting each one after Clear() (or whenever the pool itself is no longer needed) - the pool cannot know how to construct a replacement of a type it has no template for. - Acquire() returning NULL means the pool is exhausted, not that something failed. Always check for NULL before using the result - Register() more objects, wait, or fall back to a plain `new` for that one call, depending on what your program needs. - No money is at risk in the demo. It manages a small in-memory buffer type only and never sends a trade request.

Script · MT4 · v1.0 · Free

Tags: Trading Sessions · MT4 Script · MQL4 Source Code

MQL4 & MQL5 scripts · PolyMaria