Sobrecarga de operadores de clase
 

Pues eso, aunque se supone que Delphi no soporta sobrecargar los operadores de clase como si sucede con los tipos records o registros, existe cierta sintaxis que lo hace posible, apartentemente no documentada ni oficial

En fin, no se como lo habra descubierto el que lo hizo, o de donde lo saco. La cuestion es que ha publicado dos fragmentos de codigo en GitHub, aca y aca

Sorprendentemente este codigo compila, funciona y no hay fugas de memoria, en Delphi 2010 y Delphi 10.1 Berlin, asi que supongo que "la compatibilidad se mantiene" en todas las versiones del medio.

Código Delphi [-]
program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  Classes;

type
  TStringListHelper = class helper for TStringList
  public
    class function &&op_In(const Value: string; Target: TStringList): Boolean; static;
    class function &&op_LogicalOr(A, B: TStringList): TStringList; static;
  end;

class function TStringListHelper.&&op_In(const Value: string; Target: TStringList): Boolean;
begin
  Result := Target.IndexOf(Value) <> -1;
end;

class function TStringListHelper.&&op_LogicalOr(A, B: TStringList): TStringList;
begin
  if A <> nil then
    Result := A
  else
    Result := B;
end;

procedure Test;
var
  StringListA, StringListB, StringListC: TStringList;
begin
  StringListA := nil;
  StringListB := TStringList.Create;
  try
    StringListB.Add('Hola mundo');
    StringListC := StringListA or StringListB; // -> StringListC apunta al mismo objeto que StringListB
    Writeln('StringListB.Text: ' + StringListB.Text); // imprime hola mundo
    Writeln('StringListC.Text: ' + StringListC.Text); // imprime hola mundo
    Writeln(BoolToStr(StringListB = StringListC, True)); // imprime True
    Writeln(BoolToStr('Hola mundo' in StringListB, True)); // imprime True
    Writeln(BoolToStr('blabla' in StringListB, True)); // imprime False
  finally
    StringListB.Free;
  end;
end;

begin
  ReportMemoryLeaksOnShutdown := True;
  try
    Test;
    Readln;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

Me parece algo realmente poderoso y peligroso al mismo tiempo, no he podido ordenar mis ideas por el momento

Realmente algo como esto si que es util para escribir codigo mas elegante y sencillo. Muchas veces se emplea el uso de records como envolturas de clases o tipos primitivos ya que ellos son los unicos con los que se pueden sobrecargar los operadores; pero esto lo lleva a otro nivel

De hecho es posible hasta con genericos como se puede ver en el codigo del autor

Sí que sí, bastante interesante, me he preguntado desde hace tiempo ¿Cuál será la razón para que la sobrecarga de operadores no esté soportada de manera nativa en las clases?, pues como bien indicas esto es poderoso aunque a la vez peligroso.

¿Cómo habrá sabido este personaje que tenía que anteponer &&op_ al nombre de cada operador? :D

Bastante interesante, el truco y lo que habrá detrás de dicha conclusión.

P.D: Sólo anotar, que me parece muy curiosa la observación que hace un usuario diciendo que no funciona en Records :D

Interesante, Agustín. Al estar depurando, con la ventana CPU, me parece haber visto nombres similares a esos. Quizá de ahí el descubridor obtuvo los nombres "reales" que les da el compilador a esos métodos.

Sólo los compiladores con ARC (Delphi para dispositivos móviles) admiten la sobrecarga "formal" de operadores en clases, ya que en ellos puede uno despreocuparse por las instancias "intermedias" que se crean a mitad de algunas operaciones, dado que todos los objetos usan un contador de referencias, tal como lo hacen los String en cualquiera de los compiladores de Delphi.

Creo que la explicación al truco podría estar en que sólo el revisor sintáctico del compilador impide la declaración en clases, pero el resto de la compilación se realiza asumiendo que ya se superaron las validaciones sintácticas de plataforma y procede sin restricciones (asumiendo también el nombre transformado del método).

Resulta tentador empezar a aprovechar esta puerta trasera en los compiladores de escritorio, pero ya aprendí la lección, y es mejor prescindir de características del compilador no oficiales. Además hay que tener cuidado no de aplicar ningún operador que deje un objeto "suelto" por ahí. :p

¡Qué hallazgo! :)

Este me ha gustado mucho.
^\||/^\||/^\||/^\||/^\||/

Marco Cantú ha confirmado que esto es una puerta trasera, que es una característica no intencionalmente puesta a nuestro alcance, tal y como comenta nuestro amigo Al González

Los operadores que crean objetos intermedios seguro que ocasionan fugas de memoria.

Aún así me parece un juguetito muy interesante y que tiene mucha tela por donde cortar.

Esta es la lista completa de operadores:

A mi también me ha gustado mucho el operador in. Y el del or para usar un objeto u otro en caso de nil también me parece que tiene mucho juego

En fin, es cuestión de creatividad. Pero ya hemos sido advertidos: es posible que solucionen este defecto

