¿Qué sucede realmente en el back-end cuando se comparan dos cadenas?

Existen diferencias para los tipos de comparación, como cómo manejar la longitud. Sin embargo, en general, todos comienzan con un índice en el inicio de ambas cadenas. Los caracteres en ese índice serán recuperados y comparados. Si está trabajando con ASCII, una comparación numérica de su valor de byte es suficiente para decidir si son iguales o si uno es mayor o menor que el otro. Por menor que o mayor que devolver ese resultado de comparación. Para igual, incremente el índice y repita el proceso hasta encontrar una desigualdad. Si llega al final de ambas cadenas con igual, regrese igual, pero si llega al final de una cadena, tendrá que decidir cómo manejar eso.

Entonces, en los días de ASCII, esto era fácil, tan fácil que podía escribir su propia cadena de comparación en una mano llena de líneas. Entra en Unicode y las cosas se vuelven un poco locas. UTF-16 requeriría que leyeras dos bytes y potencialmente lo convirtieras en un solo orden de bytes. También requiere que el software descubra si el carácter tiene dos pares de bytes de largo y vuelva a ensamblar en caso de que lo sean. Microsoft ha seguido este camino con una rica colección de rutinas basadas en versiones amplias de los clásicos ASCII. Creo que esta es una situación menos que óptima. Utiliza bytes adicionales para todo y es difícil trabajar con una forma inconsistente de manejo de caracteres. Podría escribir una comparación similar llamando a una función de recuperación de caracteres que consume los bytes necesarios y devuelve el índice, pero habrá muchas cosas debajo de las cubiertas.

Aparentemente, los chicos originales de Unix sintieron lo mismo. Crearon una opción compatible con ASCII llamada UTF-8. Mira el primer bit y determina si se usa un solo byte o si se necesitan más. Si se establece el primer bit, los bits que siguen inmediatamente determinan el número a leer y cambian a un número de 32 bits. Puede escribir este código para consumir bytes y devolver caracteres e índices en una función relativamente pequeña.

El siguiente problema proviene de lo que significa mayor o menor que. ¿Cada conjunto de caracteres tiene un orden natural o el punto de código en Unicode es un orden artificial? Cada conjunto de caracteres tendrá un orden artificial en comparación con otros conjuntos. La lista continua. El orden Lexigraphic es difícil en estos casos.

Depende del idioma.

En Lua, todas las cadenas (más pequeñas que una longitud definida) se combinan en el tiempo de análisis o en el momento de creación de la cadena. Cuando se comparan, Lua solo puede comparar los hashes, que es súper rápido.

En muchos idiomas, las cadenas solo se comparan un byte a la vez. Pero hay optimizaciones como comparar una palabra de procesador a la vez que un lenguaje o biblioteca puede usar. La biblioteca C para memcmp () a menudo se implementa utilizando un algoritmo optimizado como ese.

Pero a excepción del enfoque Lua de cadenas de pre-hashing, el algoritmo para comparar cadenas de cadenas de longitud idéntica sigue siendo siempre O (n). Incluso el hash tiene que ser O (n), pero se puede extraer de los bucles: un bucle O (n) que compara cadenas en la mayoría de los idiomas terminaría en O (n * m) (donde m representa la longitud de la cadena), mientras que en Lua se quedaría O (n).

No estoy seguro de lo que quiere decir con “en la parte de atrás”.

Si simplemente quiere saber cómo se comparan dos cadenas, depende del algoritmo elegido. Algunos son mucho más rápidos que la fuerza bruta de comparar cada byte usando el mismo índice en cada cadena.

Algunos algoritmos crean una tabla para permitirle omitir secciones de una cadena rápidamente, por lo que no se compara cada byte (uno usa el primer y el último byte para ver si hay una coincidencia y determina la cantidad de omisión en función de la tabla, otro aprovecha de características arquitectónicas, y puede comparar 8 bytes a la vez, después de hacer una configuración de alineación para las cadenas …)

Entonces todo depende de lo que quieras saber. Los métodos particulares no siempre son apropiados.