Parler de l'OLP dans le salon - page 16

Nouveau commentaire
 
Vasiliy Sokolov:

Dans les langages de programmation normaux(pas en C++), lasurcharge de l'opérateur '=' est interdite.

Une langue normale, c'est votre Sharp ? Et le seul que vous connaissez ? Ça craint aussi, sinon vous ne diriez pas des choses comme "les interfaces ne sont pas de l'héritage".

Vous savez, l'opérateur = est là, non pas comme un sucre, mais comme un opérateur. Et dans MQL, il est -- auto-généré, vous savez !

Et le fait que dans MQL le constructeur de copie est beaucoup plus pratique que celui que vous avez écrit, je n'ai même pas besoin de vous en parler. Vous étiez un imbécile il y a quelques années et vous l'êtes toujours. Tu viens de booster ton ego avec des gars comme Denisa.

 
Комбинатор:

...Tu viens de voir ton ego boosté par des gens comme Denis.

Vous ne pouvez pas m'avoir sur des points spécifiques, alors maintenant vous vous en prenez au reste du forum. Méchant et méprisable.

(Note : il met les autres à la troisième personne et avec une petite lettre, c'est-à-dire sans respect et "vous êtes tous des nuls ici")

 
Vasiliy Sokolov:

Dans les langages de programmation normaux(pas en C++), lasurcharge de l'opérateur '=' est interdite.

Il est très pratique pour moi, surtout lorsque j'utilise beaucoup de modèles, de pouvoir surcharger cet opérateur. Je le surcharge dans de nombreuses autres situations également.

Et la surcharge de certains opérateurs est presque totalement interdite dans certains langages, parce qu'elle y est totalement méritée en tant qu'anti-modèle. Je suggère qu'avant d'utiliser une telle surcharge, en particulier l'opérateur d'assignation, on devrait réfléchir sérieusement à la raison pour laquelle les architectes idiots de ces langages idiots font cela.

Les nombres complexes et les matrices constituent un exemple classique de surcharge d'opérateurs. Je ne vois rien de mal à cela. J'écris tout le temps des opérateurs parce que le code n'est plus encombrant et que l'on voit tout de suite la logique.


Le plus simple

struct MQLTICK : public MqlTick
{
  bool operator >( const double Price ) const
  {
    return(this.bid > Price);
  }

  bool operator <( const double Price ) const
  {
    return(this.ask < Price);
  }
};
 

Vasiliy Sokolov et Combinator, s'il vous plaît, arrêtez de jurer.

Sinon, nous devrons interdire Volchanski comme provocateur :)

 
Vasiliy Sokolov:

Vous ne pouvez pas m'avoir sur des points précis

Vous n'avez pas besoin de plus de détails ? )) Ecrire du code charp avec affectation ? Ou me montrer comment écrire un constructeur de copie ? Ou lister des langages avec des opérateurs d'affectation? Parler du manque de spécificités et faire de fausses accusations contre moi est beaucoup plus facile que d'admettre que vous êtes plein de merde.
 
Rashid Umarov:

Sinon, nous devrons interdire Wolchansky en tant que provocateur :)

Nan, qui va raconter les histoires ? Je préfère être l'instigateur.

 
Vasiliy Sokolov:

Je ne vais pas me laisser provoquer par des haineux analphabètes, et je ferais mieux d'expliquer mon point de vue :

Dans les langages de programmation normaux(pas en C++),la surcharge de l'opérateur '=' est interdite. Je suggère qu'avant d'utiliser une telle surcharge, en particulier l'opérateur d'affectation, ceux qui le souhaitent réfléchissent sérieusement à la raison pour laquelle les architectes de ces langages idiots font cela.

Et pourquoi s'agit-il de "langages de programmation normaux" ?

La surcharge de l'opérateur d'affectation est très pratique dans de nombreux cas. L'exemple classique est celui des "pointeurs intelligents". L'opérateur d'affectation ne doit pas seulement copier un pointeur, mais aussi faire AddRef() - avec la surcharge, tout cela se fait de manière transparente.

Pourquoi est-ce pratique ? Parce qu'il est beaucoup plus logique de copier des pointeurs plutôt que des objets entiers. (Et avec une copie intensive à différents endroits du programme, il est difficile de voir si l'objet est nécessaire ou non. Dans ce cas, les smartpoints sont très utiles.

Bien sûr, il existe des choses comme le "collecteur d'ordures" - mais j'aime moins cette variante, précisément parce que les pointeurs ont un accès complet aux références et au nombre de copies, alors que le collecteur d'ordures n'en a pas. Sans compter que les pointeurs détruisent l'objet dès qu'il n'est plus nécessaire, alors que le collecteur d'ordures travaille avec un certain retard.

 
George Merts:

Bien sûr, il y a des choses comme le "collecteur d'ordures" - mais j'aime moins cette option, précisément parce que les pointeurs ont un accès complet au compte de références et de copies, alors que le collecteur d'ordures ne l'a pas. Sans compter que les pointeurs détruisent l'objet dès qu'il n'est plus nécessaire, alors que le collecteur d'ordures travaille avec un certain retard.

Uh-huh, GC, même lancé de force, ne supprime pas toujours tout. Parfois, cela devient un problème.
 
Vasiliy Sokolov:

Je ne vais pas me laisser provoquer par des haineux analphabètes, et je ferais mieux d'expliquer mon point de vue :

Dans les langages de programmation normaux(pas en C++),la surcharge de l'opérateur '=' est interdite. Je suggère qu'avant d'utiliser une telle surcharge, en particulier l'opérateur d'affectation, ceux qui le souhaitent réfléchissent sérieusement à la raison pour laquelle les architectes stupides de ces langages stupides font cela.

Je n'ai pas pu résister, personnellement à andrei : bon sang, ne te mets pas dans l'embarras comme ça. Vous dites des choses si stupides : d'abord sur la FP, maintenant sur les opérateurs. Vouloir hayterite - bienvenue : donner des références à des sources faisant autorité, justifier, etc. Ce que vous faites maintenant, c'est une haine enragée et surtout totalement analphabète. Vous semblez être un programmeur, voire un vrai programmeur - il est honteux d'écrire de telles choses.


Vasily, il est souhaitable de préciser les noms des langues. Les expressions "dans la norme", "dans certains", "ces" n'ajoutent pas de crédibilité à ce qui est dit. Nous sommes des programmeurs, pas des whitelists, alors soyons précis dans nos déclarations.

 
Yuriy Asaulenko:
Uh-huh, GC, même quand il est forcé, ne supprime pas toujours tout. Parfois, cela devient un problème.

S'il pense que l'objet est susceptible d'être recréé prochainement, il ne le supprimera pas.

1...91011121314151617181920212223
Nouveau commentaire