Addio robot - ciao marasma - pagina 11

Nuovo commento
 

Per quanto riguarda il nascondere il nome della variabile:

simpleton ha già scritto sul compilatore intel, situazione simile con gcc e clang. Quando si compila in modo molto rigoroso (in termini di presenza di messaggi):

gcc(clang) -Wall -Wextra

il compilatore non si lamenta di questo problema. Le lamentele sull'occultamento sono attivate con un'opzione separata -Wshadow. Cioè il controllo stesso non è difficile sui compilatori c++ (tranne MSVC). Ma non ho visto nessun ide (basato su gcc, per esempio, qt creator, code blocks ...) dove -Wshadow è attivato di default.

Perché? Probabilmente perché per la maggior parte delle persone l'utilità di questo messaggio è discutibile.

 
Pavlick:

Per quanto riguarda il nascondere il nome della variabile:

simpleton ha già scritto sul compilatore intel, situazione simile con gcc e clang. Quando si compila in modo molto rigoroso (in termini di presenza di messaggi):

Sembra che tu confonda l'ingannevole "strict compiler mode" e il lavoro effettivo degli analizzatori statici, dato che non li hai mai usati.

Il compilatore completa la compilazione in 1-2 minuti, mentre gli analizzatori lavoreranno per diverse ore (PVS Studio) o decine di ore (CPP Check) sullo stesso codice. Da qui la diversa qualità e profondità dei risultati.

 

Saluti a tutti.

È passato quasi un anno da quando il "pazzo" e marasma di innovazioni in MQL4 non si è fermato. "Ma è ancora lì! (с).

Prima incolpavano "Metaquotes" per il linguaggio povero, ora li incolpano per l'eccessiva "acqua". I problemi non sono diminuiti.

Posso aggiungere quanto segue da parte mia.

Per i commercianti, i non programmatori e i programmatori principianti, è possibile implementare un semplice algoritmo e un codice.

Se avete una grande base di indici, gufi, ecc. che non si compilano nelle nuove build, allora ha senso guardare da vicino e "scuotere le vostre casse". Assicuratevi di salvare le cose più utili e non perdete tempo a riscriverle e debuggarle per le nuove build.

I veri programmatori esperti o quelli che vogliono diventarlo, seguono sempre le innovazioni, i bug e i glitch sono il loro pane. È scrivere codice senza bug che conta come buona programmazione. Se non avete l'energia, il tempo, la possibilità o il desiderio di afferrare tutte le innovazioni di "Metakvot", usate la lingua che conoscete bene. Le DLL non sono state abolite, inseriteci i vostri algoritmi messi a punto.

 
Andrei01:

Gli ambienti di test sono ampiamente utilizzati nei prodotti software per la verifica funzionale dei progetti di chip software, dove i requisiti di qualità del codice sono molto alti. Inoltre, una shell funzionale è parte integrante di qualsiasi sviluppo di codice di progettazione di chip. D'altra parte, molti programmatori non hanno nemmeno idea di questi test funzionali quando scrivono i soliti progetti software, perché scrivere questi test da zero può richiedere più tempo che quando si scrive il progetto stesso ed è giustificato solo quando c'è un requisito per scrivere codice di alta qualità o ci sono molte versioni dello stesso progetto. D'altra parte, un ambiente di test abilmente scritto risparmia significativamente il tempo del debug e della verifica del codice.

L'analisi statica è anche usata, ma solo come controllo sintattico iniziale e molto superficiale.

Gli ambienti di prova sono ambienti di prova. Un ambiente di test è "confinato" al prodotto che sta testando.

Intendevo strumenti generali - quelli che "non hanno idea" del prodotto da analizzare e quindi possono analizzare e trovare problemi in qualsiasi prodotto.

 
Renat:

Sempliciotto, che sciocchezza.

"Che sciocchezza" sembra implicare una completa discrepanza di atteggiamenti.

Renat:

