Errori, bug, domande - pagina 1953

[fxsaber]

Alexey Navoykov:

In generale, ammetto con rammarico che il compilatore MQL non è così intelligente come pensavo). Ho provato a fare alcuni semplici esempi e ho scoperto che anche se creo un oggetto fittizio, che non è usato da nessuna parte e non fa nulla, il compilatore non se ne preoccupa. Non è ottimizzato per niente. Sto giudicando solo dalla velocità. E per qualche motivo funziona più lentamente nelle nuove build che in quelle vecchie.

Gli sviluppatori ne sono consapevoli. Ma tale ottimizzazione da parte del compilatore è lontana dalla priorità dei compiti da risolvere.

Ci sono anche queste ambiguità del compilatore.

[Alexey Navoykov]

fxsaber:

Gli sviluppatori ne sono consapevoli. Ma tale ottimizzazione da parte del compilatore è lontana dall'essere una priorità dei compiti da risolvere.

Sì, ma è semplicemente incredibile: prima si vantavano tanto di aver portato la qualità dell'ottimizzatore a livelli mai visti prima, ma in realtà non è in grado di gestire nemmeno cose così semplici. Per non parlare di quelli più complessi.

[Alexey Navoykov]

fxsaber:

Ecco perché propongo di aggiungere a OnTesterInit la possibilità di cambiare la tabella dei passaggi predefinita:

int PassesSet( const int Index, const MqlParam& Parameters[] );

Presumo che gli stessi set di parametri non siano memorizzati nel sistema, ma siano calcolati dal numero unico della combinazione (ora coincide con il numero di passaggio). Quindi è possibile cambiare solo l'ordine delle combinazioni, ma non la loro composizione. Quindi, in questo caso, sarebbe qualcosa come SwapPasses(long indexx1, long index2).

Ma potrei sbagliarmi.

[fxsaber]

Alexey Navoykov:

Presumo che i set di parametri stessi non siano memorizzati nel sistema, ma siano calcolati utilizzando il numero di combinazione unico (ora coincide con il numero di passaggio). Pertanto, si può solo cambiare l'ordine delle combinazioni, ma non la loro composizione. Cioè in questo caso sarebbe qualcosa come SwapPasses(long indexx1, long index2).

Questo può essere il caso. Ora l'ordine può ancora essere in qualche modo influenzato dalle linee di ingresso Swap nel sorgente EA.

[Stanislav Korotky]

fxsaber:

Questo può essere il caso. Ora l'ordine può essere in qualche modo influenzato da Swap input lines nel codice sorgente EA.

Uccide l'algoritmo di ottimizzazione - è come ottimizzare in direzione casuale.

[fxsaber]

Stanislav Korotky:

Questo uccide l'algoritmo di ottimizzazione - è come ottimizzare in una direzione casuale.

Stiamo parlando di un superamento completo in primo luogo.

[[Eliminato]]

Sto lentamente imparando l'OOP e mi sono imbattuto in una cosa non ovvia.

C'è una classe A, i cui campi sono oggetti di un'altra classe B.

Nella classe A, viene chiamato un metodo costante che restituisce un oggetto della classe B.

Dopo di che, viene chiamato un metodo della classe B, che cancella i parametri dell'oggetto restituito.

Si presenta così (l'esempio è semplificato, scritto nel browser):

class B
{
private:
   int m_width;
   int m_length;
public:
   void Reset() { m_width = 0; m_length = 0; }
}
class A
{
private:
   B m_member;
public:
   B GetBMember() const { return( m_member ); }
}
//---
A obj;
obj.GetBMember().Reset();

Di conseguenza, risulta che Reset() non funziona, cioè i campi m_member non vengono cancellati.

Domanda: il compilatore non dovrebbe segnalare (errore/avviso) in fase di compilazione che un metodo non costante per un oggetto costante viene chiamato (o qualcosa del genere)?

[Sergey Dzyublik]

Alexey Kozitsyn:

Domanda: il compilatore non dovrebbe segnalare (errore/avviso) in fase di compilazione che un metodo non costante viene chiamato per un oggetto costante (o qualcosa del genere)?

Forse la ragione è una chiamata implicita al costruttore di copia come risultato della chiamata diReset per un oggetto temporaneo.

[[Eliminato]]

Sergey Dzyublik:

Forse la ragione è una chiamata implicita al costruttore di copia come risultato della chiamata diReset per un oggetto temporaneo.

Grazie. Probabilmente hai ragione, e lo specificatore const non influenza il risultato (nessun reset si verifica sia con che senza di esso).

[Andrey Barinov]

Alexey Kozitsyn:

Sto lentamente imparando l'OOP e mi sono imbattuto in una cosa non ovvia.

C'è una classe A, i cui campi sono oggetti di un'altra classe B.

Nella classe A, viene chiamato un metodo costante che restituisce un oggetto della classe B.

Dopo di che, viene chiamato un metodo della classe B, che cancella i parametri dell'oggetto restituito.

Si presenta così (l'esempio è semplificato, scritto nel browser):

Il risultato è che Reset() non funziona, cioè i campi m_member non vengono cancellati.

Domanda: il compilatore non dovrebbe segnalare (errore/avviso) in fase di compilazione che un metodo non costante per un oggetto costante viene chiamato (o qualcosa del genere)?

Restituire i puntatori.

class B
{
private:
   int m_width;
   int m_length;
public:
   void Reset() { m_width = 0; m_length = 0; }
}
class A
{
private:
   B m_member;
public:
   B * GetBMember() const { return( & m_member ); }
}
//---
A obj;
obj.GetBMember().Reset();