Se ha añadido StringLen a la prueba y se ha inicializado la cadena de forma diferente. La documentación dice una cosa, el comportamiento real es diferente. Y el buffer en este caso muestra 0 en lugar de 260.
La documentación especifica cuándo se devuelve 0 y es apropiado para el caso especificado
La documentación no coincide en absoluto con el comportamiento actual.
Documentación: Un valor de 0 significa que la cadena es una constante y el contenido del buffer no puede ser modificado.
La cadena se inicializa con la constante "_" y el compilador considera la cadena condicionalmente (por razones de eficiencia) como una constante - ¿por qué no? ¿Por qué hay una contradicción? Sobre todo porque no se realizan más operaciones con él.
Creo que lo he conseguido con el número 260, el propio compilador asigna el tamaño inicial del bufferStringBufferLen a 260. Si la longitud de la cadena es inferior a 260, el StringBufferLen imprimirá 260, ¡no la longitud real de la cadena! Y si la longitud de la cadena es mayor que 260, entonces se imprime el valor real de la cadena.
Así, utilizando la función StringBufferLen, con una longitud de cadena inferior a 260 caracteres, no obtendremos la longitud real de la cadena, y siempre obtendremos 260. Esto debe ser un error. En cuanto la longitud supere los 260 caracteres, obtendremos la longitud real de la cadena.
p.d. como la documentación está desfasada es muy engañosa.
Es decir, utilizando la función StringBufferLen, con una longitud de cadena inferior a 260 caracteres, no obtendremos la longitud real de la cadena, y siempre obtendremos 260. Esto debe ser un error. En cuanto la longitud supere los 260 caracteres, obtendremos la longitud real.
Estrictamente hablando, la longitud de la cadena: StringLen y la longitud del buffer: StringBufferLen son funciones bastante raras. Y en general pueden no coincidir.
Eso hace que haya dos casos al menos cuestionables:
voidOnStart()
{
string s1 = "_";
Print(StringBufferLen(s1)); //(1)//Ожидалось 260 вместо 0 - строка s1 далее может быть увеличенаStringInit(s1,1,'_');
conststring s2 = s1;
Print(StringBufferLen(s2)); //(2)//Ожидалось 0\1 вместо 260 - строка s2 константная и не может быть далее увеличена
}
El error de optimización del probador de estrategias aún no se ha solucionado.
Por favor, corrige.
La configuración de optimización que utilizo es equilibrio + ratio de nitidez, pero se muestra un valor de optimización anormal como en la captura de pantalla, y la optimización normal debido a este valor anormal se genera en la generación de optimización posterior. Es imposible.
La optimización que estoy utilizando es balance + sharp, pero el valor de optimización anormal se muestra como en la captura de pantalla y la optimización normal debido a este valor anormal se genera en la generación de optimización posterior. Esto no es posible
El tamaño de la memoria de la cadena preasignada es una cuestión interna del compilador y no se puede confiar en ella.
Los resultados de la ejecución muestran que el compilador actúa de forma contraria a la lógica:
Para una cadena constante se asigna más memoria de la necesaria (en principio no se puede aumentar su longitud)
Para una cadena no constante, no se asigna memoria adicional (si se aumenta su longitud, se requerirá una nueva asignación de memoria)
Si un usuario inicializa una cadena con StringInitInit, se asigna más memoria de la necesaria, ya que el tamaño del buffer es establecido explícitamente por el usuario y en la mayoría de los casos no se incrementará (el usuario ya ha pensado qué buffer final necesita y ha establecido su tamaño explícitamente)
Los resultados de la ejecución muestran que el compilador actúa de forma contraria a la lógica:
Para una cadena constante se asigna más memoria de la necesaria (en principio no se puede aumentar su longitud)
Para una cadena no constante, no se asigna memoria adicional (si se aumenta su longitud, se requerirá una nueva asignación de memoria).
Si un usuario inicializa una cadena con StringInitInit, se asigna más memoria de la necesaria, porque el tamaño del buffer es definido explícitamente por el usuario, y en la mayoría de los casos, no se incrementará (el usuario ya ha pensado qué buffer final necesita y ha definido su tamaño explícitamente)
La preasignación del tamaño de los búferes para las cadenas es una cuestión interna del compilador.
Cambiaremos el manejo de las cadenas muchas veces más.
Se ha añadido StringLen a la prueba y se ha inicializado la cadena de forma diferente. La documentación dice una cosa, el comportamiento real es diferente.
Y el buffer en este caso muestra 0 en lugar de 260.
La documentación especifica cuándo se devuelve 0 y es apropiado para el caso especificado
La documentación indica cuándo se devuelve el 0 y es adecuada para el caso indicado
La documentación no coincide en absoluto con el comportamiento actual.
Y los resultados son diferentes ))¿Cuál es la diferencia entre los dos tipos de inicialización?
Y no está claro de dónde viene el número 260 de la izquierda.
La documentación no coincide en absoluto con el comportamiento actual.
Documentación: Un valor de 0 significa que la cadena es una constante y el contenido del buffer no puede ser modificado.
La cadena se inicializa con la constante "_" y el compilador considera la cadena condicionalmente (por razones de eficiencia) como una constante - ¿por qué no? ¿Por qué hay una contradicción? Sobre todo porque no se realizan más operaciones con él.
Y en general no está claro de dónde viene el número 260 de la izquierda.
El moderador explicó de dónde venía, y por qué en el caso de
no aparece - motivo de comprobación
El moderador aclaró de dónde procedía la
Creo que lo he conseguido con el número 260, el propio compilador asigna el tamaño inicial del bufferStringBufferLen a 260.
Si la longitud de la cadena es inferior a 260, el StringBufferLen imprimirá 260, ¡no la longitud real de la cadena!
Y si la longitud de la cadena es mayor que 260, entonces se imprime el valor real de la cadena.
Así, utilizando la función StringBufferLen, con una longitud de cadena inferior a 260 caracteres, no obtendremos la longitud real de la cadena, y siempre obtendremos 260.
Esto debe ser un error.
En cuanto la longitud supere los 260 caracteres, obtendremos la longitud real de la cadena.
p.d. como la documentación está desfasada es muy engañosa.
Es decir, utilizando la función StringBufferLen, con una longitud de cadena inferior a 260 caracteres, no obtendremos la longitud real de la cadena, y siempre obtendremos 260.
Esto debe ser un error.
En cuanto la longitud supere los 260 caracteres, obtendremos la longitud real.
Estrictamente hablando, la longitud de la cadena: StringLen y la longitud del buffer: StringBufferLen son funciones bastante raras. Y en general pueden no coincidir.
Eso hace que haya dos casos al menos cuestionables:
Los resultados de la ejecución muestran que el compilador actúa de forma contraria a la lógica:
Los resultados de la ejecución muestran que el compilador actúa de forma contraria a la lógica:
La preasignación del tamaño de los búferes para las cadenas es una cuestión interna del compilador.
Cambiaremos el manejo de las cadenas muchas veces más.