Programmazione asincrona e multithread in MQL - pagina 35

 
Andrei Novichkov:

Perché non leggere effettivamente la bandiera nella documentazione? Su https://en.cppreference.com . Ed esempi con discussione su stackoverflow.com. Di solito uso queste fonti di informazione, e vi consiglio di fare lo stesso.

Perché, allora, vuoi partecipare alla conversazione se non sei responsabile delle tue parole? Mi interessava la tua opinione, non quella dei ragazzi intelligenti del manuale. Togliti di mezzo. Posso leggere le banchine senza le vostre istruzioni. E non ho bisogno di tutto questo zoo di future/promise/async per chiamare una funzione in un thread.

 
Vict:

Perché allora entrare nella conversazione se non si risponde di quello che si dice? Mi interessava la tua opinione, non quella dei ragazzi intelligenti del manuale. Togliti di mezzo. Posso leggere le banchine senza le vostre istruzioni. E non ho bisogno di tutto questo zoo di future/promise/async per chiamare la funzione in un thread.

Non ha alcun senso. Non lo sai, ti ho detto dove trovare le informazioni. Ed è stata colpa mia. Sii più spesso amico dei libri.
 
Andrei Novichkov:
Non ha alcun senso. Non lo sai, ti ho detto dove trovare informazioni. Ed è stata colpa mia. Sii più spesso amico dei libri.

A quanto pare non lo sai nemmeno tu. Perché scrivere di niente? Forse non lo so, qual è il problema? Ho chiesto un parere normale, mi ha mandato da qualche parte.

In lista nera, compagno.

 
Vict:

A quanto pare non lo sai nemmeno tu. Perché scrivere di niente? Forse non lo so, qual è il problema? Ho chiesto un parere normale, mi ha detto di andare da qualche parte.

In lista nera, compagno.

Non ti ho mandato da nessuna parte, non ci ho nemmeno pensato. Non rispondo bene a queste domande con le mie parole, quindi ho scritto sulla documentazione. Di nuovo, cosa c'è da essere offesi? Ma come vuoi tu, nero, quindi nero.
 
Andrei Novichkov:
Non ti ho mandato da nessuna parte, non me lo sognerei mai. Non sono bravo a rispondere a queste domande con parole mie, così ho scritto sulla documentazione. Di nuovo, cosa c'è da essere offesi? Ma come vuoi tu, nero, quindi nero.

Beh, la documentazione su questo è di scarsa utilità

std::launch::deferred il compito viene eseguito sul thread chiamante la prima volta che viene richiesto il suo risultato (valutazione pigra)
Non capisco davvero perché ho bisogno di un tale miracolo, posso facilmente passare un puntatore a una funzione nel thread di cui ho bisogno e calcolarlo lì senza alcun async( std::launch::deferred).
 
Vict:

Non capisco davvero perché ho bisogno di un tale miracolo, posso facilmente passare un puntatore a una funzione in un thread di cui ho bisogno e calcolarlo lì senza alcun async( std::launch::deferred).

può essere fuori tema, ma:

notato che gli esempi Microsoft sono spesso scritti come codice auto-documentato, quindi scrivono costrutti ingombranti che possono essere espansi e sostituiti con il valore finale (tipo, vedi il codice, e ottieni tutto in un colpo solo)) )

HH: Negli esempi di C# purtroppo non è così, diverse volte ho scritto C# con la convinzione che fosse di fatto un analogo del C++ con una certa propensioneall'uso dell'OOP, si scopre che non è così, non è affatto C++, spesso non si può "arrivare" ai campi della classe senza fare il casting a una classe base, è per questo che devo usare costruzioni lunghe e ingombranti, in generale, l'analisi delle librerie pronte per C# è una vera avventura!

 

Nota, per impostazione predefinita questi due flag sono applicati insieme deferred | async, che rimuove la responsabilità dallo sviluppatore. Stiamo parlando della funzione del thread principale qui, sì, potete passargli qualsiasi cosa, incluso un puntatore a una funzione, o un funtore, come argomento. E il flag differito può anche implicare l'esecuzione sincrona della funzione. Vedi, te l'ho detto, non sono bravo a rispondere a queste domande con parole mie). Ci si confonde. Di solito, si lascia tutto di default e non ci si preoccupa di queste bandiere, forse non è corretto.

 
Igor Makanu:

HH: Gli esempi di C#, purtroppo, non sono così, diverse volte ho scritto in C# confidando che fosse, di fatto, analogo del C++ con qualche tendenza all'uso obbligatoriodell'OOP, si è scoperto che non è così, non è affatto C++, spesso non puoi "arrivare" ai campi della classe senza fare il casting alla classe base, quindi devi usare strutture lunghe e ingombranti, in generale, analizzare le librerie pronte per C# è una vera avventura!

Beh, MS ha un'ottima documentazione su Spurs. Tutto è spiegato nei dettagli. Non posso lamentarmi.
 
Vict:

Beh, la documentazione su questo è di scarsa utilità

Non capisco davvero perché ho bisogno di un tale miracolo, posso facilmente passare un puntatore a una funzione in un thread di cui ho bisogno e calcolarlo lì senza alcun async( std::launch::deferred).
Bene, per esempio, avete bisogno di una funzione per calcolare i valori con i parametri attuali sullo stack, ma non ora e non in questo ambito. Quindi, si crea std::asinc, ma, ecco il problema, uno dei parametri è un riferimento o un puntatore a una variabile globale, ma nel calcolo non avrete bisogno del valore corrente di questa variabile, ma di quello che sarà più tardi, ecco perché vengono creati std::lounch::asinc e std::lounch::: bitmaskdifferito e potete passare il valore alla funzione ora ed eseguire il calcolo più tardi.
 
Vladimir Simakov:
Bene, per esempio, avete bisogno di una funzione per calcolare i valori con i parametri attuali sullo stack, ma non ora e non in questo ambito. Quindi, si crea std::asinc, ma ecco il problema, uno dei parametri è un riferimento o puntatore a una variabile globale, ma i calcoli non avranno bisogno del valore corrente di questa variabile, ma di quello che sarà più tardi, ecco perché vengono creati std::lounch::asinc e std::lounch::: bitmasks differiti e si può passare il valore alla funzione ora ed eseguire i calcoli più tardi.

Così posso prendere una funzione che passo ad async, legare gli argomenti ad essa, e memorizzarla fino a quando è il momento di chiamarla (o inviarla ad un altro thread). Che differenza fa se memorizzare il futuro o l'output di std::bind()?

L'unica spiegazione ragionevole che mi viene in mente - controllo manuale sul numero di thread in esecuzione nel pool (se non ci fidiamo del default async|deferred) - per esempio, se il sistema è troppo occupato, smettere di inviare lavori con flag async, inviare deferred.

In generale, sono un po' deluso dalla lentezza di async(), creerò il mio pool di thread leggero, mi sembra che sarà molto più veloce.