In breve, non si può definire un'implementazione di funzione in .mqh e usarla senza problemi in qualsiasi .ex5
:)
Ma quando usate un .ex5 per chiamare funzioni su un altro .ex5, anche se la funzione con quel nome esiste in entrambi, dovete assicurarvi di specificare accuratamente il namespace. Cioè, il ::In() dovrebbe, in teoria, risolvere il problema. E se non lo fa - questo è un bug che deve essere risolto.
"Quando si compila 1.mq5, all'interno della funzione B() non è chiaro quale funzione dovrebbe essere chiamata, importata A() o esportata A() - perché il compilatore non capisce che si intende la stessa funzione"
Sono giusti sulla forma - ma se si volesse, al compilatore potrebbe (e dovrebbe) essere detto che è la stessa funzione, come ripeto il nome del modulo al momento della compilazione è disponibile (specificato in #import).
Tanto più che se prima metti :: in un posto e compili, poi cancelli e metti :: in un altro - tutto funziona, ma devi essere d'accordo - è molto scomodo e dopo 10-15 permutazioni forzate sono passato a #define
"Quando si compila 1.mq5, all'interno della funzione B() non è chiaro quale funzione debba essere chiamata,
Importato A() o esportato A() - poiché il compilatore non capisce che intendevi la stessa funzione".
Assolutamente, è così.
Sono corretti nella forma - ma al compilatore potrebbe (e dovrebbe) essere detto che è la stessa funzione se lo si desidera, come ripeto il nome del modulo è disponibile al momento della compilazione (specificato in #import).
Per tali suggerimenti esiste un operatore di risoluzione del contesto "::", ma non è applicabile in questo caso perché anche il nome del modulo (file) è lo stesso.
Il consiglio è adeguato - cambiare la struttura del programma.
Tanto più che se prima metti :: e compili in un posto e poi togli e metti :: in un altro - tutto funziona, ma devi essere d'accordo - è molto scomodo
È meglio evitare questi trucchi, che non sono solo scomodi, ma anche "razzialmente scorretti", "poco ortodossi", "brutti", e "su moccio". I tentativi di imbrogliare il compilatore hanno il diritto di esistere solo se non ci sono altre opzioni per implementare ciò che si vuole. In questo caso, ce ne sono molte.
e dopo 10-15 di queste permutazioni forzate sono passato a #define
Le define parametrizzate sono utili solo quando il rilevamento del tipo non è desiderabile o quando i parametri sono sostituiti da pezzi di testo "verbosi". Come sostituto di una funzione in linea, una define è senza dubbio dannosa per la salute di un programma.
--
Nel tuo caso mi rifiuterei di usare le librerie .ex5, e tutto funzionerebbe bene. L'unico uso pratico che se ne può fare è nell'implementazione dell'occultamento (quando si vende), e non vedo il loro uso in altri casi.
A proposito, per quanto riguarda l'inlining, funziona. Ci sono stati anche problemi con il debugger a causa di questo.
Quindi funziona a livello di compilatore. Ho dato un esempio sopra - tutto funziona attraverso un inspiegabile "bypassare il compilatore", mentre il lavoro diretto richiede passaggi extra, a volte significativi, perché come hai suggerito di non includere la descrizione e l'implementazione di una stessa funzione in un file è certamente possibile, ma poi 10 .mqh completi sono spezzati in 100 .mqh più piccoli
Non ho ancora inseguito la velocità. La cosa principale è la comodità e che la quantità di codice non cresca esponenzialmente.
Ho anche affrontato la necessità di usare analoghi #if #else in MQL5 (è un po' complicato finora, ma funziona qua e là)
Non sto ancora cercando la velocità. La cosa principale è la convenienza e che il volume di codice non cresca esponenzialmente.
Dipende da voi. Ma dato l'amore patologico delle meta-citazioni per le limitazioni, c'è una probabilità tutt'altro che nulla di prendere un rastrello o due con tali macro.
Solo un sacco di .mqh e un eseguibile .mq5, nient'altro.
Uso un codice su 3 terminali diversi, significa che almeno un .ex5 (condiviso da tutti) deve essere. E se è così - allora torniamo al problema descritto sopra - ci sono solo 2 moduli - ma non si compilano normalmente.
In breve, non si può definire un'implementazione di funzione in .mqh e usarla senza problemi in qualsiasi .ex5
:)
Ma quando usate un .ex5 per chiamare funzioni su un altro .ex5, anche se la funzione con quel nome esiste in entrambi, dovete assicurarvi di specificare accuratamente il namespace. Cioè, il ::In() dovrebbe, in teoria, risolvere il problema. E se non lo fa - questo è un bug che deve essere risolto.
Fermiamoci con la risposta di ServiceDesk:
"Quando si compila 1.mq5, all'interno della funzione B() non è chiaro quale funzione dovrebbe essere chiamata,
importata A() o esportata A() - perché il compilatore non capisce che si intende la stessa funzione"
Sono giusti sulla forma - ma se si volesse, al compilatore potrebbe (e dovrebbe) essere detto che è la stessa funzione, come ripeto il nome del modulo al momento della compilazione è disponibile (specificato in #import).
Tanto più che se prima metti :: in un posto e compili, poi cancelli e metti :: in un altro - tutto funziona, ma devi essere d'accordo - è molto scomodo e dopo 10-15 permutazioni forzate sono passato a #define
Fermiamoci con la risposta di ServiceDesk:
"Quando si compila 1.mq5, all'interno della funzione B() non è chiaro quale funzione debba essere chiamata,
Importato A() o esportato A() - poiché il compilatore non capisce che intendevi la stessa funzione".
Sono corretti nella forma - ma al compilatore potrebbe (e dovrebbe) essere detto che è la stessa funzione se lo si desidera, come ripeto il nome del modulo è disponibile al momento della compilazione (specificato in #import).
Per tali suggerimenti esiste un operatore di risoluzione del contesto "::", ma non è applicabile in questo caso perché anche il nome del modulo (file) è lo stesso.
Il consiglio è adeguato - cambiare la struttura del programma.
Tanto più che se prima metti :: e compili in un posto e poi togli e metti :: in un altro - tutto funziona, ma devi essere d'accordo - è molto scomodo
e dopo 10-15 di queste permutazioni forzate sono passato a #define
Le define parametrizzate sono utili solo quando il rilevamento del tipo non è desiderabile o quando i parametri sono sostituiti da pezzi di testo "verbosi". Come sostituto di una funzione in linea, una define è senza dubbio dannosa per la salute di un programma.
--
Nel tuo caso mi rifiuterei di usare le librerie .ex5, e tutto funzionerebbe bene. L'unico uso pratico che se ne può fare è nell'implementazione dell'occultamento (quando si vende), e non vedo il loro uso in altri casi.
Stai scrivendo per vendere?
Stai scrivendo per vendere?
Per me stesso.
Non posso farlo senza .ex5. Ho anche funzioni come F( string& [] ), che in qualche modo non entrano in .dll :)
Forse si potrebbe spingerli attraverso un separatore, ma non ho ancora provato
MQL5 non ha funzioni in linea (in forma) e uso invece macro parametriche, che non è del tutto corretto, perché non c'è controllo del tipo.
Inoltre, il compilatore non ottimizza le espressioni, quindi c'è un'ulteriore penalità di velocità. È meglio che controlli.
A proposito, riguardo all'inlining - funziona. Ho avuto alcuni problemi con il debugger a causa di questo.
A proposito, per quanto riguarda l'inlining, funziona. Ci sono stati anche problemi con il debugger a causa di questo.
Quindi funziona a livello di compilatore. Ho dato un esempio sopra - tutto funziona attraverso un inspiegabile "bypassare il compilatore", mentre il lavoro diretto richiede passaggi extra, a volte significativi, perché come hai suggerito di non includere la descrizione e l'implementazione di una stessa funzione in un file è certamente possibile, ma poi 10 .mqh completi sono spezzati in 100 .mqh più piccoli
Non ho ancora inseguito la velocità. La cosa principale è la comodità e che la quantità di codice non cresca esponenzialmente.
Ho anche affrontato la necessità di usare analoghi #if #else in MQL5 (è un po' complicato finora, ma funziona qua e là)
Non sto ancora cercando la velocità. La cosa principale è la convenienza e che il volume di codice non cresca esponenzialmente.
A100:
Non funziona senza .ex5. Ho anche funzioni come F( string& [] ), ma non entrano in .dll in qualche modo :)
....
Cavolo... :)
Non ho suggerito di usare DLL invece di librerie .ex5. Solo un sacco di .mqh e un eseguibile .mq5, niente di più.
Solo un sacco di .mqh e un eseguibile .mq5, nient'altro.