
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
Signori, perché non proviamo a fare una discussione concreta? :)
Un foglio corretto non dovrebbe richiedere l'implementazione esplicita di una nuova classe per usarla per una classe arbitraria.
Pertanto, l'implementazione corretta dovrebbe fare affidamento sui template.
Ad essere onesti, non sono sicuro che questo sia realizzabile al livello di template presentato.
Ma questo è in realtà molto lontano dai problemi dell'articolo.
Un elenco corretto non dovrebbe richiedere l'implementazione esplicita di una nuova classe per usarlo per una classe arbitraria...
Condizionalmente, CList dovrebbe includere diversi tipi di nodi....
Perché? ) Un contenitore è un insieme di oggetti omogenei.
La differenza degli oggetti stessi può essere realizzata tramite il polimorfismo all'interno di oggetti già esistenti e non ha nulla a che fare con l'elenco.
Perché? ) Un contenitore è un insieme di oggetti omogenei.
La differenza degli oggetti stessi può essere realizzata dal polimorfismo all'interno di oggetti già esistenti e non ha nulla a che fare con la lista.
Un foglio corretto non dovrebbe richiedere l'implementazione esplicita di una nuova classe per poterla utilizzare per una classe arbitraria.
Pertanto, l'implementazione corretta dovrebbe affidarsi ai template.
Ad essere onesti, non sono sicuro che questo sia realizzabile al livello di template presentato.
Ma questo è in realtà molto lontano dai problemi dell'articolo.
Quello che propone TheXpert sembra essere chiaro.
Se ho capito bene la sua idea, tutti i metodi di una lista astratta dovrebbero riconoscere automaticamente il "suo" nodo (questo è polimorfismo).
Nell'articolo, ad esempio, ci sono le classi utente CiSingleList (Fig.9), CDoubleList (Fig.11), CiUnrollDoubleList (Fig.12), CiCircleDoubleList (Fig.13).
Quindi, in linea di principio, tutti questi metodi possono essere inseriti in una classe. Ma dovremo codificare ogni metodo in modo che riconosca il tipo di nodo di cui si occupa in un determinato momento. E questo richiederà anche una risorsa... quindi non tutto è così chiaro....
È chiaro che un particolare elenco comprende nodi omogenei. Intendevo dire che le relazioni tra i nodi di quell'elenco possono essere diverse, il che richiede un tipo di elenco diverso per ogni tipo di nodo. Se si potesse creare la stessa classe di lista per nodi di tipo diverso, sarebbe fantastico.... Personalmente non l'ho ancora provato..... Bisogna pensare al livello superiore di astrazione.....
Quello che propone TheXpert sembra essere chiaro.
Se ho capito bene la sua idea, tutti i metodi di una lista astratta dovrebbero riconoscere automaticamente il "suo" nodo (questo è polimorfismo).
Nell'articolo, ad esempio, ci sono le classi utente CiSingleList (Fig.9), CDoubleList (Fig.11), CiUnrollDoubleList (Fig.12), CiCircleDoubleList (Fig.13).
Quindi, in linea di principio, tutti questi metodi possono essere inseriti in una classe. Ma dovremo codificare ogni metodo in modo che riconosca il tipo di nodo di cui si occupa in un determinato momento. E questo richiederà anche una risorsa... quindi non tutto è così chiaro...
Cosa c'è da codificare?
Prima elementare, seconda media. Purtroppo non si può fare a meno di un intermediario comunitario, perché MQL5 ha un controllo dei tipi estremamente debole. Ma se avessimo a disposizione una funzione ClassToString come EnumToString(), tutto potrebbe essere organizzato in modo molto più elegante e semplice.