Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
BTW, sei consapevole che la build 1325 ha introdotto i puntatori alle funzioni?
Questo fa qualche differenza nell'applicazione della comunicazione triangolare?
MQL5: Aggiunto il supporto per i puntatori alle funzioni per semplificare la disposizione dei modelli di eventi.
Per dichiarare un puntatore a una funzione, specificare il tipo "puntatore a una funzione", per esempio:
Ora, TFunc è un tipo, ed è possibile dichiarare la variabile puntatore alla funzione:
La variabile func_ptr può memorizzare l'indirizzo della funzione per dichiararla in seguito:
I puntatori alle funzioni possono essere memorizzati e passati come parametri. Non è possibile ottenere un puntatore a un metodo di classe non statico.
Probabilmente è solo per MT5, e da quello che ho visto non è ancora per i metodi, solo per le funzioni.
Comunque non ho ancora capito come si definisce l'abilità di terze parti all'interno della classe base, per esempio nel contesto della linea di tendenza e del contenitore, dove si trova il terzo oggetto.
Ma cercherò di leggere di nuovo.
Voglio dire, come e dove decidere chi (quale classe) riceverà cosa (evento).
È chiaro che il dispatcher superiore, quello nativo della lingua, cioè il linguaggio ::OnChartEvent è scritto solo una volta in un progetto, nella classe di primo livello.
Allora da qui, qual è il modo o i modi corretti di distribuire gli eventi ai diversi oggetti?
Dovrebbe esserci una classe di eventi di dispacciamento? Dovrebbe essere fatto solo nel ::OnChartEvent basato su dichiarazioni if?
Quello che mi sembra mancare nella comprensione del modello degli eventi in connessione con OO e MQL5, è quale sia il giusto tipo di dispacciamento degli eventi.
Voglio dire, come e dove decidere chi (quale classe) riceverà cosa (evento).
È chiaro che il dispatcher superiore, quello nativo della lingua, cioè il linguaggio ::OnChartEvent è scritto solo una volta in un progetto, nella classe di primo livello.
Quindi da qui, qual è il modo o i modi corretti di distribuire gli eventi ai diversi oggetti?
Dovrebbe esserci una classe di eventi di dispacciamento? Dovrebbe essere fatto solo nel ::OnChartEvent basato su dichiarazioni if?
Ok, penso di aver capito. C'è un vero problema di spostamento di concetto quando si passa dal procedurale all'oop.
In realtà, una volta volevo implementare l'osservatore e a causa della mancanza di interfacce in MQL o dell'ereditarietà multipla non l'ho fatto. Non ho pensato alla tua buona idea che lo stesso oggetto può forzare l'interfaccia su entrambi i lati.
Così in realtà ogni CObject ora ha un posto di un oggetto che è il ricevitore di eventi, e ha anche un metodo di registrazione per l'oggetto di ascolto per iscriversi come tale e un metodo mittente di eventi e un metodo gestore di eventi utilizzato dal ricevitore.
In realtà, una volta volevo implementare l'osservatore e a causa della mancanza di interfacce in MQL o dell'ereditarietà multipla non l'ho fatto. Non ho pensato alla tua buona idea che lo stesso oggetto può forzare l'interfaccia su entrambi i lati.
Solo per incoraggiarti, ho usato molto gli ascoltatori con MQL4.
Grazie, ma non mi sento incoraggiato (:
Sono riuscito a farlo, ma non con un contratto tra l'editore e l'ascoltatore, voglio dire, l'editore doveva presumere che l'ascoltatore avesse il metodo di gestione, ma nulla obbligava che lo avesse.
Oppure, dovrei ereditare tutti gli ascoltatori da un oggetto ascoltatore principale - ma poi ovviamente perderei tutto il punto perché non possono ereditare altre classi.
Comunque, sono un professionista della programmazione, ma sicuramente non in OO dove non ho ancora esperienza, e non sono in competizione con nessuno di voi programmatori oo esperti come Doerk.
Quello che sono venuto a sapere è che essere procedurale ti dà una buona logica e capacità di programmazione, ma il cambiamento è mentalmente difficile, specialmente se un orientato alla procedura come me affronta la missione di costruire un framework OO, è uno stato mentale totalmente diverso. E il framework della parte GUI è il framework più dettagliato con molti eventi di cui prendersi cura, penso che voi ragazzi sarete d'accordo che tra i framework è il più difficile da costruire.