Il mio approccio. Il nucleo è il motore. - pagina 4

[Aliaksandr Hryshyn]

OOP non interferisce con l'implementazione del kernel, al contrario.

Di solito ci sono codice e dati. Il kernel, nel nostro caso, è il codice, fortemente separato dai dati. I dati possono anche essere il codice stesso. Il kernel di solito ha una funzionalità più completa per gestire dati specifici, o almeno un minimo autosufficiente.

Questo approccio permette di utilizzare il formato di dati più conveniente, si presume che ci saranno molti dati.

Ecco un altro esempio in cui questo approccio può essere applicato: ci sono molte strategie nell'Expert Advisor, i dati rappresentano solo la logica delle strategie, il nucleo è la funzionalità per gestirle, vale a dire, gestione degli ordini, gestione del rischio, lavoro con l'ambiente di trading, indicatori, gestione degli errori, visualizzazione di alcune o tutte le statistiche, funzioni trailing/grid/.....

[Alexey Navoykov]

Ре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:

struct TObject { char type;  string name;  int x;  int y;  int width;  int height;  color clr; };

TObject Objects[]= { { OBJ_BITMAP, "Bitmap", 100, 100, 200, 200, clrRed },
                     { OBJ_BUTTON, "Button", 150, 150, 50, 10, clrWhite },
                   };

[Maxim Kuznetsov]

Alexey Navoykov:

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...

[Alexey Navoykov]

Maxim Kuznetsov:

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

[Petros Shatakhtsyan]

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.

[Реter Konow]

Alexey Navoykov:

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.

[pavlick_]

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, perché è impressionante (mantissa, esponente, segno):

_NEW_OBJECT, тра-та-та-та-та-та, 3, 10, 1, тра-та-та-та-та-та

[Реter Konow]

pavlick_:
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.

[Реter Konow]

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.

[Реter Konow]

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()).