Erreurs, bugs, questions - page 1953

Nouveau commentaire
 
fxsaber:

Les développeurs en sont conscients. Mais une telle optimisation par le compilateur est loin de constituer une priorité des tâches à résoudre.

Oui, mais c'est tout simplement incroyable : ils se sont tellement vantés ici tout à l'heure d'avoir porté la qualité de l'optimiseur à des sommets sans précédent, mais en fait, il ne peut même pas gérer des choses aussi simples. Sans parler des plus complexes.

 
fxsaber:

C'est pourquoi je propose d'ajouter à OnTesterInit la possibilité de changer la table de passage par défaut :

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

Je suppose que les jeux de paramètres eux-mêmes ne sont pas stockés dans le système, mais sont calculés par le numéro unique de la combinaison (qui coïncide maintenant avec le numéro de passe). Il est donc uniquement possible de modifier l'ordre des combinaisons, mais pas leur composition. Donc, dans ce cas, ce serait quelque chose comme SwapPasses(long index1, long index2).

Mais je peux me tromper.

 
Alexey Navoykov:

Je suppose que les jeux de paramètres eux-mêmes ne sont pas stockés dans le système, mais sont calculés à l'aide d'un numéro de combinaison unique (qui coïncide maintenant avec le numéro de passe). Par conséquent, vous ne pouvez modifier que l'ordre des combinaisons, mais pas leur composition. Dans ce cas, ce serait quelque chose comme SwapPasses(long index1, long index2).

C'est peut-être le cas. Maintenant, l'ordre peut encore être influencé d'une manière ou d'une autre par les lignes d'entrée Swap dans la source EA.

 
fxsaber:

C'est peut-être le cas. Maintenant l'ordre peut être influencé d'une manière ou d'une autre par les lignes d'entrée Swap dans le code source de l'EA.

Cela tue l'algorithme d'optimisation - c'est comme si on optimisait dans une direction aléatoire.

 
Stanislav Korotky:

Cela tue l'algorithme d'optimisation - c'est comme si on optimisait dans une direction aléatoire.

Nous parlons d'un dépassement complet en premier lieu.

 

J'apprends lentement la programmation opérationnelle et j'ai rencontré une chose non évidente.

Il existe une classe A, dont les champs sont des objets d'une autre classe B.

Dans la classe A, on appelle une méthode constante qui renvoie un objet de la classe B.

Ensuite, une méthode de la classe B est appelée, qui supprime les paramètres de l'objet retourné.

Cela ressemble à ceci (l'exemple est simplifié, écrit dans le navigateur) :

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();

Le résultat est que Reset() ne fonctionne pas, c'est-à-dire que les champs m_member ne sont pas effacés.

Question : le compilateur ne devrait-il pas signaler (erreur/alerte) au moment de la construction qu'une méthode non constante pour un objet constant est appelée (ou quelque chose comme ça) ?

 
Alexey Kozitsyn:

Question : le compilateur ne devrait-il pas signaler (erreur/alerte) au moment de la construction qu'une méthode non constante est appelée pour un objet constant (ou quelque chose comme ça) ?


La raison en est peut-être un appel implicite du constructeur de la copie en raison de l'appel deReset pour un objet temporaire.

 
Sergey Dzyublik:

La raison en est peut-être un appel implicite du constructeur de la copie en raison de l'appel deReset pour un objet temporaire.

Merci. Vous avez probablement raison, et le spécificateur const n'affecte pas le résultat (aucune réinitialisation ne se produit avec et sans lui).
 
Alexey Kozitsyn:

J'apprends lentement la programmation opérationnelle et j'ai rencontré une chose non évidente.

Il existe une classe A, dont les champs sont des objets d'une autre classe B.

Dans la classe A, on appelle une méthode constante qui renvoie un objet de la classe B.

Ensuite, une méthode de la classe B est appelée, qui supprime les paramètres de l'objet retourné.

Cela ressemble à ceci (l'exemple est simplifié, écrit dans le navigateur) :

En conséquence, il s'avère que Reset() ne fonctionne pas, c'est-à-dire que les champs m_member ne sont pas effacés.

Question : le compilateur ne devrait-il pas signaler (erreur/alerte) au moment de la construction qu'une méthode non constante pour un objet constant est appelée (ou quelque chose comme ça) ?

Pointeurs de retour.
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();
 
Andrey Barinov:
Ramenez les panneaux indicateurs.
Merci pour cette idée. Je les avais complètement oubliés.
1...194619471948194919501951195219531954195519561957195819591960...3184
Nouveau commentaire