FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
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.
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 |
#2
|
||||
|
||||
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? 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
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!" http://www.purodelphi.com/ http://www.nosolodelphi.com/ Última edición por jhonny fecha: 29-11-2016 a las 07:28:20. Razón: Quitar gazapo |
#3
|
||||
|
||||
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í. ¡Qué hallazgo! |
#4
|
||||
|
||||
Cita:
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#5
|
||||
|
||||
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: Cita:
En fin, es cuestión de creatividad. Pero ya hemos sido advertidos: es posible que solucionen este defecto Última edición por AgustinOrtu fecha: 29-11-2016 a las 12:10:44. |
#6
|
||||
|
||||
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. |
#7
|
||||
|
||||
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
|
#8
|
||||
|
||||
Hablando de estas cosas, yo sueño con el día en que pueda escribir en Delphi "expresiones de asignación" como
en lugar de que suelo escribir en lugar de
Un abrazo esperanzador. Al González. Última edición por Al González fecha: 29-11-2016 a las 20:15:47. |
#9
|
||||
|
||||
Cita:
Y si no, ¿por qué en C++ sí es seguro y en Delphi no? LineComment Saludos |
#10
|
||||
|
||||
Cita:
LineComment Saludos |
#11
|
||||
|
||||
Ay ay me equivoque
El que recolecta basura era el C# |
#12
|
||||
|
||||
Me lo has quitado de la boca...
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#13
|
||||
|
||||
El lenguaje C tiene algunas cosas muy buenas, Román.
|
#14
|
||||
|
||||
Eso lo sé, pero pensé que tú no
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: Código:
/* DameRegistro devuelve el siguiente registro o FALSE si no hay más registros */ WHILE registro = DameOtro() DO BEGIN MuestraRegistro(registro) END LineComment Saludos |
#15
|
||||
|
||||
Ok. Pero entonces, ¿qué hace que C++ si pueda tener el operator overloading y delphi no?
LineComment Saludos |
#16
|
||||
|
||||
Un parentesis pequeño, sólo para mostrar el recolector de basuras de C#
P.D: Perdón, no pude evitarlo.
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!" http://www.purodelphi.com/ http://www.nosolodelphi.com/ |
#17
|
||||
|
||||
Cita:
Delphi, por el contrario, fue derivado de alguien que *diseño* el lenguaje: http://pascal-central.com/ppl/#Origins Cita:
---- 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!
__________________
El malabarista. |
#18
|
||||
|
||||
¿Qué tendrá C/C++ que es tan envidiado y odiado?
Saludos. |
#19
|
||||
|
||||
C me gusta, C++ no me gusta
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#20
|
||||
|
||||
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 |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Sobrecarga de propiedades | jzginez | OOP | 2 | 21-02-2014 18:58:09 |
Duda operadores de clase | waremovil | C++ Builder | 4 | 22-02-2012 09:58:46 |
Sobrecarga de constructores | vejerf | OOP | 2 | 06-06-2008 13:52:36 |
Polimorfismo y sobrecarga | davitcito | Varios | 3 | 15-04-2005 20:56:11 |
sobrecarga de operadores | zuriel_zrf | Varios | 1 | 11-09-2003 14:08:36 |
|