Erreurs, bugs, questions - page 2419
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
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?
Quel est alors l'intérêt de passer le paramètre par référence?
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.
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éé.
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 :
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&) { }
Il voulait dire pourquoi prendre un objet temporaire par référence quand on peut le prendre par valeur.
parce que
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.
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.
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.
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.
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.