Quando si arriva al livello del controllo di qualità totale, solo allora lo si capirà. Ma nel frattempo, finché si rimane al livello di percezione di un singolo programmatore egoista, si continuerà a pensare "è ragionevole non controllarmi, lasciamo che il controllo sia da utility separate mai eseguite".

Allora perché il "controllo totale della qualità" permette un livello così basso di controllo della qualità?

Per esempio:

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }

public:
  static void method1() {
    //A a; // 'A::A' - cannot call private member function      3.mq4   10      7
  }

  static void method2() {
    A *a = new A; // А здесь private member function великолепно вызывается
    delete a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method1();
  A::method2();
}

Il costruttore viene chiamato quando viene creato un oggetto nel metodo2:

00:50:23 Script 3 EURUSDm,M5: loaded successfully
00:50:23 3 EURUSDm,M5: initialized
00:50:23 3 EURUSDm,M5: A::A()
00:50:23 3 EURUSDm,M5: uninit reason 0
00:50:23 Script 3 EURUSDm,M5: removed

Perché tutto va bene quando un oggetto viene creato dinamicamente, cioè il costruttore privato è disponibile dal metodo dell'oggetto, ma quando l'oggetto viene creato automaticamente, il costruttore privato è improvvisamente non disponibile?

Personalmente ho rinunciato a fare qualsiasi cosa un po' più complicata del semplice in MQL, perché è molto difficile per me: mi imbatto sempre in qualcosa che non funziona.

Ma non ho questi problemi con i compilatori C/C++.

E il problema "è ragionevole non controllarmi, lasciare che il controllo sia separato non gestire mai le utilità" è direttamente legato alla psicologia. Qui la psicologia deve essere corretta in modo che il programmatore possa imporsi, piuttosto che cercare di adattare la tecnologia alla psicologia per aggirare questa psicologia.

Non me lo invento, alcune utility sono utilizzate con successo su base regolare davanti a me, e il risultato del loro lavoro è anche utilizzato con successo in seguito per eliminare i bug.

Renat:

I glitch vengono combattuti, ma in parallelo stiamo aggiungendo e migliorando molto.

Forse le priorità sono spostate verso l'aggiunta e il miglioramento a scapito della qualità. Ma allora non è più un controllo totale di esso.

Renat:

Venerdì ci sarà una release di MT4 con chiari miglioramenti nella velocità di esecuzione e nei test.

In questo caso intendo la disponibilità del costruttore privato dai metodi dell'oggetto non solo per il caso della creazione dinamica dell'oggetto - ci saranno miglioramenti nell'operatività del linguaggio?

Renat:

