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
La méthode constante est un autre exemple du proverbe "nous voulions faire mieux, mais il s'est avéré que c'était toujours la même chose". Je pense que c'est une devise pour le C++ tout court. Il n'y a pas d'utilisation pratique mais cela complique considérablement la conception des programmes OOP parce que vous devez constamment contrôler le type d'objet qui est modifié (il doit aussi être constant).
Je peux vous donner un exemple de ce que vous avez écrit ?
La méthode constante n'est qu'un autre exemple du proverbe "Nous voulions que les choses soient meilleures, mais elles se sont déroulées comme d'habitude". Je pense que c'est une devise pour C++ tout court. Elle n'a aucune utilité pratique mais complique considérablement la conception des programmes OOP car il faut constamment contrôler le type de l'objet modifié (il doit aussi être constant).
))) J'ai un vieux livre de Stroustrup qui traîne, si des cambrioleurs s'introduisent dans la maison, je peux les frapper avec, il pèse comme une brique ;)) Le vieil homme avait tellement de mal avec sa langue.
Je me souviens qu'il y a longtemps, j'ai été poursuivie lors d'un entretien d'embauche, ils m'ont posé une question et je n'ai pas pu y répondre avec précision. Ils m'ont apporté un livre comme celui-ci, je l'ai lu et j'ai demandé : "L'utilisez-vous vous-même ?
J'ai demandé : "L'utilisez-vous vous-même ?" Les gars rient, c'est bon, personne n'a encore répondu correctement à cette question, car personne ne l'utilise.
À propos, j'ai un livre sur les plus datant du début des années 90, avant l'adoption de la première norme. Un livre de poche normal et digeste. Mais alors Ostap s'est emporté))
Puis-je avoir un exemple de ce que vous avez écrit ?
Alexey a écrit un exemple. Une méthode constante ne peut pas modifier les membres de sa classe. Quel semble être le problème ? Il suffit de ne pas utiliser le modificateur const. Mais il y a ensuite des difficultés dans l'héritage (surtout à partir de labibliothèque standard) : le concepteur a défini une méthode virtuelle const, mais dans la classe dérivée, la méthode doit changer quelque chose dans ses données - et il y a un bouchon à cause de const. Sans elle, la méthode ne sera pas surchargée, et avec elle, la méthode dérivée ne peut pas modifier les données de sa propre classe.
Quelle est la principale erreur dans l'introduction d'un tel modificateur pour les méthodes de classe ? Le principe principal de l'héritage est violé : spécialisation et raffinement. La classe de base interdit à la méthode de la classe dérivée de travailler avec ses données internes. Et une telle situation ne devrait pas exister.
Sharpe pue à un kilomètre).
Il n'y a rien de gênant, pas besoin d'en rajouter.
Sharpe pue à un kilomètre).
Je ne le nie pas. Sharpe est vraiment une langue parfaite, grande et belle.
Const ne complique rien, ne fait pas de blabla
Ok, disons qu'on peut toujours se débarrasser de Const. Mais pourquoi n'expliquez-vous pas brièvement, par exemple, ce que fait Const ? Quelle est sa véritable utilité ? Par exemple, et de préférence pas écrit de toutes pièces.
...
Quelle est l'erreur principale de l'introduction d'un tel modificateur pour les méthodes de classe ? Le principe principal de l'héritage est violé : spécialisation et raffinement. La classe de base interdit aux méthodes de la classe dérivée de travailler avec ses données internes. Mais il ne doit pas y avoir de telle chose.
Peut-être s'agit-il d'une partie qui passe des créateurs aux simples utilisateurs. Comme la fonction de démarrage dans le conseiller expert et les variables Bid et Ask.
Lorsque l'on fabrique tout soi-même, il est inutile de s'embarrasser de toutes sortes de contraintes.
Je ne le nie pas. Sharp est en effet une langue parfaite, grande et belle.
...
Super. Mais c'est loin d'être parfait.