Erreurs, bugs, questions - page 1358
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
C'est pour quoi faire ? C'est à l'envers.
Il est plus logique que ce soit l'inverse : que < et > conduisent à une comparaison de pointeurs.
Ce sujet a déjà été abordé à l'époque (veuillez relire ce vieux fil). Dans mes posts, j'ai supposé que vous vous en souveniez si vous suggériez : "terminons cette question".
Je le répète : deux opérateurs sont sacrifiés (== et !=) afin de préserver les capacités de tous ( !) les autres (pas seulement < et >). La beauté au détriment de la fonctionnalité.
pour ne pas avoir à spécifier explicitement A.operator!=(B)
Eh bien, cela sera bientôt résolu, j'espère, car les développeurs m'ont enfin entendu. Alors ce sera simple : *A != *B
Cela a déjà été discuté à l'époque (veuillez relire cet ancien fil de discussion) - je répète - deux opérateurs sont sacrifiés (== et !=) afin de préserver les capacités de tous ( !) les autres (pas seulement < et >).
Je suis d'accord pour que tous ces opérateurs aient un statut égal. Mais pas de la manière que vous suggérez. Si les deux arguments sont des pointeurs, ce sont les pointeurs qui doivent être comparés l'un à l'autre. Sinon, ce serait illogique : les deux arguments sont explicitement donnés par GetPointer, mais pour une raison quelconque, les opérateurs de classe sont exécutés. Donc, à mon avis, les signes d'inégalité seraient plus correctement appliqués aux pointeurs dans ce cas.
De toute façon, personne ne va changer le comportement des opérateurs, c'est évident, sinon il y aura une agitation générale autour des programmes qui ne fonctionnent pas.
Une fois de plus, vous oubliez l'opérateur d'affectation. Suggérez-vous que nous l'implémentions également par le biais d'une fonction ? Ne serait-ce pas trop fastidieux ?
Bonjour à tous,
Je me pose la question, je me suis inscrit à un signal qui est assez fiable, puis tout d'un coup le trading a commencé sur des lots fous, tout aurait été bien au début car il y avait un profit qui s'est avéré être une perte d'argent à la fin. Pouvez-vous me dire où le chien est enterré (la faute à qui ?) et qui peut aider à régler le problème.
Bonjour à tous,
Une telle question, signé pour un signal qui est assez fiable, ici hors de l'azur a commencé à négocier des lots fous, tout aurait été bien au début, comme il y avait un profit qui s'est avéré pour finir par perdre de l'argent. Pouvez-vous me dire où le chien est enterré (la faute à qui ?) et qui peut aider à régler le problème.
Un signal qui est assez fiable, ici, tout d'un coup, a commencé à négocier des lots fous.
+100500
Pouvez-vous me dire où le chien est enterré (à qui la faute ?) et qui peut aider à régler le problème ?
Nous vous dirons où le chien est enterré : derrière les garages, mais à qui la faute - vous devriez aller à la branche télépathique, c'est quelque part sur ce forum, googlez-le.
oui le truc c'est que les ordres présentés sur le site dans ma section signal et ce que la plateforme sur mon téléphone a émis ne correspondent pas.
ce n'est pas une question de signal, le signal est fiable, c'est une question de transmission, quelle pourrait être la raison ?
et que puis-je faire pour fournir le matériel si je ne le comprends pas du tout d'un point de vue technique ?
Et encore une fois, vous oubliez l'opérateur d'assignation. Proposez-vous de l'implémenter également par le biais d'une fonction ? Ne serait-ce pas trop fastidieux ?
Dans le cas de operator=(...), il n'y a pas de solution plus simple que d'utiliser directement a.operator=( b ).
S'ils font *A = *B - très bien !
En avez-vous un ?