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 06: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 11: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 19:15:47. |
#9
|
||||
|
||||
Cita:
Y si no, ¿por qué en C++ sí es seguro y en Delphi no? LineComment Saludos |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Sobrecarga de propiedades | jzginez | OOP | 2 | 21-02-2014 17:58:09 |
Duda operadores de clase | waremovil | C++ Builder | 4 | 22-02-2012 08:58:46 |
Sobrecarga de constructores | vejerf | OOP | 2 | 06-06-2008 12:52:36 |
Polimorfismo y sobrecarga | davitcito | Varios | 3 | 15-04-2005 19:56:11 |
sobrecarga de operadores | zuriel_zrf | Varios | 1 | 11-09-2003 13:08:36 |
|