A differenza del C++, MQL è assolutamente sicuro (se non c'è un output alla DLL) a causa del rifiuto dei link grezzi, e in generale - è un linguaggio gestito.

Ok, assumiamo che "C++ è pericoloso e suicida" e "MQL è assolutamente sicuro".

Perché prendere come base per MQL un linguaggio che è così lontano dal criterio di sicurezza da quello che si voleva, cioè creare un linguaggio "assolutamente sicuro" basato esattamente su quello "pericoloso e suicida"?

 
Pavlick:

VA BENE?


Ciao, Pavlik!

sono ancora io panza!

Ho provato il tuo codice per chiamare lo script su diversi mt4

e ho scoperto delle cose strane!

Il tuo codice funziona bene su MT4 build 670 di Pepperston

(Australia), ma non vuole funzionare su MT4 build 670 Alpari!

user32.dll èchiamatostranamentesu alpari!

Vengono chiamate le prime 2 DLL (anche se questo non era nel codice!)

allorauser32.dllviene chiamato,ma viene gettato in una libreria!

ma dovete anche chiamarlo dalla biblioteca!

Sembra che Alpari stia lottando con la chiamata.

cioè c'è un'evidente interferenza del codice!

Allego 2 foto per il confronto!

auguro il successo!

Panza

oo-bild zu gross!

MT4-Pepperstone-user32.dll

MT4-Alpari-KERNEL32.dll,GDI.dll,E:\metaQuotes\Terminal\F................OBO\MQL4\Libraries\user32.dll

















 
simpleton:

"Che assurdità" - questo significa apparentemente una completa discrepanza di posizioni.

Questo significa che qualcuno è consapevolmente più esperto nel dirigere il rilascio di più prodotti software per un mercato concorrente.


Perché il "controllo totale della qualità" permette un livello così basso di controllo della qualità?

Non c'è bisogno di passare da una discussione sui principi generali di controllo della qualità ai difetti specifici di una soluzione particolare. Tale metodo è inaccettabile, perché è sempre possibile trovare qualsiasi difetto in qualsiasi prodotto.

Per esempio:

Il costruttore viene chiamato quando viene creato un oggetto nel metodo2:

Perché tutto va bene quando un oggetto viene creato dinamicamente, cioè il private-constructor è disponibile dal metodo dell'oggetto, ma quando un oggetto viene creato automaticamente, il private-constructor è improvvisamente non disponibile?

Questa è solo una conseguenza dell'iperprotezione"il metodo statico della classe non ha il diritto di entrare nei contenuti della classe". In questo caso, però, il controllo dell'accesso deve essere allentato.

Personalmente ho rinunciato a fare qualcosa di leggermente più complesso del semplice in MQL, perché è molto difficile per me: mi imbatto sempre in qualcosa che non funziona.

Datemi un esempio funzionante, e non un caso di "ho stravolto le cose di proposito, ho chiuso gli accessi e poi ho iniziato ad appellarmi al comportamento borderline".


Non ho questi problemi con i compilatori C/C++, però.

I problemi lì sono di un altro tipo. E sono consapevolmente maggiori di ordini di grandezza se si tiene conto che non si usano analizzatori statici.


E il problema "è ragionevole non controllarmi, lasciare che il controllo sia separato non gestire mai le utenze" è direttamente legato alla psicologia. Qui la psicologia deve essere corretta in modo che il programmatore possa imporsi, piuttosto che cercare di adattare la tecnologia alla psicologia per aggirare questa psicologia.

Non me lo invento, singole utility sono utilizzate con successo su base regolare sotto i miei occhi, e il risultato del loro lavoro è utilizzato con successo anche dopo per eliminare i bug.

Forse le priorità sono spostate verso l'aggiunta e il miglioramento a scapito della qualità. Ma allora non è più un controllo totale di esso.

È già solo un gioco di parole. La tua posizione è già stata chiaramente delineata prima "non posso essere controllato", quindi sì "davanti a qualcuno, da qualche parte si sta usando, ma nessuno sta sopra di me con un bastone e io non sto usando".


E i miglioramenti in termini di operabilità del linguaggio - in questo caso intendo la disponibilità di un costruttore privato dai metodi dell'oggetto non solo per il caso della creazione dinamica dell'oggetto - avrà già?

E vi piace fare degli sgambetti deliberati nei vostri programmi "semplici": "nascondo il costruttore in privato, creo un metodo statico e poi lo uso per cesellare il costruttore nascosto"?


Ok, assumiamo che "C++ è pericoloso e suicida" e "MQL è assolutamente sicuro".

Perché prendere un linguaggio così lontano dal criterio di sicurezza come base del MQL, cioè creare un linguaggio "assolutamente sicuro" sulla base di quello molto "pericoloso e suicida"?

Siete in grado di trovare una "base diversa" per un linguaggio generico?

In modo che ogni altro programmatore possa ricevere il linguaggio e iniziare a scriverci con piacere dopo un paio d'ore e non buttarlo via con disgusto e rimprovero? I trader hanno guardato il linguaggio facile e l'hanno buttato via, mentre MQL4/MQL5 vengono usati e sviluppati con grande piacere.

I linguaggi più comunemente usati si basano sui principi di base dei costrutti come in C/C++. Così abbiamo preso il noto framework, rimosso le cose più pericolose con i link, aggiunto DRM e ottenuto un linguaggio sicuro e protetto.

Di conseguenza, noi siamo in crescita e i concorrenti vanno nelle direzioni sbagliate, ma più economiche, come pensano loro.

 
Renat:
Significa che qualcuno ha più esperienza nel gestire il rilascio di molti prodotti software in un mercato competitivo.

A proposito, riguardo all'esperienza di gestione. 5 anni fa abbiamo discusso sul forum mql5 sulle prospettive di MT5, ho detto allora che il tempo lo dirà. Sono passati cinque anni e vediamo che la comunità ha rifiutato MT5. L'esperienza di gestione non garantisce contro gli errori. Anche se si ha esperienza in un settore, si possono fare degli errori. A proposito del mercato concorrente, o meglio dei concorrenti, alla fine.

Tuttavia, in questo caso, non è una questione di esperienza in molti prodotti software, ma della qualità del prodotto e, in particolare, del compilatore e degli strumenti e metodi per raggiungere un'alta qualità.

Renat:
Non dovremmo spostare la discussione dai principi generali di controllo della qualità ai difetti specifici di una particolare soluzione. Non potete farlo perché è sempre probabile che troviate tutti i difetti di ogni prodotto.


Questa è solo una conseguenza dell'iperprotezione "il metodo statico della classe non ha il diritto di entrare nei contenuti della classe". Anche se in questo caso dobbiamo allentare il controllo degli accessi.

Non sto traducendo, principi generali, teoria - non per la teoria stessa, ma per l'applicazione nella pratica. Non troverete "difetti" così gravi negli stessi compilatori C/C++.

Se dite che in questo caso "un metodo statico di classe non ha il diritto di entrare nel contenuto della classe", allora perché in caso di creazione dinamica di un oggetto ha già questo diritto?

Che dire del fatto che un metodo non statico si comporta esattamente allo stesso modo?

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }

