¿Hay alguna ventaja en el uso de la cadena de recursos en lugar de una cadena const?

Question

me dirías si hay alguna ventaja (menos espacio sotorage, aumentar la velocidad, etc) en el uso de:

resourcestring 
    MsgErrInvalidInputRange = 'Invalid Message Here!'; 

en lugar de

const 
    MsgErrInvalidInputRange : String = 'Invalid Message Here!'; 

Answer 1

Con resourcestring, el compilador coloca esas cadenas como una recurso de cadena de caracteres en el ejecutable, permitiendo que cualquiera (digamos su equipo de traducción) los edite con un editor de recursos sin necesidad de volver a compilar la aplicación o tener acceso al código fuente.

Answer 2

Las cadenas de recursos se almacenan como entradas STRINGTABLE en su recurso exe, las ventajas se almacenan como parte del segmento de datos fijo. Como forman parte de la sección de recursos, puede extraerlos y los DFM, traducirlos y almacenarlos en un módulo de recursos (DLL solo de datos). Cuando se inicia una aplicación Delphi, busca esa DLL y usará las cadenas de ella en lugar de las incluidas en su EXE para cargar traducciones.

El docwiki de Embarcadero cubre el uso del Translation Manager, pero muchas otras herramientas de traducción de Delphi también usan cadenas de recursos.

Answer 3

La opción const será más rápida que la cadena de recursos, porque la última llamará a la API de Windows para obtener el texto del recurso. Puede hacerlo más rápido utilizando algún mecanismo de almacenamiento en caché. Esto es lo que hacemos en nuestro Delphi RTL mejorado.

Y es una buena idea cargar primero la cadena de recursos en una cadena, si tendrá que acceder muchas veces a un contenido de cadenas de recursos.

El principal punto de la cadena de recursos es permitir i18n (internacionalización) de su programa.

Tiene el Administrador de traducciones con algunas ediciones de Delphi IDE. Pero depende de DLL externo.

Puede usar el sistema gettext, que proviene del mundo de Linux, desde http://dxgettext.po.dk que se basa en archivos .po externos.

Incluimos nuestro propio mecanismo i18n en nuestro framework, que traduce y almacena en caché el texto de la red de recursos, y se basa en archivos .txt externos (puede usar archivos de texto UTF-8 o Unicode, desde Delphi 6 hasta XE). El almacenamiento en caché lo hace tan rápido como el uso constante. Ver http://synopse.info/fossil/finfo?name=SQLite3/SQLite3i18n.pas

Existen otras soluciones comerciales o de código abierto.

Acerca del tamaño de almacenamiento, la cadena de recursos se almacena como búferes UC2. Así que la cadena de recursos utilizará más memoria que la cadena hasta Delphi 2009. Desde Delphi 2009, todas las cadenas son unicodestring, es decir, UCS2, por lo que no tendrá mucho más espacio de almacenamiento. En todos los casos, el tamaño de almacenamiento del texto no es el parámetro de mayor tamaño para una aplicación (los mapas de bits y el tamaño del código tienen un efecto mucho mayor en el ejecutable final).

Answer 4

También hay una tercera opción que es:

const MsgErrInvalidInputRange =; 'mensaje no válido aquí!'

Este último debería ser el más eficaz porque le dice al compilador que no asigne espacio en el segmento de datos, podría poner la cadena en el segmento del código.También recuerde que lo que se puede hacer con las constantes tipadas depende de la directiva $ WRITEABLECONST, aunque no sé exactamente qué es el compilador cuando está activado o desactivado.

Answer 5

Como han mencionado otros, las cadenas de cadenas de recursos se incluirán en un recurso separado dentro de su ejecutable, y como tal tienen ventajas cuando necesita atender múltiples idiomas en la interfaz de usuario de su aplicación.

Como algunos han mencionado también, las cadenas de comandos se incluyen en la sección de datos de su aplicación.

Hasta D2007

En las versiones de Delphi hasta D2007, cuerdas const se almacenan como cadenas ANSI, lo que requiere un solo byte por carácter, mientras que cadenas de recursos serían almacenados en UTF-16: las ventanas codificación por defecto (aunque quizás no para Win9x). IIRC D2007 y las versiones anteriores no admitían archivos UTF-8 codificados por unidad. Por lo tanto, cualquier cadena codificada en sus fuentes debería ser soportada por las páginas de códigos ANSI, y como tal probablemente no fuera más allá del plano multilingüe básico de Unicode. Lo que significa que solo se usaría la parte UCS-2 de UTF-16 y todas las cadenas se podrían almacenar en dos bytes por carácter.

En resumen: hasta D2007 las cadenas const toman un solo byte por caracter, las cadenas de recursos toman dos bytes por caracter.

D2009 y hasta

Delphi se ha habilitado en la versión Unicode D2009. Desde entonces las cosas son un poco diferentes. Las cadenas de cadenas de recursos todavía se almacenan como UTF-16. No hay otra opción aquí, ya que son "manejados" por Windows.

Sin embargo, las cuerdas de constelación son una historia completamente diferente. Desde D2009 Delphi almacena múltiples versiones de cada cadena const en su exe. Cada versión en una codificación diferente. Const se puede almacenar como cadenas Ansi, cadenas UTF-8 y cadenas UTF-16.

Cuál de estas codificaciones se almacena depende del uso de la const. De forma predeterminada, se usará UTf-16, ya que esa es la codificación interna predeterminada de Delphi. Asignar el mismo const a una cadena "normal" (UTF-16), así como a una variable de AnsiString, y la const se almacenará en el exe tanto UTF-16 y ANSI codificados ...

De- duping

por lo que se ve (a experimentar con el D5 y D2009), Delphi "de-engañados" cuerdas const, mientras que no hacerlo para resourcestring cuerdas.