Erreurs, bugs, questions - page 2419

Nouveau commentaire
 
Alexey Navoykov:

Que pensez-vous de l'ajout au langage de la possibilité de transmettre un argument sous forme de valeur r? Cela résoudrait immédiatement tous les problèmes et permettrait de créer des conteneurs universels pour n'importe quel type. En particulier, la méthode ci-dessus serait surchargée pour la valeur r :

C'est exactement comme cela qu'il est implémenté dans tous les conteneurs STL.

Et le deuxième plus : il permettra de définir des constructeurs de déplacement. Maintenant, cela est également très manquant, en particulier pour la mise en œuvre des pointeurs intelligents unique_ptr et d'autres classes, conçu pour le monopole de stocker une certaine ressource unique à l'intérieur, c'est la copie habituelle constructeurs sont inacceptables pour eux.

Quel est alors l'intérêt de passer un paramètre par référence?

 
Slava:

Quel est alors l'intérêt de passer le paramètre par référence?

vous posez des questions très étranges. Les liens de valeur r ne servent qu'à déplacer la sémantique. Les liens normaux servent à tout le reste.
 
Slava:

Quel est l'intérêt de passer le paramètre par référence alors ?

Je ne comprends pas vraiment non plus de quel genre de référence vous parlez. À l'origine, nous disions que les références l-value (disponibles dans MQL) ne couvrent pas tous les besoins, ce qui a été démontré par l'impossibilité de passer une constante ou une valeur d'expression à une telle fonction. À cette fin, la référence r-value est nécessaire, qui acceptera tous les autres types. Ainsi, la combinaison de deux fonctions surchargées pour r-value et l-value garantira que tous les types d'arguments seront acceptés, indépendamment de leur origine.

Ce que vous avez dit, qu'une constante n'est stockée nulle part, mais créée à la volée, cela signifie qu'elle doit être passée sous la forme d'une valeur r, et non d'une valeur l (contrairement au C++). En principe, cela ne fait pas de différence sous quelle forme elle est interprétée, l'essentiel est qu'elle puisse être acceptée dans la fonction.

 
Alexey Navoykov:

Ce que vous avez dit, que la constante n'est stockée nulle part, mais qu'elle est créée à la volée, cela signifie qu'elle doit être passée comme valeur r, et non comme valeur l (contrairement au C++). En principe, cela ne fait pas de différence sous quelle forme elle est interprétée, tant que vous pouvez l'accepter dans une fonction.

La référence à la valeur r implique en fait un objet pour lequel le déplacement sera effectué, c'est-à-dire qu'un objet temporaire doit encore être créé.

 
TheXpert:

En fait, la référence à la valeur r implique qu'il existe un objet pour lequel le déplacement sera effectué, c'est-à-dire qu'un objet temporaire doit être créé de toute façon.

De toute évidence, l'objet existe toujours quelque part. J'ai écrit que cet objet est créé à la volée, c'est-à-dire qu'il est temporaire.

Mais je crois que j'ai compris ce que Slava demandait. Il voulait dire pourquoi nous devons accepter un objet temporaire par référence quand nous pouvons l'accepter par valeur.

Le fait est qu'il est impossible de surcharger une fonction simultanément pour la référence et la valeur en une seule copie :

template<typename T>
 void f(T) { }
template<typename T>
 void f(T const&) { }
 
class A { };

void OnStart()
{
  A a;
  f(a);
  const int b=0;
  f(b);  // 'f' - ambiguous call to overloaded function with the same parameters
}

Cela rend problématique l'écriture de solutions universelles. En remplaçant la valeur par la valeur r, nous obtenons une variante fonctionnelle :

template<typename T>
 void f(T &&) { }
template<typename T>
 void f(T const&) { }
 
Alexey Navoykov:

Il voulait dire pourquoi prendre un objet temporaire par référence quand on peut le prendre par valeur.

parce que 

void f(int) {}
void f(const int&) {}

void OnStart()
{
   const int x = 0;
   f(x); // 'f' - ambiguous call to overloaded function with the same parameters
}

et parce qu'il est généralement plus pratique de transmettre quelque chose par référence que par valeur.

Et si la méthode est modélisée (c'est là que tout a commencé), le comportement actuel ne permet tout simplement pas d'écrire correctement.

 
TheXpert:

Et si la méthode est basée sur des modèles (c'est là que tout a commencé), le comportement actuel ne permet tout simplement pas d'écrire correctement.

Oui, j'ai remplacé mon exemple par un modèle pour le rendre plus clair, car les ints passés par référence n'ont vraiment pas l'air très convaincants).
 
Alexey Navoykov:

Et en remplaçant la valeur par la valeur r, on obtient une version fonctionnelle :

pas vraiment)

la sémantique de déplacement implique de dire à l'objet à déplacer qu'il n'a pas besoin de supprimer ses internes. si l'objet est constant, vous auriez besoin d'un membre de classe mutable, mql ne supporte pas cela.

 
TheXpert:

pas vraiment)

la sémantique de déplacement implique de dire à l'objet à déplacer qu'il n'a pas besoin de supprimer ses internes. si l'objet est une constante, vous avez besoin d'un membre de classe mutable, mql ne supporte pas cela.

Oui, vous avez raison, la constante pour la valeur r ne doit pas être définie (cela ne se compile pas de cette façon dans les plus). Je vais le corriger maintenant)
 

Pourquoi mql5 déplacerait-il la sémantique ? Il n'y a pas besoin d'une telle optimisation des performances, d'autant plus qu'il s'agit d'une machine virtuelle. Pour quoi d'autre en avez-vous besoin ?)

En soi, mql5 est très différent de C++, ainsi que deC++98, et encore plus de C++11/14/17, mais ses capacités couvrent maintenant complètement les éléments dont vous avez besoin pour créer une EA.

1...241224132414241524162417241824192420242124222423242424252426...3184
Nouveau commentaire