Para mi siempre ha sido algo natural la sobrecarga de operadores que uso bastante, ahorrándome código y proporcionando limpieza e intuición al código. Estoy hablando de C++
Siempre lo he echado en falta en delphi.

Saludos.

En C++ o los lenguajes con recoleccion de basura es seguro tener operadores de clase.

En Delphi que no es necesariamente el caso, puede haber muchas fugas de memoria, y creo que ese es el motivo por el cual no tenemos a nuestra disposicion sobrecarga de operadores. Al menos no para el compilador para Windows; los que implementan ARC, como señalo Al, si que permiten la sobrecarga

Los record son un caso especial porque Delphi se encarga de manejar la memoria por nosotros y entonces no hay problema

A mi tambien siempre me hacian mucha falta en Delphi.. seria muy bueno poder tener esta sintaxis de manera oficial, por lo menos en interfaces que si implementan el mecanismo de contador de referencias

Otro detalle es que no necesariamente hay que usar un ayudante de clase como esta mas arriba. Es posible utilizar una subclase para lograr el mismo efecto; o tambien el viejo truco de la clase interpuesta

Código Delphi [-]
  TStringListEx = class(TStringList)
  public
    class function &&op_In(const Value: string; Target: TStringListEx): Boolean; static;
    class function &&op_LogicalOr(A, B: TStringListEx): TStringListEx; static;
  end;

Código Delphi [-]
  TStringList = class(Classes.TStringList)
  public
    class function &&op_In(const Value: string; Target: TStringList): Boolean; static;
    class function &&op_LogicalOr(A, B: TStringList): TStringList; static;
  end;

Hablando de estas cosas, yo sueño con el día en que pueda escribir en Delphi "expresiones de asignación" como

Código Delphi [-]
...

If ... Then
  If (A := B) > 10 Then  // <---
    ...

...

en lugar de

Código Delphi [-]
...

If ... Then
  If TghSys.SetInt (A, B) > 10 Then  // <---
    ...

...

que suelo escribir en lugar de

Código Delphi [-]
...

If .. Then
Begin  // <---
  A := B;  // <---

  If A > 10 Then  // <---
    ...
End;  // <---

...

Un abrazo esperanzador. :)

Al González.

¿C++ tiene recolector de basura? :eek:

Y si no, ¿por qué en C++ sí es seguro y en Delphi no?

LineComment Saludos

¡Anda! Ahora sí me sorprendiste. ¿Tú soñando con una característica típica del lenguaje C? :rolleyes:

LineComment Saludos

Ay ay me equivoque :)

El que recolecta basura era el C#

Me lo has quitado de la boca... :)

El lenguaje C tiene algunas cosas muy buenas, Román. ;)

Eso lo sé, pero pensé que tú no :D

Pero ya en serio, me causa curiosidad el uso que deseas, quizá por no tener contexto. En lo particular, esa característica (que la asignación sea un operador) casi sólo la uso para ciclos en los que obtengo y uso un dato:

En otros casos, puede devenir en una lectura confusa.

LineComment Saludos

Ok. Pero entonces, ¿qué hace que C++ si pueda tener el operator overloading y delphi no?

LineComment Saludos

Un parentesis pequeño, sólo para mostrar el recolector de basuras de C#



P.D: Perdón, no pude evitarlo. :D

QUe C++ es el frankestein de los lenguajes y le inyectan toda caracteristica bajo el sol. Prácticamente puedes programar como si estuvieras en otro lenguaje abusando de C++ como te de la gana.


Delphi, por el contrario, fue derivado de alguien que *diseño* el lenguaje:

http://pascal-central.com/ppl/#Origins

Delphi/Pascal tiene un compilador veloz *PRECISAMENTE* por ser tan anti-C++ como es posible.

----

Ahora, lograr poder sobrecargar operadores no es en si algo tan problematico... excepto que en los lenguajes imperativos existe una división entre expresiones, clases, tipos, statements (bloques), etc. Si Delphi fuera un lenguaje unificado a todo es una expresión esto sería un cambio trivial.

Tambien *supongo* que no seria trivial el darle una disponibilidad universal y que efectos tendria con el chequeo e intersección de tipos y si quedaria oscurecido el código por su uso. Esto no lo he pensando asi que es pura especulación.
---

En ultimas hay cambios a los lenguajes que los alteran de forma fundamental. Intentar agregarles cosas puede terminar siendo poco "idiomático" o convertirse en una característica de nicho poco usada pero que igual tiene su coste en mantenimiento e implementación.


P.D: Esta es una caracteristica que no es tan problematica si esta bien implementada, y NO SE PERMITE redefinir o crear nuevos operadores al vuelo (un problema que termina creando diversos codigos con el mismo operador pero diferente semantica!). Si esta limitado a unos pocos es muy util!

¿Qué tendrá C/C++ que es tan envidiado y odiado?

Saludos.

C me gusta, C++ no me gusta :)

Ya pero características propias de C++ son tan envidiadas cómo el propio C. No será tan malo, diho yo. :) A mi me gustan ambos y delphi también.

Saludos