public:
  void method() { // Метод - обычный, никакой не статический
    A a;
  }

};

/******************************************************************************/
void OnStart() {
}

Stessi errori:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

Ok, consideriamo il divieto di "salire sul contenuto della classe":

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }
  A(const A &a) { Print("A::A(const A &)"); }
  void operator =(const A &a) { Print("A::operator =()"); }
  void f() { Print("A::f()"); }

public:
  static void assign(A &l, const A &r) {
    l = r;
  }

  static void method() {
    A *p = new A, b(p);

    b = p;
    b.f();
    delete p;
  }

};

L'oggetto b viene creato chiamando il costruttore copy, poi viene eseguita un'assegnazione chiamando l'"operatore =", viene chiamato il metodo f(), e tutti questi costruttori, operatori e metodi sono privati, il che significa che il metodo statico() è autorizzato ad "accarezzare la classe":

00:59:18 Script 3 EURUSDm,M5: loaded successfully
00:59:18 3 EURUSDm,M5: initialized
00:59:18 3 EURUSDm,M5: A::A()
00:59:18 3 EURUSDm,M5: A::A(const A &)
00:59:18 3 EURUSDm,M5: A::operator =()
00:59:18 3 EURUSDm,M5: A::f()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: uninit reason 0
00:59:18 Script 3 EURUSDm,M5: removed

Vediamo un altro esempio, molto vicino al primo:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Errore di compilazione, - sia il costruttore che il distruttore non sono disponibili:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

Ora, senza cambiare nulla, inizializzate la variabile a con un valore diverso da quello di default nel costruttore:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a(1);
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Ora l'esempio viene compilato ed eseguito:

00:20:35 Script 3 EURUSDm,M5: loaded successfully
00:20:35 3 EURUSDm,M5: initialized
00:20:35 3 EURUSDm,M5: A::A(int i = 1)
00:20:35 3 EURUSDm,M5: A::~A()
00:20:35 3 EURUSDm,M5: uninit reason 0
00:20:35 Script 3 EURUSDm,M5: removed

Come ha fatto un metodo statico a diventare improvvisamente autorizzato a "entrare nel contenuto della classe"?

È abbastanza ovvio che in questo caso non si tratta di una "iperprotezione", ma di un banale bug. Il controllo totale della qualità è un'affermazione piuttosto forte, ma i fatti sono cose testarde.

