Errori, bug, domande - pagina 1016

 
A100:

Sì, grazie, ho fatto un errore nel semplificare il codice sorgente - ora ho riscritto l'errore in modo diverso

Ho cancellato il precedente per evitare confusione.

È terribile. Lo è davvero. Che cosa terribile da vivere...

--

Senti, cosa ci guadagni? Se non è un segreto.

Scrivi il tuo consulente in Lisp? Tanto di cappello, ma ti consiglio di passare a Haskell.

;-)

 
MetaDriver:

Senti, a cosa ti serve? Se non è un segreto.

Beh, MQL5 non ha funzioni in linea (in forma) e uso invece macro parametriche, il che non è del tutto corretto, perché non c'è controllo del tipo
 
A100:
MQL5 non ha funzioni in linea (in forma) e uso invece macro parametriche.

Sì, li uso anch'io, ma non così raccapricciante per il nido. ))))

Per vostra informazione, mql5 traduce tutte le piccole funzioni in sostituzione inline. In altre parole, possiamo assumere che la parola chiave "inline" sia in ogni funzione definita dall'utente per default.

La decisione di sostituire una macro o di compilare in una funzione è presa in definitiva dal compilatore (proprio come il C++, tra l'altro). Quindi non ha senso cercare di accelerare le cose in questo modo, tutte le funzioni semplici sono comunque inlineate.

// E a proposito - con il controllo dei tipi! :)

 

MetaDriver:

Per riferimento, mql5 traduce tutte le piccole funzioni in sostituzioni inline. In altre parole - si può assumere che la parola chiave "inline" sia in ogni funzione utente per default.

Non sto cercando di renderlo più veloce, ma per comodità. Possono essere in linea nella sostanza, ma non nella forma(!). Le difficoltà sorgono se si definisce inline in .mqh e poi lo si usa in diversi .ex5. Ora cercherò di trovare il link

https://www.mql5.com/ru/forum/1111/page1013#comment_520221

int B() { return ( A( 0 ) ); }

Ci B() in 1.mqh dovrebbe essere in linea - ma tutti insieme - non compila normalmente - solo separatamente. ServiceDesk riferendosi all'ambiguità della chiamata non ha approfondito l'essenza del problema e ha raccomandato di organizzare il progetto in modo diverso. Come si potrebbe fare diversamente? Tutto funziona solo quando rimuovo l'implementazione B() da .mqh a .ex5. E cos'è allora la forma inline?

A proposito, in MQL4, quell'esempio funziona - senza errori, anche se B() non è in linea di fatto, ma nella forma - in linea.

 
A100:

E non l'ho fatto per la velocità, l'ho fatto per comodità. In sostanza possono essere in linea, ma non in forma(!).

E che dire della forma.

"Chi è una Studebaker? È il tuo parente Studebaker? Tuo padre è una Studebaker?"

Le difficoltà sorgono se si definisce inline in .mqh e poi lo si usa in diversi .ex5.

Non ci sono difficoltà, se non si fanno errori logici e si capisce bene come funziona un compilatore.

Ora cercherò di trovare il link

https://www.mql5.com/ru/forum/1111/page1013#comment_520221

La funzione B() qui è essenzialmente inline

Non sono riuscito a sbarazzarmi di errori come "chiamata ambigua a funzione sovraccaricata con gli stessi parametri" - non si verificavano a meno che non la si mettesse in un .ex5 separato

Hai essenzialmente una ricorsione irriconoscibile a livello di codice sorgente. Il compilatore ti ha disapprovato misericordiosamente, proprio nel merito. Stai cercando di connetterti all'inluder a libu, che definisce lo stesso inluder in cui stai compilando. Allora, cosa vuoi? Se tu fossi un compilatore, cosa faresti?

Questa potrebbe essere una novità per voi, ma una funzione inline scritta in una DLL non può in alcun modo essere usata come macro al di fuori di questa DLL. // In runtime il codice sorgente non esiste più

Immagino la seconda notizia per voi: tutte le librerie in mql(4, 5) sono collegate dinamicamente. Si tratta essenzialmente di DLL.

In conclusione: stavi effettivamente cercando di riferirti da un lib a se stesso, riferendoti a se stesso, riferendoti a se stesso...... ecc.

Sono d'accordo, sarebbe molto peggio se compilasse tutto senza obiezioni, e poi a runtime la lib cercasse di caricarsi ricorsivamente fino ad esaurire la memoria.... :))

?

Ecco perché c'è la parola chiave inline in C/C++

Non è affatto questo il motivo. Sono sicuro che l'esempio al link non compilerà in C++.

// Sono troppo pigro per controllare, ma non ha senso. Se non capisco come costruire un codice sorgente organizzato ricorsivamente, non lo capirà neanche il compilatore.

 
A100:

A proposito, quell'esempio funziona in MQL4 - senza errori, anche se B() non è in linea, ma in forma - in linea

Anche se... dato che non c'è il ricaricamento delle funzioni, forse il compilatore non cerca nemmeno di accennare al ricaricamento errato - semplicemente ignora stupidamente le definizioni ripetute.
 
MetaDriver:
Anche se... dato che non c'è sovraccarico di funzioni lì, forse il compilatore non cerca di suggerire un sovraccarico sbagliato lì - semplicemente ignora stupidamente le definizioni ripetute.

Si compila in MQL4 (!) e in C/C++ se si scrive inline prima di B()

Non c'è alcuna ricorsione lì, infatti c'è

int A( int ) e #define B() A( 0 )

È molto semplice lì - se non sei troppo pigro - dai un'occhiata sulla tua testa fresca - solo dichiarazione e implementazione delle funzioni separate :)

 
A100:

Lì B() in 1.mqh dovrebbe essere inline - ma tutti insieme non si compilano normalmente - solo separatamente. ServiceDesk riferendosi all'ambiguità della chiamata non è andato in profondità nel cuore del problema e ha raccomandato di organizzare il progetto in un altro modo. E come altro?

Si è risposto da solo:


Funziona solo se si rimuove l'implementazione B() da .mqh in .ex5. Cos'è la forma inline allora?

Il problema non è affatto con l'inline B(), ma con la sua ridefinizione. Poiché la lib è una DLL, le informazioni sugli inluders inclusi in essa (i loro nomi) mancano già durante la ricompilazione 1.mqh (la prima compilazione è stata al momento della formazione della lib), quindi quando si compila l'inline, viene trovata la funzione B() ridefinita, e dato che i parametri sono gli stessi, il compilatore considera questo un tentativo errato (scorretto) di ricaricare la funzione. Ha tutti i diritti. Molto educatamente, avrebbe potuto giurare.
 
MetaDriver:
Hai appena risposto alla tua stessa domanda:
Il problema non è affatto l'inineità di B(), ma la sua ridefinizione.

È solo che C/C++ capisce (usando la parola chiave inline) che questa non è una ridefinizione, e MQL5 no, anche se può distinguere tra il nome del modulo compilato e uno specificato in #import. Non so come MQL4 lo capisca.

In breve, non si può definire un'implementazione di una funzione in .mqh e usarla senza problemi in qualsiasi .ex5.

 
A100:
Esattamente giusto - è solo che C/C++ capisce che questa non è una ridefinizione, e MQL5 no.

C/C++ sono in grado di capire questo SOLO quando si compila una lib statica, perché le informazioni sul nome del sorgente sono memorizzate nel file oggetto (solo per riconoscere la ricompilazione).

Con le librerie collegate dinamicamente questo non funzionerà e se lo fa non è a causa del rilevamento della reimplementazione ma a causa delle "regole di priorità" per la congruenza dei nomi del sorgente corrente e della DLL. Alcuni linguaggi hanno tali regole (Delphi in particolare, probabilmente anche alcuni compilatori C/C++ le hanno).