Errori, bug, domande - pagina 2746

Nuovo commento
 
Koldun Zloy:

No. Non è ancora noto al momento della compilazione.

Allora come si fa ad evitare un numero enorme di controlli quando SymbolInfoTick viene chiamato decine di miliardi di volte?

[Eliminato]  
fxsaber:

Allora come si fa ad evitare un numero enorme di controlli quando SymbolInfoTick viene chiamato decine di miliardi di volte?

Non è così. Aiuta solo a non copiare inutilmente la stringa stessa.

 
Koldun Zloy:

No. Aiuta solo a non copiare inutilmente la stringa stessa.

Allora ovviamente la soluzione di riferimento alle stringhe per le funzioni SymbolInfo è quella giusta, se si vuole più efficienza dall'ottimizzatore.

 

Il mio debugger si rifiuta di funzionare in uno dei miei progetti. Inoltre, il suo comportamento è difficile da prevedere. A volte si rifiuta semplicemente di inserire i breakpoint. Si rifiuta anche di inserire alcune funzioni. All'inizio ho pensato che la ragione fossero gli aggiornamenti (forse qualcosa è andato storto con il debug). Ma in altri programmi più semplici tutto sembra funzionare. Non l'ho controllato molto, però, perché sto lavorando al mio progetto principale. È abbastanza complesso e comprende 15 moduli solo di mia progettazione (non ho contato il numero di moduli standard). Il modulo principale contiene fino a 2000 linee. Ho pensato che forse è tutta una questione di complessità del progetto... Inoltre, in alcuni posti uso macro per frammenti di codice ripetitivi. Inoltre uso elementi standard di UI, come CAppDialog, CCheckGroup, CComboBox, CButton ecc. che ho riscritto per la funzionalità del mio programma. Forse il debug non funziona a causa loro... Per esempio, il metodo CCheckGroup::itemCheckState(const string item), che ho scritto appositamente, non viene debuggato. Il metodo trova l'elemento della casella di controllo e controlla se è selezionato (il suo stato):

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int CCheckGroup::itemCheckState(const string item) {
  int total = m_strings.Total();
  
  if(total != m_states.Total())
    return -1;
    
  int i = 0;
  for(; i < total; i++) {
    if(m_strings.At(i) == item)
      return m_states.At(i);
  }
  
  return -1;
}

Questo è il tipo di UI che ho finito per ottenere:

UI

Alcuni elementi dell'UI sono temporaneamente classificati. Ed ecco un ramo dove ho descritto come ho scavalcato i metodi Show() e Hide() dell'elemento CAppDialog:https://www.mql5.com/ru/forum/338301 Il compilatore si è lamentato in quel momento e si è verificato un errore critico.

Alla fine il progetto si compila normalmente, il compilatore non genera alcun errore. Ma il debug fallisce e non mostra l'esecuzione di alcuni frammenti di codice, funzioni, metodi e così via.

Per quanto ho capito, ci possono essere diverse ragioni per questo.

  1. Codice complicato del progetto, uso di macro
  2. Codice complicato usando elementi standard dell'interfaccia, come CAppDialog, CCheckGroup, CComboBox, CButton (per i quali ho anche scritto nuovi metodi e ridefinito alcuni di quelli esistenti)
  3. Bug del debugger legato alla nuova build (possibile, improbabile).

Informazioni sulla costruzione e sul sistema:

2020.05.21 09:35:09.325 Terminal MetaTrader 5 x64 build 2433 started for MetaQuotes Software Corp.

2020.05.21 09:35:09.326 Terminal Windows 10 build 14393, Intel Core i5-5200U @ 2.20GHz, 2 / 3 Gb memoria, 61 / 380 Gb disco, IE 11, UAC, GMT+2

Qualcuno ha avuto problemi simili con il debugger e quale potrebbe essere la causa?
 
fxsaber:

È ovvio quindi che una soluzione di riferimento alle stringhe per le funzioni SymbolInfo è quella giusta, se si vuole più efficienza dall'ottimizzatore.

Tutto viene comunque passato per riferimento. La differenza era solo nell'antico MQL4. E non ci sono controlli durante la lettura delle stringhe.
 
Alexey Navoykov:
Questo link non ha senso, lo ha detto lo sviluppatore. Tutto viene passato dal link così com'è. L'unica differenza era nell'antico MQL4. E non ci sono controlli durante la lettura della stringa.

È solo faticoso fare affermazioni del genere.

int f1( string Str )
{
  return((Str += Str) == Str);
}

int f2( string &Str )
{
  return((Str += Str) == Str);
}

int Bench1( const int Amount = 1 e8 )
{
  int Res = 0;
  string Str = NULL;
  
  for (int i = 0; i < Amount; i++)
    Res += f1(Str);
    
  Print(Res);
    
  return(Res);    
}

int Bench2( const int Amount = 1 e8 )
{
  int Res = 0;
  string Str = NULL;
  
  for (int i = 0; i < Amount; i++)
    Res += f2(Str);

  Print(Res);
    
  return(Res);    
}

void OnStart()
{
  BENCH(Bench1())
  BENCH(Bench2())

  BENCH(Bench1())
  BENCH(Bench2())
}


        100000000
        Time[Bench1()] = 727585
        100000000
        Time[Bench2()] = 657464
        100000000
        Time[Bench1()] = 794205
        100000000
        Time[Bench2()] = 670440
 
fxsaber:

È solo fastidioso fare affermazioni del genere.


Forse è più facile da scrivere:

int f1( string Str )
{
  return(Str == NULL || Str == "");
}

?...

Perché bere qualcosa del genere?

int f1( string Str )
{
  return((Str += Str) == Str);
}
 
Mihail Matkovskij:

Può essere più facile da scrivere:

C'è un altro tipo di discussione.

 
fxsaber:

È solo faticoso fare affermazioni del genere.

Per non essere infondato, dammi un punto di riferimento in cui la stringa non cambia.
 
TheXpert:
Per evitare di essere insostenibile, datemi un punto di riferimento per i test in cui la stringa non cambia.
int f1( const string Str )
{
  return(Str + "1" != Str);
}

int f2( const string &Str )
{
  return(Str + "1" != Str);
}
        10000000
        Time[Bench1()] = 334596
        10000000
        Time[Bench2()] = 338559
        10000000
        Time[Bench1()] = 384711
        10000000
        Time[Bench2()] = 344346
1...273927402741274227432744274527462747274827492750275127522753...3184
Nuovo commento