golpe

Aunque la industria del software estandarizó en gran medida la evaluación por valor y por referencia , ^{[ 5 ]} el estudio activo de la evaluación por nombre continuó en la comunidad de programación funcional . Esta investigación produjo una serie de lenguajes de programación de evaluación perezosa en los que alguna variante de evaluación por nombre es la estrategia de evaluación estándar. Los compiladores para estos lenguajes, como el Glasgow Haskell Compiler , se han basado en gran medida en thunks, con la característica adicional de que los thunks guardan su resultado inicial para que puedan evitar recalcularlo; ^{[ 6 ]} esto se conoce como memorización o evaluación por necesidad .

Los lenguajes de programación funcional también han permitido a los programadores generar explícitamente funciones auxiliares (thunks). Esto se logra en el código fuente al encapsular una expresión de argumento en una función anónima sin parámetros propios. Esto impide que la expresión se evalúe hasta que una función receptora llame a la función anónima, consiguiendo así el mismo efecto que la llamada por nombre. ^{[ 7 ]} La adopción de funciones anónimas en otros lenguajes de programación ha hecho que esta capacidad esté ampliamente disponible.

Los thunks son útiles en plataformas de programación orientada a objetos que permiten que una clase herede múltiples interfaces , lo que da lugar a situaciones en las que se puede llamar al mismo método a través de varias interfaces. El siguiente código ilustra una situación de este tipo en C++ .

clase A { público : virtual int Access () const { return value_ ; }privado : int valor_ ; };clase B { público : virtual int Access () const { return value_ ; }privado : int valor_ ; };clase C : público A , público B { público : int Access () const override { return better_value_ ; }privado : int mejor_valor_ ; };int use ( B * b ) { return b -> Access (); }int main () { // ... B some_b ; use ( & some_b ); C some_c ; use ( & some_c ); }

En este ejemplo, el código generado para cada una de las clases A, B y C incluirá una tabla de despacho que se puede usar para llamar Accessa un objeto de ese tipo, a través de una referencia del mismo tipo. La clase C tendrá una tabla de despacho adicional, que se usa para llamar Accessa un objeto de tipo C a través de una referencia de tipo B. La expresión b->Access()usará la tabla de despacho propia de B o la tabla adicional de C, dependiendo del tipo de objeto al que se refiere b. Si se refiere a un objeto de tipo C, el compilador debe asegurarse de que Accessla implementación de C reciba una dirección de instancia para todo el objeto C, en lugar de la parte B heredada de ese objeto. ^{[ 8 ]}

Como solución directa a este problema de ajuste de punteros, el compilador puede incluir un desplazamiento entero en cada entrada de la tabla de despacho. Este desplazamiento es la diferencia entre la dirección de la referencia y la dirección requerida por la implementación del método. El código generado para cada llamada a través de estas tablas de despacho debe recuperar el desplazamiento y usarlo para ajustar la dirección de la instancia antes de llamar al método.

La solución descrita anteriormente presenta problemas similares a la implementación ingenua de llamada por nombre: el compilador genera varias copias de código para calcular un argumento (la dirección de instancia), a la vez que aumenta el tamaño de la tabla de despacho para almacenar los desplazamientos. Como alternativa, el compilador puede generar una función auxiliar de ajuste junto con la implementación de C Accessque ajuste la dirección de instancia en la cantidad requerida y luego llame al método. Esta función auxiliar puede aparecer en la tabla de despacho de C para B, eliminando así la necesidad de que quienes la llaman ajusten la dirección por sí mismos. ^{[ 9 ]}

Las funciones auxiliares (thunks) se han utilizado ampliamente para proporcionar interoperabilidad entre módulos de software cuyas rutinas no pueden llamarse directamente entre sí. Esto puede ocurrir porque las rutinas tienen convenciones de llamada diferentes , se ejecutan en distintos modos de CPU o espacios de direcciones , o al menos una se ejecuta en una máquina virtual . Un compilador (u otra herramienta) puede resolver este problema generando una función auxiliar que automatiza los pasos adicionales necesarios para llamar a la rutina de destino, ya sea transformando argumentos, copiándolos a otra ubicación o cambiando el modo de CPU. Una función auxiliar exitosa minimiza el trabajo adicional que debe realizar quien realiza la llamada en comparación con una llamada normal.

Gran parte de la literatura sobre thunks de interoperabilidad se relaciona con varias plataformas Wintel , incluyendo MS-DOS , OS/2 , ^{[ 10 ]} Windows ^{[ 11 ] [ 12 ] [ 13 ] [ 14 ]} y .NET , y con la transición del direccionamiento de memoria de 16 bits a 32 bits . A medida que los clientes han migrado de una plataforma a otra, los thunks han sido esenciales para admitir el software heredado escrito para las plataformas más antiguas. UEFI CSM es otro ejemplo de cómo hacer thunk para cargadores de arranque heredados .

La transición de código de 32 bits a 64 bits en x86 también utiliza una forma de thunking ( WoW64 ). Sin embargo, debido a que el espacio de direcciones de x86-64 es mayor que el disponible para el código de 32 bits, el antiguo mecanismo de "thunk genérico" no podía utilizarse para llamar a código de 64 bits desde código de 32 bits. ^{[ 15 ]} El único caso en el que código de 32 bits llama a código de 64 bits se da en el thunking de WoW64 de las API de Windows a 32 bits.

En sistemas que carecen de hardware de memoria virtual automática , las funciones thunk pueden implementar una forma limitada de memoria virtual conocida como superposiciones . Con las superposiciones, un desarrollador divide el código de un programa en segmentos que se pueden cargar y descargar de forma independiente, e identifica los puntos de entrada a cada segmento. Un segmento que llama a otro segmento debe hacerlo indirectamente a través de una tabla de ramificación . Cuando un segmento está en memoria, las entradas de su tabla de ramificación saltan al segmento. Cuando un segmento se descarga, sus entradas se reemplazan con "funciones thunk de recarga" que pueden recargarlo bajo demanda. ^{[ 16 ]}

De manera similar, los sistemas que enlazan dinámicamente módulos de un programa en tiempo de ejecución pueden usar thunks para conectar los módulos. Cada módulo puede llamar a los demás a través de una tabla de thunks que el enlazador completa al cargar el módulo. De esta forma, los módulos pueden interactuar sin necesidad de conocer previamente su ubicación en la memoria. ^{[ 17 ]}

• Interfaz de modo protegido de DOS (DPMI)
• Servicios de modo protegido de DOS (DPMS)
• J/Direct
• Capa de Microsoft para Unicode
• Servicios de invocación de plataforma
• Win32
• Windows en Windows
• Módulo de soporte de compatibilidad
• WoW64
• libffi
• Vino (desde la versión 9.0) ^{[ 18 ]}

• Función anónima
• Futuros y promesas
• Llamada a procedimiento remoto
• Shim (informática)
• Trampolín (informática)
• Expresión reducible