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
L'ho fatto in questo modo:
Ma per qualche motivo ci sono molti errori durante la compilazione. Cosa c'è che non va?
Cercare di trasferire un Singleton piuttosto semplice da Myers a MQL4++ potrebbe apparire così, per esempio:
Risultato dell'esecuzione:
Un metodo statico singleton() crea una variabile statica di tipo Symbol_Properties, ma in fase di compilazione viene generato un errore di accesso alla chiamata di costruttore NON valido, perché il metodo, sebbene statico, - ha accesso a tutti i membri, compresi quelli privati. Pertanto, a causa di un bug nell'implementazione di MQL4++ questo costruttore doveva essere messo in pubblico. Se lo aggiustano, non dovremo più farlo.
Il risultato dell'esecuzione mostra che i dati sono cambiati dopo la chiamata change(). Questo indica indirettamente che la funzione change() ha ricevuto l'indirizzo dello stesso oggetto al suo interno che è stato ricevuto anche in OnStart().
A causa dell'errore in MQL4++ questo non è affatto un Singleton, poiché il costruttore di default è pubblico, quindi possono essere creati molti oggetti del genere. Se l'errore viene corretto, e dopo che il costruttore di default viene messo nella sezione privata, diventerà un'implementazione completa di Myers' Singleton in MQL4++.
Non hai capito in due giorni che la statica si comporta in modo diverso in stuct e in classe?
le strutture sembrano essere prese da c e solo un po' pompate in termini di ereditarietà,
Per quanto riguarda le classi, sono complete.
Per questo motivo, non è necessario riservare spazio per una variabile statica nelle strutture
ma bisogna riservare uno spazio nelle classi, altrimenti non si può:
Non è vero, questo meraviglioso compilatore MQL4++ si comporta diversamente. Non appena si crea un'istanza dell'oggetto, il comportamento si "allinea":
Per qualche motivo non compila (il primo e il terzo sono avvertimenti, ma il secondo è un vero e proprio errore):
Quindi è necessario riservare "spazio per una variabile statica" nelle strutture?
E nella prossima versione del terminale/compilatore, sarà lo stesso (bene, per non correre a sistemare tutto quello che è stato scritto prima quando si cambia versione)?
Ho dimenticato l'incapsulamento. E può essere cancellato. E qui non ci sono puntatori costanti). E in generale, il singleton non è il modello migliore.
E i modelli sono buoni, almeno alcuni. Per le classi, probabilmente solo un sogno.
Beh, che sia il peggiore o il migliore, non giudicherò.
Permettetemi di ricordare ai partecipanti alla discussione che le modalità di gestione della memoria menzionate sopra - automatica, dinamica, statica, basata - non si applicano ai template, non importa quanto sia potente l'OOP.
Ora, a causa di un bug in MQL4++, questo non è un Singleton, perché molti oggetti del genere possono essere creati, perché il costruttore di default è pubblico. Se l'errore viene corretto e il costruttore di default viene messo nella sezione privata, diventerà un'implementazione Singleton a tutti gli effetti in MQL4++.
Grazie, non sapevo di poter prendere un puntatore qui.
Il codice è incasinato, potrebbe essere più semplice, mi dispiace che non ci siano modelli.
Non posso mettere il codice ((
classe Singleton{
privato:
classe SomeClass{
pubblico:
int a;
};
Singleton(){}
~Singleton(){}
pubblico:
static SomeClass* Instance(){
statico SomeClass a();
return GetPointer (a);
}
};
void OnStart()
{
SomeClass* some_ptr = Singleton::Instance();
some_ptr.a = 5;
Alert(some_ptr.a);
}
Grazie, non sapevo che si potesse prendere un puntatore qui.
Stai pasticciando con il codice, potrebbe essere più semplice, mi dispiace che non ci siano modelli.
Non riesco a far funzionare il codice ((
classe Singleton{
privato:
classe SomeClass{
pubblico:
int a;
};
Singleton(){}
~Singleton(){}
pubblico:
static SomeClass* Instance(){
statico SomeClass a();
return GetPointer (a);
}
};
void OnStart()
{
SomeClass* some_ptr = Singleton::Instance();
some_ptr.a = 5;
Alert(some_ptr.a);
}
Ecco il codice di Myers per C++:
Ed ecco lo stesso codice trasposto in MQL4++, che è la parte tecnica della classe nell'esempio:
Dov'è la "magia" qui?
Il tuo esempio sfrutta gli errori del compilatore MQL4++, in particolare, l'uso del tipo SomeClass in OnStart() è inappropriato, perché questo è un tipo annidato della classe Singleton, e il compilatore "adulto" rileva immediatamente un errore:
Tuttavia, questo non è un punto cruciale, poiché un tipo annidato può essere specificato correttamente. Ciò che è più importante è che il tipo SomeClass è dichiarato nella sezione privata della classe Singleton, e quindi usare SomeClass in OnStart() è ora fondamentalmente sbagliato, cosa che il compilatore "adulto" segnala immediatamente:
La vostra implementazione funzionerà a meno che il compilatore MQL4++ non corregga i baccanali del controllo di accesso.
1. Maerse, non Maerse, che cazzo importa se il codice funziona e fa la cosa giusta senza errori in MQL e non in ++.
2. Il vostro codice fa quello che dovrebbe? No, non lo fa. Avete già capito tutto.
Il mio esempio ha dimostrato il workaround degli errori (riguardanti il C++) in MQL. Se qualcosa non è conveniente, vedi i punti 1 e 2.
4. Per quanto riguarda la creazione di un puntatore a una classe privata, sì, è un errore MQL, ma non c'è un auto per identificare il tipo, quindi è bene che funzioni. \
(p.s. Forse ho esagerato a spese dell'auto, dovrei controllare)
5. Non ho trovato alcun modo in MQL di dereferenziare un puntatore per ottenere un oggetto, quindi considero superflui il costruttore di copie private e l'operatore di assegnazione.
Prova a usarli, sarò felice di vedere il modo))
1. Maerse, non Maerse, che cazzo importa se il codice funziona e fa la cosa giusta senza errori in MQL e non in ++.
2. Il vostro codice fa quello che dovrebbe? No, non è così. Avete già capito tutto.
Il mio esempio mostra la gestione degli errori (rispetto al C++) in MQL. Se qualcosa non è conveniente, vedi i punti 1 e 2.
4. Per quanto riguarda la creazione di un puntatore a una classe privata, sì, è un errore MQL, ma non c'è un auto per identificare il tipo, quindi è bene che funzioni. \
(p.s. forse ho esagerato a spese dell'auto, dovrei controllare)
5. Non ho trovato alcun modo in MQL di dereferenziare un puntatore per ottenere un oggetto, quindi considero superflui il costruttore di copie private e l'operatore di assegnazione.
Prova a usarli, sarò felice di vedere il modo))
1. Ora - lo fa, ma NON in questo modo (spiegazione sotto).
2. Se non lo aggiustano - non lo farà neanche lui. Ed è improbabile che sia implementabile del tutto.
3. Non è un modo per aggirare i bug, è sfruttamento.
4. Ci sono molte cose che non ci sono.
5. Queste cose possono essere possibili in questa versione, in particolare, credo di aver fatto balenare che il costruttore di copie non è sintetizzato, ma questo non garantisce che non inizierà a sintetizzare nelle versioni future. L'overhead di dichiararli, d'altra parte, penso sia trascurabile.
Ora per spiegare perché il tuo codice non solo ha i potenziali problemi che ho menzionato nel post precedente, ma anche perché non è in linea di principio un singleton e non lo sarà, e se risolvono i baccanali di accesso o no:
Questo codice viene eseguito con successo:
Vedete quanti singleton sono riusciti ad essere creati, eppure non esistono ancora?
Cambierebbe qualcosa in questo senso per il vostro codice se il baccanale dell'accesso fosse fissato?
Cambierà nel mio codice?
Pensate che più non vi scusate, più il vostro punto di vista sarà corretto?
Sì, grazie per l'attenzione, hai ragione, non è un singoletto neanche in questa variante.
Per quanto riguarda i costruttori e gli operatori impliciti - rendeteli espliciti e provate a usarli, mi sembra che non funzionino a causa dell'impossibilità di dereferenziare il puntatore all'oggetto
Perché non funziona, 'ptr' - non può chiamare la funzione membro protetta :
Sì, grazie per l'attenzione, hai ragione, non è un singoletto neanche in questa variante.
Per quanto riguarda i costruttori e gli operatori impliciti - rendeteli espliciti e provate a usarli, mi sembra che non funzionino a causa dell'impossibilità di dereferenziare il puntatore all'oggetto
Perché non funziona, 'ptr' - non può chiamare la funzione membro protetta :
Non sembra funzionare e ci sono molti altri bug qui. È un peccato che poche persone lo notino. Non voglio entrare in una discussione, ma in realtà c'è un'enorme differenza. Alcune cose che si applicano alle strutture in C++ non funzionano in MKL4. Ma tacerò... altrimenti cominceranno a fare domande come:
"Perché ne ho bisogno".
Se non altro per non entrare in un libro di testo incompiuto, ma semplicemente scrivere cose che funzionano in C++ in MKL4 e non pensare se funzionano qui o no. Non ho bisogno di nient'altro in questa fase...