Errori, bug, domande - pagina 2636

 
Koldun Zloy:

Non sono uno sviluppatore, ma commenterò.

Per un array statico, il compilatore deve allocare un certo numero di byte in memoria al momento della compilazione.

Quanta memoria dovrebbe allocare il compilatore se row e col sono sconosciuti al momento della compilazione?

I valori iniziali sono utilizzati solo se i parametri sono omessi durante la chiamata. I parametri effettivi sono noti solo in fase di esecuzione.

Quindi, niente espedienti, imparate la lingua.

Sto parlando ad alta voce, ma è più un appello allo sviluppatore.
Quindi Zloy, non prenderla sul personale.

Si scopre che le matrici dinamiche possono essere gestite solo attraverso oggetti o strutture. Un'altra stampella è creata in generale.
Non ci sono puntatori alle variabili in mql, quindi dobbiamo usare l'approccio a oggetti dove i puntatori sono disponibili.
Quindi, per utilizzare le matrici dinamiche, un utente deve conoscere OOP e lavorare con i puntatori, e inoltre, nell'esecuzione MQL.
Quanti di loro hanno questa conoscenza? Tu stesso conosci la risposta. Non ho difficoltà a capire l'approccio a oggetti, ma per coloro che non conoscono OOP
Creano una soglia artificiale per l'uso del linguaggio, in particolare quando si tratta di matrici dinamiche.
Per come la vedo io, uno sviluppatore, al contrario, dovrebbe essere interessato a rendere il linguaggio più facile da usare, piuttosto che complicarlo.
In altre parole, dovrebbero sviluppare quelle funzioni che sono necessarie all'utente per lavorare comodamente con il linguaggio.
E tanto più con le matrici, che sono quasi la base dei metodi numerici.

Per questo motivo, vorrei chiedervi di creare funzioni simili ad ArrayResize solo per le matrici ArrayResizeMx(A, n, m),
e forse anche per quelli multidimensionali. In altre parole, dare la possibilità di lavorare con le matrici non come con gli oggetti, ma come con i normali array nello stile C.
Specialmente per la rappresentazione visiva delle matrici, la funzione ArrayPrint(A, 0) stampa le matrici dagli array, non dagli oggetti.

 
Roman:

Nel 2012, il problema degli array dinamici multidimensionali è stato risolto con successo...
Ecco un thread correlato:https://www.mql5.com/ru/forum/6729

Il codice può ora essere migliorato aggiungendo il supporto per i template.

 
Sergey Dzyublik:

Nel 2012, il problema degli array dinamici multidimensionali è stato risolto con successo...
Ecco un thread correlato:https://www.mql5.com/ru/forum/6729

Il codice può ora essere migliorato aggiungendo il supporto per i template.

Leggete tutto il thread, per fortuna è breve.
Così il topic starter, e non ha rivelato la sua impresa!
Una specie di presa in giro, esca il tema e sparisca.
E ancora una volta è un'immersione nell'OLP, a nessuno è permesso entrare.
Yuri ha citato la sua soluzione, nessuno sa quanto sia vera.
Che dovremo modificare e modificare. Chi lo farà? Nessuno, dato che non l'hanno ancora completato.

Questo è il motivo per cui abbiamo bisogno di funzioni che lavorino con matrici dinamiche fuori dalla scatola da parte dello sviluppatore.
Lo sviluppatore conosce meglio il soggetto e l'allocazione della memoria senza wrapper sembra molto meglio e più veloce.
Almeno una funzioneArrayResizeMx(A, n, m, k) aprirebbe la possibilità di lavorare non con oggetti ma con array in stile C.

 
Roman:


E questa è di nuovo un'immersione in OOP, nessuno può entrare.

Romano:


Quindi, per usare le matrici dinamiche l'utente deve conoscere l'OOP e lavorare con i puntatori e anche nell'esecuzione MQL.
Quanti di loro hanno questa conoscenza? Tu stesso conosci la risposta. Non ho difficoltà a capire l'approccio a oggetti, ma per coloro che non conoscono OOP
Creano una soglia artificiale per l'uso del linguaggio, in particolare quando si tratta di matrici dinamiche.
Mi sembra che lo sviluppatore, al contrario, dovrebbe essere interessato a rendere il linguaggio più facile da usare piuttosto che complicarlo.

