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
Реter Konow:
Si crea un array e vi si scrivono i valori delle proprietà del pulsante che si vuole creare.
Un pulsante è composto da tre oggetti: Base, Testo, Immagine.
Ogni oggetto esiste all'interno di un Button Element, quindi l'array deve essere bidimensionale.
Quindi, perché preoccuparsi di tutti quegli array quando si può (e si dovrebbe) usare una struttura per questo. E possiamo indirizzare questi valori umanamente - per nome di campo, non per indice (che può causare molti errori stupidi).
Come risultato, invece di un array bidimensionale ci sarà un array di strutture. La dichiarazione è la stessa concisa, ma la semplicità e l'affidabilità è molto più alta, oltre all'uso razionale della memoria, perché ogni campo ha il suo tipo. E l'OOP non ha niente a che fare con tutto ciò.
Ecco un esempio:
Il risultato è un array di strutture invece di un array bidimensionale. La dichiarazione è la stessa, ma la convenienza e l'affidabilità sono molto più alte, oltre all'uso razionale della memoria, perché ogni campo ha il suo tipo. E l'OOP non ha niente a che fare con tutto ciò.
È un po' ambiguo... cos'è meglio - un array di strutture o una struttura di array?
ma MQL è progettato per lavorare con gli array di Forthran, questo è un fatto...
C'è un po' un dilemma qui... cos'è meglio - un array di strutture o una struttura di array?
Di che tipo di struttura di array stiamo parlando? L'autore ha solo array
Non credo che Peter abbia mai visto come creare un modello di DialogBox in Visual C++, trascinare e rilasciare qualsiasi controllo, come Button, CheckBox, EditBox, ComboBox, ecc.
In altre parole, gli elementi che potete vedere in Windows, comprese diverse opzioni per la visualizzazione di stringhe DB con regolazioni di campi e stringhe.
E con l'uso di MFC si possono fare finestre di dialogo abbastanza complesse in pochi minuti e molto brevemente.
E perché tutte queste perversioni con un array, quando si può (e si dovrebbe) usare una struttura per questo scopo. È inizializzato esattamente allo stesso modo - con valori, separati da virgole. E questi valori sono accessibili umanamente - per nome di campo, non per indice (che può portare a molti errori stupidi).
Come risultato, invece di un array bidimensionale ci sarà un array di strutture. La dichiarazione è la stessa concisa, ma la semplicità e l'affidabilità è molto più alta, oltre all'uso razionale della memoria, perché ogni campo ha il suo tipo. E l'OOP non ha niente a che fare con tutto ciò.
Ecco un esempio:
È una bella soluzione. Ma questa struttura non può essere integrata nel kernel. Se quando si costruisce un kernel secondo la mia tecnologia, basta fare un ciclo sull'array con gli elementi del prototipo e riscriverli nel kernel, nel caso della tua soluzione, il ciclo è impossibile.
Anche se potrebbe essere possibile, ma ogni elemento dovrebbe essere avvolto in una struttura separata. E come visualizzarlo nell'ambito globale? Dove dichiarare tutto... Non è chiaro.
Il mio è semplice. Un array di prototipi di elementi. Tutte le proprietà degli oggetti sono al suo interno. L'array stesso è globale. L'accesso è il più semplice e da qualsiasi punto del programma.
Il tuo istinto non resiste all'uso dei doppi? Dopo tutto, è anche un oggetto composito con i suoi propri metodi. Non c'è posto per loro negli array di kernel ortodossi! Guarda, è impressionante (mantissa, esponente, segno):
Non capisco.
Mi sbarazzo della sintassi inutile e del tamburello, inizializzo semplicemente le proprietà degli elementi in un array globale di prototipi.
È usato solo una volta - quando i prototipi degli elementi sono riscritti nel Kernel.
La riscrittura è fatta in un semplice ciclo.
Di conseguenza, nella fase di costruzione, il Kernel inizia a contenere prototipi di elementi selezionati dall'utente.
Poi, iniziano nuovi cicli sul Kernel. In essi, scrivo i valori definiti dall'utente delle proprietà degli elementi.
Alla fine, si ottiene un Kernel finito, che contiene le finestre utente finite con tutti gli elementi.
Il processo descritto sopra, lo chiamo "processo di costruzione del kernel".
Dopo che il nucleo è stato costruito, il "motore" inizia a funzionare.
Il motore è il codice che controlla la meccanica degli elementi.
Il motore è addestrato a lavorare solo con il Kernel. Il suo motore sono vari eventi (per lo più provenienti da OnChartEvent()).