Renat:
Dai un esempio di lavoro, non un caso di "ho fatto le cose in questo modo di proposito, ho chiuso gli accessi e poi ho iniziato a fare appello al comportamento limite".

Per favore, un singleton classico, cioè il singleton Myers descritto nella sezione di esempio C++ del link:

class OnlyOne
{
public:
        static const OnlyOne& Instance()
        {
                static OnlyOne theSingleInstance;
                return theSingleInstance;
        }
private:        
        OnlyOne(){};
        OnlyOne(const OnlyOne& root);
        OnlyOne& operator=(const OnlyOne&);
};

Si traduce anche in MQL4++ con la nuova funzione aperta:

#property strict

/******************************************************************************/
class OnlyOne
{
public:
        static OnlyOne *Instance()
        {
                static OnlyOne theSingleInstance(1);
                return GetPointer(theSingleInstance);
        }
private:        
        OnlyOne(int i = 0) { Print("Создан"); };
        ~OnlyOne() { Print("Уничтожен"); };
        OnlyOne(const OnlyOne &);
        void operator=(const OnlyOne &);
};

/******************************************************************************/
void OnStart() {
  OnlyOne *p = OnlyOne::Instance();
}

Compila ed esegue:

01:31:49 Script 3 EURUSDm,M5: loaded successfully
01:31:49 3 EURUSDm,M5: Создан
01:31:49 3 EURUSDm,M5: initialized
01:31:49 3 EURUSDm,M5: uninit reason 0
01:31:49 3 EURUSDm,M5: Уничтожен
01:31:49 Script 3 EURUSDm,M5: removed

I tentativi di creare un oggetto in qualsiasi modo diverso dalla chiamata a OnlyOne::Instance() risulterà in un errore di compilazione.

E a proposito di "ho stravolto le cose così deliberatamente, ho chiuso gli accessi e poi ho iniziato ad appellarmi al comportamento limite" - è stato usato qualcosa in modo improprio?

Ci sono dei meccanismi nella lingua - ho il diritto di usarla come voglio nei limiti consentiti dalla lingua. Almeno è così con i compilatori C++.

Se ci sono errori nell'implementazione della lingua, beh, sì, errori. Stai parlando di controllo totale della qualità - quindi in pratica sbarazzati degli errori di implementazione nel compilatore MQL4++, in modo che gli errori siano quasi difficili da trovare come nei compilatori C++, dato che hai tale controllo. Continuo a credere che il parser non aiuterà a sbarazzarsi di errori come quelli che ho dimostrato.

Renat:
E vi piace mettere dei passi deliberati nei vostri programmi "semplici" "nascondere il costruttore in privato, creare un metodo statico e poi cesellare il costruttore nascosto da esso"?

Non si tratta di quello che mi piace o non mi piace. C'è uno strumento. Perché dovrei rifiutare di usare tutte le sue capacità?

Non è nemmeno "mi piace" in questo caso. È Myers, del resto, a cui piace così tanto. E in qualche modo nessuno cerca di accusarlo di cercare di "incastrare deliberatamente" i compilatori C++.

Renat:
Siete in grado di proporre un "quadro diverso" per i linguaggi generici?

In modo che ogni altro programmatore possa ricevere un linguaggio e iniziare a scriverci con piacere dopo un paio d'ore e non buttarlo via con disgusto e rimproveri? I trader hanno guardato il linguaggio facile e l'hanno buttato via, mentre MQL4/MQL5 sono felicemente usati e sviluppati.

I linguaggi più diffusi si basano sui principi di base dei costrutti come in C/C++. Quindi abbiamo preso una struttura familiare, rimosso le cose più pericolose con i riferimenti, aggiunto DRM e ottenuto un linguaggio sicuro e protetto.

Di conseguenza, siamo in cima, mentre i nostri concorrenti vanno nella direzione sbagliata, ma più economica, come pensano loro.

Non è un compito facile e non può essere risolto subito. Qui bisogna mettere un po' di impegno, e non poco. La stragrande maggioranza degli utenti di MQL non sono programmatori. Questo deve essere preso in considerazione nella progettazione della lingua. Ma il compito può essere risolto, ne sono sicuro.

