Pregunta

Trasfondo

Estoy trabajando en un programa de conversión fonética que convierte el texto en inglés en texto equivalente en el idioma regional. Los idiomas regionales tendrán más caracteres que las letras en inglés y las fuentes de idiomas regionales utilizan casi todas las posiciones (1-255) en una fuente.

Mi programa admite diferentes fuentes y he creado una clase de fuente que tendrá métodos para dar acceso a los caracteres. Esta clase tendrá 255 métodos que representan cada personaje. Todos estos están marcados como virtual para que una nueva fuente pueda anular los métodos de caracteres necesarios.

Los métodos en esta clase de fuente son triviales. Todos los métodos son de una sola línea. El ejemplo sería

string StandardFont::consonant1(){
    return "a";
}

string StandardFont::consonant2(){
    return "b";
}

..

Preguntas

  1. ¿255 funciones virtuales en una sola clase causarán problemas de rendimiento? Sé sobre vtable cosas, pero no estoy seguro de cuánto impacto tiene en este escenario.
  2. ¿Alguien puede sugerir un diseño alternativo para esta clase? El objetivo principal del diseño es permitir que las clases derivadas anulen los métodos necesarios. He pensado en agregar los caracteres en contenedores como mapa o vector y proporcionar un método para obtener el carácter. Pero dado que tendré 255 elementos y esta clase se usa con frecuencia, creo que cada vez que tengo que recorrer el contenedor para obtener el personaje, lo que nuevamente es un problema.

¿Alguna idea?

¿Fue útil?

Solución

Le sugiero que utilice una codificación estándar de caracteres no ASCII (regionales).

Una codificación estándar se llama " unicode " ;, por ejemplo http://www.joelonsoftware.com/articles/Unicode.html

De todos modos: para responder a sus preguntas ...

  

¿255 funciones virtuales en una sola clase causarán problemas de rendimiento?

En una palabra: no, no lo hará.

  

Pero como tendré 255 elementos y esta clase se usa con frecuencia, creo que cada vez que tengo que hacer un bucle en el contenedor para obtener el personaje, lo que nuevamente es un problema.

Con un vector o una matriz de longitud fija cuya longitud es 256, no necesitaría hacer un bucle ... en su lugar, podría indexar directamente, por ejemplo:

const char* translations[256] = {
 "a",
 "bee",
 "c!",
 ...etc...
};

const char* translate(char c)
{
  //use the character as an index into the array
  int index = c;
  //use the translation array (using indexing, not looping)
  const char* result = translations[index];
  return result;
}

Otros consejos

255 funciones virtuales generalmente no causarán problemas de rendimiento (excepto que cada instancia de su clase tendrá una gran tabla virtual que afectará muy marginalmente el almacenamiento en caché).

Sin embargo, 255 funciones virtuales generalmente causarán una pesadilla de mantenimiento.

Si entiendo su descripción correctamente, entonces lo que necesita es:

1) Cree una clase que represente un personaje en un idioma regional, probablemente con métodos para devolver la imagen o lo que necesite.

2) Crear es una jerarquía de clases que representan conjuntos de caracteres.

3) Cada instancia de un conjunto de caracteres mantendrá una asignación de posiciones a instancias de la clase de caracteres.

4) Tener una función que obtenga el índice y devuelva el objeto.

Una ventaja de este diseño es que puede tener varios conjuntos de caracteres utilizando algunos de los mismos glifos (por ejemplo, para números).

Dicho todo esto, ¿por qué no estás usando caracteres Unicode y de 16 bits?

Creo que sería más limpio usar un solo método para acceder al personaje en lugar de 255 métodos. La indexación / subscripción viene a la mente.

¿Puede aclarar cómo se deben usar estas clases? Como los idiomas y los alfabetos son diferentes, me parece extraño que se refiera a más de una letra de la misma manera. Las letras son, desde cualquier perspectiva, arbitrarias. Serán diferentes y no estarán relacionados en los diferentes idiomas.

El objetivo de Unicode es proporcionar una solución a su problema. ¿Has considerado usarlo?

Abordar su cuestión de velocidad, tener 255 métodos virtuales no debería causar ninguna penalización de rendimiento particular, aunque se aplica el consejo habitual: si no está seguro de cómo funcionará, la única forma de averiguarlo será compararlo

Dicho esto, es muy probable que haya una mejor manera de abordar el problema. Ayudará si proporciona más detalles sobre lo que se supone que debe hacer esta clase de fuente.

¿por qué no solo tener un vector de 255 caracteres?

cada " font " simplemente instala diferentes caracteres en la matriz? o incluso una clase de personaje?

o podría usar un mapa u otra cosa

255 métodos definitivamente no es el camino a seguir.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top