Suggerimenti per la sintassi MQL - pagina 10

Nuovo commento
 
È divertente leggere tutto questo. Ricordo le grida dei vecchi compagni quando hanno deciso di introdurre classi, "puntatori" e strutture in MQL. Scrivevano: "Avete ucciso MQL! Ora solo i professionisti potranno scriverci dentro...". - e altre sciocchezze. Ora urlano dall'altra parte: lasciatemi avere un C++ completo mentre il mega-sistema è impossibile da codificare. Ma chi vi impedisce di farlo? Prendi C++ e vai per la tua strada. Il MQL è un po' un'altra storia ed è ingenuo mescolare il caldo e il freddo.
 

Cosa stai dicendo di C++... Se non ti piace C++, prendi C#. L'ho specificatamente menzionato nel mio post originale e più avanti nelle discussioni l'ho sottolineato. Molte delle cose suggerite riguardano entrambi i linguaggi.

Quindi una delle due cose: o sei contro il progresso in linea di principio o semplicemente brontoli. Anche se entrambe le varianti sono anche possibili

 
Alexey Navoykov:

...

MetaTrader è un buon terminale. Ma purtroppo, la stragrande maggioranza dei suoi utenti sono ancora perdenti e giocatori d'azzardo. MQ ha fatto un grande sforzo per entrare nella nicchia dello smart trading, ma non ha avuto successo. Gli scommettitori hanno solo bisogno di un "poke" MT4 con qualche "TrendLaser" multicolore sul grafico. A loro non interessano le strutture, le classi, le specialità con declinazione, ecc. Ma "un vello di una pecora sottile" - è così che viviamo. Quindi, in questa situazione, non è economicamente fattibile sviluppare le caratteristiche della lingua in MQL5. Ma sarebbe ragionevole flirtare con la folla, per esempio introdurre blocchi in MT5 o Open[0] invece di CopyRates.

 

In realtà, questo è un po' strano. Originariamente, MQL è stato creato come un linguaggio applicativo per scrivere strategie di trading. Pertanto, non conteneva tutto ciò che ha il C++. Ma col tempo, i compiti nel trading algoritmico sono diventati più complicati, e le persone cercano e aspettano le aggiunte al linguaggio. Così, tendono a mettere tutto ciò che non è stato aggiunto intenzionalmente. Così facendo, il numero di regole e il livello di complessità della lingua aumenteranno, diventando una barriera per se stessi. Ma, se sono disposti a superarli, non c'è modo di fermarli.

Per me, lo sviluppo consiste prima di tutto nel trovare il modo giusto e più semplice per implementare un pensiero. Come tale, le capacità del vecchio linguaggio sono abbastanza buone, ma i programmatori professionisti sentono la nostalgia del cumulo di regole e dei mucchi di sintassi. )) Beh, se dà loro l'ispirazione - perché no?

 
Реter Konow:

Allo stesso tempo, il numero di regole e il livello di complessità della lingua aumenteranno, diventando una barriera per loro.

Perché una barriera? L'aggiunta di nuove funzioni non impedisce loro di usare quelle vecchie. Di regola, nessuno è obbligato a usare queste "complessità".

Anche se ci sono stati certamente periodi in cui le regole stabilite sono state improvvisamente alterate senza pietà a beneficio del C++, ma quello era il periodo del suo rapido sviluppo. Ora il linguaggio ha quasi tutto e rimangono solo piccole modifiche.

 

A proposito, personalmente sento non solo la mancanza di miglioramenti, ma anche la riduzione delle caratteristiche della lingua nell'ultimo anno e mezzo. La build più funzionale e stabile è stata la 1554, datata 14 marzo 2017.Dopo di che c'è stata una riprogettazione radicale degli interni, e ci sono state build problematiche con un sacco di bug, alcuni dei quali non sono stati risolti fino ad oggi. Tuttavia, alcuni dei vecchi bug sono stati risolti. In generale, il livello dei bug delle build attuali è probabilmente leggermente migliore. Ma riguardo alla funzionalità...

Per esempio, ho già scritto del taglio della possibilità di lanciare gli array ai tipi di base. Un altro taglio è stato il divieto di lanciare strutture semplici tra di loro. Sì, sono state sostituite da unità, ma non coprono le possibilità date dal cast che permetteva di compensare gli svantaggi della funzionalità regolare. Dato che MQL non ha interfacce per le strutture (ne ho già scritto), questa soluzione era una buona alternativa:

template<typename T>
struct IValueable
{ 
  double Value() const { return ((T)this).GetValue(); }
 protected:
  IValueable() { }
 private:
  static void Check_IValueable() { T::Check_IValueable(); }  // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
  double _value;

  A(double value) { _value=value; }
  
  double GetValue() const { return _value; }
};


void Func(IValueable<A> &a) { Print(a.Value()); }


void OnStart()
{
  A a(10);
  Func(a);
}
 
Alexey Navoykov:

Perché una barriera? L'aggiunta di nuove funzioni non impedisce di usare quelle vecchie. Di regola, quindi nessuno è costretto a usare queste "complessità".

Anche se naturalmente ci sono stati momenti in cui regole ben stabilite sono state improvvisamente riscritte senza pietà per il bene del C++, ma quella era l'epoca del suo rapido sviluppo. Ora abbiamo quasi tutto e rimangono solo piccole modifiche.

Intendevo una barriera per coloro che vogliono usare le nuove regole e la sintassi da soli. Dovranno scrivere i loro programmi più a lungo e impiegare più tempo per capirli. Questo renderà i loro programmi più efficienti? - Non proprio. Saranno in grado di risolvere un numero maggiore di compiti? - Non proprio.

Una volta ho proposto su un forum una soluzione molto semplice di un compito che tutti risolvevano con una montagna di codice. Era piccolo e veloce. Tuttavia, non è piaciuto a tutti. Non aveva quelle cose che piacevano a loro. Tutti i tipi ditemplate<typename T> evoid Func(IValueable<A> &a)

Mi è stato offerto di usarli tutti. Quando ho chiesto "perché?" nessuno ha spiegato niente di chiaro.


P.S. La spiegazione più chiara che ho ricevuto è stata: "Il tuo codice è brutto". E un'altra cosa: "Non capite il potere concettuale". Ma io sono uno sviluppatore. Ho bisogno di una bella soluzione, non di un bel codice.

 
Alexey Navoykov:

Sì, sono stati sostituiti dalle unioni, ma non coprono le possibilità che sono state fornite dalla conversione, che ha permesso di compensare le carenze della funzionalità standard. Dato che MQL non fornisce interfacce per le strutture (ne ho già scritto), questa soluzione era una buona alternativa:

Questo compila.

#include <TypeToBytes.mqh>

template<typename T>
struct IValueable
{ 
  uchar Tmp;
  double Value() const { return (_C(T, this)).GetValue(); }
 protected:
//  IValueable() { }
 private:
  static void Check_IValueable() { T::Check_IValueable(); }  // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
  double _value;

//  A(double value) { _value=value; }
  void Set( double value ) { _value=value; }
  
  double GetValue() const { return _value; }
};

Ma il risultato, ovviamente, è diverso.

1...345678910
Nuovo commento