Hablando de la OLP en el salón - página 16

[TheXpert]

Vasiliy Sokolov:

En los lenguajes de programación normales(no en C++),la sobrecarga del operador '=' está prohibida.

¿Una lengua normal es su Sharp? ¿Y el único que conoces? También es una mierda, si no, no estarías diciendo cosas como "las interfaces no son herencia".

Ya sabes, el operador = está ahí, no como un azúcar, sino como un operador. Y en MQL es... ¡autogenerado, ya sabes!

Y el hecho de que en MQL el constructor de copia es mucho más cómodo que el que has escrito, ni te cuento. Hace unos años eras un tonto y lo sigues siendo. Acabas de aumentar tu ego con tipos como Denis.

[Vasiliy Sokolov]

Комбинатор:

...Sólo has conseguido que te suban el ego con gente como Denis.

No me puedes poner en lo específico, así que ahora te pones en contra del resto del foro. Malvado y despreciable.

(Nota: puso a los demás en tercera persona y con minúscula, es decir, sin respeto y "aquí no sois nadie")

[fxsaber]

Vasiliy Sokolov:

En los lenguajes de programación normales(no en C++),la sobrecarga del operador '=' está prohibida.

Es muy conveniente para mí, sobre todo cuando uso mucho la plantilla, que sea posible sobrecargar este operador. También lo sobrecargo en muchas otras situaciones.

Y la sobrecarga de algunos operadores está casi completamente prohibida en algunos lenguajes, porque es completamente merecida allí como un anti-patrón. Sugiero que antes de usar cualquier sobrecarga de este tipo, especialmente el operador de asignación, uno debería pensar bien por qué esos tontos arquitectos de esos tontos lenguajes hacen eso.

Un ejemplo clásico de sobrecarga de operadores son los números complejos y las matrices. No veo nada malo en ello. Escribo operadores todo el tiempo porque el código ya no es engorroso y se puede ver la lógica de inmediato.

Lo más sencillo

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

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

[Rashid Umarov]

Vasiliy Sokolov y Combinator, por favor, dejen de insultar.

Si no, tendremos que prohibir a Volchanski por provocador :)

[TheXpert]

Vasiliy Sokolov:

No puedes conseguirme detalles específicos

¿no necesita más detalles? )) ¿Escribir código charp con asignación? ¿O mostrarme cómo escribir un constructor de copias? ¿O enumerar lenguajes con operadores de asignación? Hablar de falta de detalles y hacer falsas acusaciones contra mí es mucho más fácil que admitir que estás lleno de mierda

[TheXpert]

Rashid Umarov:

Si no, tendremos que prohibir a Wolchansky por provocador :)

No, ¿quién va a contar cuentos entonces? Prefiero ser el instigador.

[Georgiy Merts]

Vasiliy Sokolov:

No voy a dejarme provocar por odiadores analfabetos, y será mejor que explique mi punto de vista:

En los lenguajes de programación normales(no en C++)la sobrecarga del operador '=' está prohibida. Y en algunos la sobrecarga de operadores está prohibida casi por completo, porque allí es totalmente merecida como anti-patrón. Sugiero que antes de usar cualquier sobrecarga de este tipo, especialmente el operador de asignación, los que quieran, piensen bien por qué los tontos arquitectos de esos tontos lenguajes hacen eso.

¿Y por qué son "lenguajes de programación normales"?

La sobrecarga del operador de asignación es muy útil en muchos casos. El ejemplo clásico son los "punteros inteligentes". El operador de asignación no sólo debe copiar un puntero, sino también hacer AddRef() - con la sobrecarga, todo esto se hace de forma transparente.

¿Por qué es conveniente? Porque tiene mucho más sentido copiar punteros que objetos enteros. (Y con la copia intensiva en diferentes lugares del programa es difícil ver, si el objeto es necesario o no. En este caso, los smartpoints son muy útiles.

Por supuesto, existe el "recolector de basura", pero esta variante me gusta menos, precisamente porque los punteros tienen acceso completo a las referencias y al recuento de copias, mientras que el recolector de basura no. Por no hablar de que los punteros destruyen el objeto en cuanto deja de ser necesario, mientras que el recolector de basura funciona con cierto retraso.

[Yuriy Asaulenko]

George Merts:

Por supuesto, hay cosas como el "recolector de basura" - pero me gusta menos esa opción, precisamente porque los punteros tienen acceso completo a la cuenta de referencias y copias, mientras que el recolector de basura no. Por no hablar de que los punteros destruyen el objeto en cuanto deja de ser necesario, mientras que el recolector de basura funciona con cierto retraso.

Ajá, la GC, incluso ejecutada a la fuerza, no siempre borra todo. A veces esto se convierte en un problema.

[Alexey Volchanskiy]

Vasiliy Sokolov:

No voy a dejarme provocar por odiadores analfabetos, y será mejor que explique mi punto de vista:

En los lenguajes de programación normales(no en C++)la sobrecarga del operador '=' está prohibida. Y en algunos, la sobrecarga de operadores está prohibida casi por completo, ya que allí se considera merecidamente un anti-patrón. Sugiero que antes de utilizar cualquier sobrecarga de este tipo, especialmente el operador de asignación, los que quieran, piensen bien por qué los estúpidos arquitectos de esos estúpidos lenguajes hacen eso.

Nopude resistirme, personalmente a andrei: caramba, no te avergüences así. Qué tonterías dices: primero sobre FP, ahora sobre los operadores. Quieres hayterite - bienvenido: dar referencias a fuentes autorizadas, justificar, etc. Lo que está haciendo ahora es un odio rabioso y, sobre todo, totalmente analfabeto. Parece que eres un programador, como incluso uno de verdad - es vergonzoso escribir esas cosas.

Vasily, es conveniente especificar los nombres de las lenguas. Las frases "en lo normal", "en algunos", "estos" no añaden credibilidad a lo que se dice. Somos programadores, no listas blancas, así que seamos específicos en nuestras declaraciones.

[Alexey Volchanskiy]

Yuriy Asaulenko:
Uh-huh, GC, incluso cuando se alimenta a la fuerza, no siempre borra todo. A veces esto se convierte en un problema.

Si cree que es probable que el objeto se vuelva a crear pronto, no lo eliminará.