Pamięć i wskaźniki: MQL5 to nie C++

Składnia przypomina C++, ale zarządzanie pamięcią działa inaczej. Kiedy obiekt ginie sam, a kiedy zostaje w pamięci do zamknięcia terminala.

1 fragment kodu z tej strony przeszedł przez kompilator MetaEditor build 6090, 2026-08-05.

Programiści przechodzący do MQL5 z języków takich jak C++ lub C# często łapią się na tym, że traktują zarządzanie pamięcią w MQL5 zbyt lekko. Składnia przypomina C++, a słowa kluczowe new i delete sugerują pełną kontrolę nad alokacją. Jednak MQL5 posiada własny mechanizm zarządzania pamięcią, który przypomina bardziej środowiska zarządzane (np. .NET) z elementami " inteligentnych wskaźników". Zrozumienie tej różnicy jest kluczowe, aby uniknąć wycieków pamięci i błędów dostępu (Access Violation).

Obiekty automatyczne vs Dynamiczne

W MQL5 obiekt zadeklarowany lokalnie (na stosie) jest niszczony automatycznie po wyjściu z zakresu ważności. Problem pojawia się, gdy używamy wskaźników (*). W C++ wskaźnik to surowy adres w pamięci. W MQL5 wskaźnik to w rzeczywistości uchwyt (handle) zarządzany przez maszynę wirtualną terminala.

Pokrewne problemy i błędy początkujących

Najczęstszym błędem jest założenie, że jeśli wskaźnik przestanie istnieć, obiekt zostanie usunięty (Garbage Collection). W MQL5 tak nie jest. Jeśli stworzysz obiekt przez new, a nie usuniesz go przez delete, pamięć pozostanie zajęta aż do usunięcia wykresu lub wyłączenia terminala.

class CMyStrategy {
public:
    CMyStrategy() { Print("Konstruktor"); }
    ~CMyStrategy() { Print("Destruktor"); }
};

void OnTick() {
    // BŁĄD: Wyciek pamięci przy każdym ticie!
    CMyStrategy *strategy = new CMyStrategy();
    
    // POPRAWNIE: Obiekt automatyczny, usunięty po zakończeniu OnTick
    // CMyStrategy strategy_auto; 
}

Funkcja CriticalError i architektura

Kolejnym problematycznym aspektem jest sposób obsługi krytycznych błędów. W C++ można użyć wyjątków (try/catch). MQL5 nie obsługuje wyjątków w tradycyjnym sensie. Zamiast tego, błędy krytyczne (np. błędny wskaźnik) powodują natychmiastowe zatrzymanie eksperta (EA) z odpowiednim kodem błędu w logach. Używaj bloków sprawdzających (ang. defensive programming), aby zapobiec zatrzymaniu strategii na środku sesji.