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
Voici la réponse à cette question :
Dans le rectangle rouge - ajout d'un appel àGetMicrosecondCount(), dans le rectangle bleu - un de plus. C'est pour ça que c'est presque égal.
Pourquoi osez-vous me montrer le code ? Sans le code, vous pouvez fourrer vos images temporelles là où le soleil ne brille pas.
Oups. Avec des actions identiques, la différence n'était que de 30 %.
Peut-être que ce sont les classes qui créent les frais généraux ? Bien sûr, le compilateur devrait de toute façon tout mettre en ligne et supprimer les éléments inutiles. Il est logique de le signaler aux développeurs.
Ça a marché. La structure a travaillé à la même vitesse que la fonction et la macro. Mais la classe... loin derrière.
Ça a marché. La structure a travaillé à la même vitesse que la fonction et la macro. Mais la classe... loin derrière.
J'ai donné des conseils sur la façon d'accéder à des méthodes/champs privés dans SB et j'ai trouvé ce crochet sur le forum moi-même, je ne me souviens pas qui l'a suggéré.
j'ai été surpris de constater que je donnais des conseils comme d'habitude sans m'en tenir à la terminologie, ce n'était pas un crochet mais un anti-modèle Public Morozovhttp://blog.kislenko.net/show.php?id=1775
)))
J'ai donné des conseils sur la façon d'accéder à des méthodes/champs privés dans SB et j'ai trouvé ce crochet sur le forum moi-même, je ne me souviens pas qui l'a suggéré.
j'ai été surpris de constater que je donnais des conseils comme d'habitude sans m'en tenir à la terminologie, ce n'était pas un crochetmais un anti-modèle Public Morozovhttp://blog.kislenko.net/show.php?id=1775
)))
Vous avez donné un baril de miel aux négationnistes et aux amoureux de l'OO :-) Un modèle pour obtenir ce qui est caché par des considérations de conception :-)
Quelqu'un (quelqu'un des monstres actuels de l'OO/C++) a dit très raisonnablement que le point sensible de l'OO est que la classe de base doit fournir des interfaces suffisantes pour toutes les variations descendantes (pratiquement avoir des setters-getters disponibles pour tous les champs, ou tout-en-un),
et les descendants ne peuvent pas créer de fonctions virtuelles en dehors du protocole parent, alors seulement le bonheur universel viendra. Ensuite, la STL+boost généralisée est vraiment utile, les tests sont utiles et réutilisables. Mais cela devient beaucoup de classes, car au lieu de nouvelles fonctions virtuelles, toutes sortes de proxies agissent.
ici, vous avez donné un baril de miel aux négationnistes et aux amoureux de l'OO :-) Un modèle pour obtenir ce qui est caché par des considérations de conception :-)
Quelqu'un (quelqu'un des monstres actuels de l'OO/C++) a dit très raisonnablement que le point sensible de l'OO est que la classe de base doit fournir des interfaces suffisantes pour toutes les variations descendantes (pratiquement avoir des setters-getters disponibles pour tous les champs, ou tout-en-un),
et les descendants ne peuvent pas créer de fonctions virtuelles en dehors du protocole parent, alors seulement le bonheur universel viendra. Ensuite, la STL+boost généralisée est vraiment utile, les tests sont utiles et réutilisables. Mais cela devient beaucoup de classes, car toutes sortes de proxies agissent à la place de nouvelles fonctions virtuelles.
Qu'est-ce que les modèles et les amoureux de l'OO ont à voir avec cela ?
Quelqu'un (quelqu'un qui fait partie des monstres actuels de l'OO/C++) a dit, avec beaucoup de bon sens, que le point sensible de l'OO est que la classe de base doit fournir des interfaces suffisantes pour toutes les variations des descendants (pratiquement avoir des setter-getters disponibles pour tous les champs, ou tout à fait n'importe quoi).