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
Un remplacement pourrait être une table d'index native - mais alors je ne peux pas faire une classe encapsulant le travail avec un tableau de structures avec la possibilité de son héritage avec des services une fois spécifiés (tri et recherche binaire).
Je vois - il ne s'agissait pas d'une solution spécifique, mais de possibilités abstraites.
Si vous voulez travailler efficacement à la périphérie des systèmes externes, écrivez du code spécifique au site, plutôt que d'essayer de faire une solution universelle qui contredit les questions de sécurité.
Non, nous ne ferons pas de telles remises. C'est un mal absolu, dont nous serons tenus responsables jusqu'à la fin.
Il n'y a pas grand-chose à répondre. Vous ne voyez pas les dangers.
J'ai souligné l'inévitabilité d'une énorme table d'échange. C'est un mal énorme.
Vous ne voulez même pas travailler avec des index, vous dites à quel point c'est gênant pour vous, et puis soudain, une énorme et lente table de handles dans MQL5 "ne représente aucun danger".
Renat:
..........., plutôt que d'essayer d'apporter une solution unique qui contredit les questions de sécurité.
Renat, donnez-moi au moins un exemple d'utilisation dangereuse d'une poignée sur une structure. Je m'obstine à ne pas en voir. J'essaie d'en trouver un et je ne le trouve pas. Peut-être ai-je raté quelque chose ?
--
Qu'en est-il des structures paramétrées ? Y en a-t-il à long terme ? Tout est résolu au niveau du préprocesseur, de sorte que les questions de sécurité sont généralement hors de question. Et beaucoup de problèmes liés aux conteneurs de données pratiques seraient résolus de manière très agréable et compacte.
1. j'ai souligné le caractère inévitable d'une énorme table de correspondance des poignées. C'est un mal énorme.
Vous ne voulez même pas travailler avec des index, vous me dites à quel point c'est gênant et tout d'un coup une énorme et lente table de handles dans MQL5 "ne représente aucun danger".
1. la table n'est pas énorme, c'est ce que l'utilisateur a "manipulé" - extensible dynamiquement. Les chaînes de caractères sont aussi mauvaises. Alors limitons à 128 symboles par ligne. Il y aura alors moins de mal dans le monde, non ? :)
2. je veux même vraiment travailler avec des index. je ne veux simplement pas travailler encore et encore - je veux hériter de mon travail et le reproduire quand c'est nécessaire, pas le réécrire (avec de nouvelles erreurs avec des corrections de copier-coller bâclées).
Mais je n'en parle même plus, peut-être que je devrais ?
1. la table n'est pas énorme, mais comme l'utilisateur l'a "nahndled" - dynamiquement extensible. les chaînes de caractères sont alors mal aussi. Alors limitons à 128 symboles par ligne. Il y aura alors moins de mal dans le monde, non ? :)
Les cordes sont liées en interne et personne ne l'exige en externe. En d'autres termes, nous n'avons pas besoin de maintenir des identifiants publics affichés par le biais de tables. Tout y est rapide et caché.
"User nahndled" - c'est un tableau énorme et freinant.
Nous n'allons pas nous créer un problème à l'improviste. N'exagérons donc pas le sujet - cette question est close et aucun argument ne pourra la changer.
Les structures paramétrées sont-elles prévues à long terme ? Tout est résolu au niveau du préprocesseur, de sorte que les problèmes de sécurité sont généralement écartés. Et de nombreux problèmes liés à la commodité des conteneurs de données seraient résolus de manière très agréable et compacte.
Les modèles ne sont pas encore dans les plans.
En ce moment, nous libérons les mèmes des classes statiques et la surcharge des opérateurs.
Nous libérons maintenant les mèmes classes statiques et la surcharge des opérateurs.
1. les modèles ne sont pas encore dans les plans.
2. nous libérons maintenant les mèmes classes statiques et la surcharge des opérateurs.
1. Dommage, tu devrais peut-être le planifier.
2. pour cela - un grand merci humain, j'attends avec impatience la construction.