Semmai, basterebbe aggiungere alcune strutture al vecchio MQL4 e pulire alcune cose come le priorità alle operazioni, come è stato fatto per MQL4++ e questo sarebbe un compromesso ragionevole. Il successo di MT4 era in gran parte dovuto alla mancanza di "intelligenza" del linguaggio. Questo non è il caso ora. E ci sono molti più errori nell'implementazione del compilatore, perché MQL4++ è molto più complicato del vecchio MQL4 e il team di sviluppo non è cambiato molto.

Renat:
Di conseguenza, noi siamo al rialzo mentre i nostri concorrenti vanno nella direzione sbagliata, ma più economica, come credono loro.

Qui sono d'accordo con te, ma penso che sia soprattutto perché i concorrenti fanno cose incomprensibili.

 
Renat:
Questo significa che qualcuno è consapevolmente più esperto nel dirigere il rilascio di molti prodotti software al mercato concorrente.


Non abbiamo bisogno di spostare l'argomento dalla discussione dei principi generali di controllo della qualità ai difetti specifici di una particolare soluzione. Tale metodo è inaccettabile, perché è sempre possibile trovare qualsiasi difetto in qualsiasi prodotto.

Questa è solo una conseguenza dell'iperprotezione "un metodo statico di classe non ha il diritto di entrare nel contenuto della classe". Anche se in questo caso è necessario allentare il controllo degli accessi.

Dacci un esempio funzionante, non un caso di "ho stravolto tutto di proposito, bloccato gli accessi, e poi fatto appello al comportamento limite" tipo.


I problemi lì sono di un altro tipo. E sono consapevolmente maggiori di ordini di grandezza se si tiene conto che non si usano analizzatori statici.


Questo è già solo un gioco di parole. La tua posizione è già stata chiaramente delineata prima "non posso essere controllato", quindi sì "davanti a qualcuno, da qualche parte usando, ma nessuno sta sopra di me con un bastone e non sto usando".


Vi piace mettere dei passi deliberati nei vostri programmi "semplici" "nascondere il costruttore in privato, creare un metodo statico e poi cesellare il costruttore nascosto da esso"?


Siete in grado di trovare una "base diversa" per le lingue commonplan?

In modo che ogni altro programmatore possa ricevere un linguaggio e iniziare a scriverci con piacere dopo un paio d'ore e non buttarlo via con disgusto e rimprovero? I trader hanno guardato il linguaggio facile e l'hanno buttato via, mentre MQL4/MQL5 sono felicemente usati e sviluppati.

I linguaggi più diffusi si basano sui principi di base della costruzione come in C/C++. Così abbiamo preso il ben noto framework, rimosso le cose più pericolose con i link, aggiunto DRM e ottenuto un linguaggio sicuro e protetto.

Di conseguenza, siamo in cima, mentre i nostri concorrenti vanno nella direzione sbagliata, ma più economica, come pensano loro.

 

Ciao membri del forum!

Vorrei approfittare della presenza di Renate su questo thread

Vorrei dare alcuni suggerimenti per migliorare MT4!

Tutti sanno che col tempo MT4 funziona sempre peggio.

allora non obbedisce al mouse - finito!

Dobbiamo passare a un nuovo MT4 e rimuovere

tutta la roba (indicatori, eXperts)!

Questo è un lavoro di un giorno!

Anche se ora ci sono programmi di riparazione per DL, DRIVER, ecc...

Perché non fare un compilatore per MT4?

Devi avere 2 МТ4 (uno valido e l'altro funzionante)

e confrontarli periodicamente e correggere gli errori nell'MT4 funzionante.

Il secondo suggerimento è quello di costruire non solo grafici di prezzo ma

produrre il prezzo moltiplicato per i grafici di crescita del volume!

In questo modo saresti immediatamente visibile cosa sta succedendo (trading reale o incassare

stoppie)

Penso che sia facile per le persone con un alto livello di comprensione!

Panza

1...45678910111213141516
Nuovo commento