Caractéristiques du langage mql5, subtilités et techniques - page 110
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
Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading
Bugs, bugs, questions
fxsaber, 2018.12.01 11:15
Conception du super-freinUn fichier de 40 Mo contenant 1 million de lignes prend 18 secondes à lire.
Le même résultat de sortie, mais fait différemment
est déjà fait en 0,5 seconde.
Une contrepartie simple à auto_ptr (considéré comme obsolète). Note : pas tout à fait analogue, avec
...
https://habr.com/post/140222/
pavlick_
Une ligne au début devrait être ajoutée à operator= :
Bien que cela vaille probablement la peine de se limiter à quelque chose comme ça (vous ne pouvez pas copier du tout) :
Pourquoi ai-je fait la copie pour auto_ptr ? En raison de la courbure de µl - pour copier un objet de la pile vers CArrayObj, vous devez créer un tas d'objets en appelant le constructeur un tas de fois. Mais je ne pense pas que ça en vaille la peine. À cet égard, je vais retirer le premier message.Pourquoi ai-je fait la copie pour auto_ptr ? En raison de la courbure de µl - pour copier un objet de la pile vers CArrayObj, vous devez créer un tas d'objets en appelant le constructeur un tas de fois.
Et pourquoi "la courbure de μl" ?
Et pourquoi le "crochetage du µl" ?
La tâche triviale d'ajouter une copie d'un objet de pile à un tableau est d'ajouter un constructeur par défaut, dont je n'avais pas besoin en premier lieu :
Ce n'est pas fatal, oui, vous pouvez faire init() à Q, ce qui atténue un peu le problème, mais quand même - c'est dégoûtant. Et en copiant auto_ptr à la main, tout se passe en deux lignes, mais le jeu n'en vaut pas la chandelle. Peut-être trop pointilleux, perfectionnisme.
La tâche triviale d'ajouter une copie d'un objet de pile à un tableau s'avère être la suivante + je dois prescrire un constructeur par défaut, dont je n'avais pas du tout besoin :
Ce n'est pas fatal, oui, vous pouvez faire init() à Q, ce qui lissera un peu le problème, mais c'est quand même dégoûtant. Et quand on copie auto_ptr à la main, tout se passe en deux lignes, mais le jeu n'en vaut pas la chandelle. Peut-être trop pointilleux, perfectionnisme.
Mais c'est exactement la même chose en C++ aussi, donc on ne sait pas vraiment pourquoi la mcl tordue.
Et dans votre cas, il est plus facile de spécifier le constructeur de copie, et d'ajouter des éléments avec une seule ligne :
ar.Add(new Q(q));
La tâche triviale d'ajouter une copie d'un objet de la pile à un tableau s'avère être la suivante + je dois écrire un constructeur par défaut, ce dont je n'avais pas du tout besoin :
Pas fatal, oui, vous pouvez faire init() à Q, ce qui atténuera un peu le problème, mais c'est quand même dégoûtant. Et quand on a copié auto_ptr, tout se passe en deux lignes, mais le jeu n'en vaut pas la chandelle. Peut-être trop pointilleux, perfectionnisme.
C'est comme ça que ça se passe de toute façon - c'est juste caché derrière votre auto_ptr...
Je ne vois pas de problèmes particuliers ici.
En tant que vieux routier endurci, je n'aime vraiment pas l'approche du C# où la mémoire est supprimée automatiquement. À mon sens, c'est la personne qui a demandé la suppression des objets, et non des "collecteurs de déchets", qui devrait en être responsable.
Mais c'est exactement la même chose en C++, donc on ne voit pas très bien pourquoi la mcl est tordue.
Et dans votre cas, il est plus facile de spécifier un constructeur de copie, et d'ajouter des éléments en une seule ligne :
En quoi est-ce la même chose ? Il y a un constructeur de copie automatiquement et toutes les manipulations auront un regard :
Dans votre cas, il est plus facile de définir un constructeur de copie et d'ajouter des éléments en une seule ligne.
Bien sûr, c'est une classe jouet par exemple, en réalité c'est aussi des données, probablement beaucoup, ce n'est pas du tout une option pour écrire un constructeur de copie. Enveloppé aux bons endroits dans des wrappers et pas besoin d'un constructeur personnalisé.
Donc tout se passe de toute façon - c'est juste caché derrière votre auto_ptr...
Je ne vois pas de problème particulier ici.
En tant que vieux routier endurci, je n'aime pas l'approche du C# où la mémoire est supprimée automatiquement. À mon sens, c'est la personne qui a demandé la suppression des objets qui devrait en être responsable, et non un quelconque collecteur de déchets.
En µl, on peut se passer des pointeurs intelligents. Collecteur de déchets != pointeurs intelligents, vous ne pouvez pas vous en passer, au moins à cause des exceptions. Je n'aime pas le ramasseur d'ordures moi-même.