Forse vi sorprenderà, ma i giovani programmatori di oggi considerano l'OOP una programmazione più facile della programmazione procedurale.

State pensando in termini di 25 anni fa. I giovani d'oggi assorbono l'OOP con il latte della madre. Imparate l'OOP se volete essere alla moda, altrimenti non farete altro che brontolare.

 
Nikolai Semko:

Forse vi sorprenderà, ma i giovani programmatori di oggi considerano l'OOP una programmazione più facile della programmazione procedurale.

forse rispetto alla programmazione funzionale?

 
Nikolai Semko:

Forse vi sorprenderà, ma i giovani programmatori di oggi considerano l'OOP una programmazione più facile della programmazione procedurale.

State pensando in termini di 25 anni fa. I giovani d'oggi assorbono l'OOP con il latte della madre. Imparate l'OOP se volete essere alla moda, altrimenti non farete altro che brontolare.

Sì, capisco l'OOP, non nella misura in cui vorrei.
Questo non è un brontolio ma una proposta costruttiva.
Affinché lo sviluppatore non debba scrivere una funzione per allocare due malloc, costringono gli utenti a studiare OOP.
Questo è certamente il progresso, lo sviluppo e la divulgazione del linguaggio. Potete vedere quanto amano e capiscono l'OOP qui.
Vedi, Nikolay, tutto ciò che è avvolto è codice non necessario da eseguire - non credo ci sia bisogno di spiegare perché.
Non ho bisogno di parlarvi dei moderni compilatori di ottimizzazione - non sappiamo quali istruzioni applicheranno.
Forse vi sorprenderà anche il fatto che anche i programmatori americani preferiscono scrivere in stile procedurale non perché l'OOP è male, ma perché il codice è più semplice e veloce.
E se non ci sono compiti ad oggetto nel progetto, perché usare i wrapper, che devono essere in qualche modo compresi, per i giovani ))
Quindi non sono d'accordo con te che i giovani assorbono avidamente OOP.

Sto pensando in C, che è dove è costruita la logica del linguaggio mql.
C è nato nel 1972, quindi ha 48 anni ))
Ma comunque C è uno dei linguaggi più veloci. Sapete perché? Perché non ha wrapper di classe.

 
Andrei Trukhanovich:

forse rispetto a uno funzionale?

Proceduralmente funzionale :)

 
Petros Shatakhtsyan:

Non credo che sia così. C'è un argomento speciale qui: https://www.mql5.com/ru/forum/40295

Non l'ho guardato fino in fondo, soprattutto perché è per MQL4.

Non credo che il server debba inviare le quotazioni dei simboli se il mercato è chiuso.

Il mio robot non è realmente influenzato da questo perché dopo che il mercato "apre" quando arrivano i tick analizza la tendenza, le loro inversioni, e questo richiede un po' di tempo. Durante questo periodo il mercato si apre.

Ma è d'intralcio se vogliamo eseguire manualmente alcuni trade durante questo periodo. Se l'esecuzione è basata sul mercato, la richiesta è in attesa fino all'apertura del mercato e viene naturalmente eseguita al prezzo corrente.

La funzione diretta che riceve il nome del simbolo e restituisce vero/falso (mercato aperto/chiuso) è chiaramente mancante.

C'è una quotazione e una sessione commerciale. Cerca, è stato spiegato 20 volte.

 
Andrey Dik:

Si prega di aggiungere un altro distintivo di qualche tipo:

4. Soldi

Dove la somma di tutti i fondi ricevuti per il giorno (mercato, freelance, ecc.) verrebbe visualizzata, sarebbe molto comodo, e ora per questo bisogna andare nel profilo, che vedrebbe il saldo disponibile.

Se così tanto e regolarmente arriva, si può ordinare un plugin per il cromo ;)

 
Andrey Khatimlianskii:

C'è una sessione di quotazione e una sessione di trading. Cercalo, è tutto masticato 20 volte.

Mi ci sono voluti solo pochi giorni per passare da VC++ a MQL5. Non ho mai cercato qualcosa così a lungo.

Se ricevi il messaggio "Mercato chiuso" durante il trading, devi avere un modo semplice per determinare questo stato, invece di scrivere codice chilometrico e complicato.

Non darmi consigli del genere.

Motivazione: