Adicionou StringLen ao teste, e inicializou a corda de forma diferente. A documentação diz uma coisa, o comportamento real é diferente. E o tampão neste caso mostra 0 em vez de 260.
A documentação especifica quando 0 é devolvido e é apropriado para o caso especificado
A documentação não corresponde em nada ao comportamento atual!
Documentação: Um valor de 0 significa que a string é uma constante e que o conteúdo do buffer não pode ser alterado.
A cadeia é inicializada com um "_" constante e o compilador considera a cadeia condicionalmente (para fins de eficiência) uma constante - por que não? Por que existe uma contradição? Tanto mais que não são realizadas mais operações com ele.
Acho que consegui com o número 260, o próprio compilador aloca o tamanho inicial do bufferStringBufferLen a 260. Se o comprimento da corda for inferior a 260, a StringBufferLen imprimirá 260, não o comprimento real da corda! E se o comprimento da corda for maior que 260, então o valor real da corda é impresso.
Portanto, usando a função StringBufferLen, com um comprimento de corda inferior a 260 caracteres, não teremos o comprimento real da corda, e sempre teremos 260. Isto deve ser um erro. Assim que o comprimento exceder 260 caracteres, teremos o comprimento real da corda.
p.s. como a documentação está desatualizada, é muito enganosa.
Ou seja, usando a função StringBufferLen, com um comprimento de corda inferior a 260 caracteres, não teremos o comprimento real da corda, e sempre teremos 260. Isto deve ser um erro. Assim que o comprimento exceder 260 caracteres, teremos o comprimento real.
Estritamente falando, o comprimento das cordas: StringLen e comprimento do buffer: StringBufferLen são funções bastante raras. E, em geral, podem não coincidir.
Isso faz com que haja pelo menos dois casos questionáveis:
voidOnStart()
{
string s1 = "_";
Print(StringBufferLen(s1)); //(1)//Ожидалось 260 вместо 0 - строка s1 далее может быть увеличенаStringInit(s1,1,'_');
conststring s2 = s1;
Print(StringBufferLen(s2)); //(2)//Ожидалось 0\1 вместо 260 - строка s2 константная и не может быть далее увеличена
}
O bug de otimização do testador de estratégia ainda não foi corrigido.
Por favor, corrija.
A configuração de otimização que eu uso é equilíbrio + relação nítida, mas um valor de otimização anormal é exibido como na captura de tela, e a otimização normal devido a este valor anormal é gerada na geração de otimização subseqüente. Isso é impossível.
A otimização que estou usando é equilíbrio + nítida, mas o valor de otimização anormal é mostrado como na captura de tela e a otimização normal devido a este valor anormal é gerada na geração de otimização subseqüente. Isto não é possível
O tamanho da memória de cordas pré-alocada é uma questão interna do compilador e você não pode contar com ela.
Os resultados da execução mostram que o compilador age de forma contrária à lógica:
Para uma cadeia constante é alocada mais memória do que o necessário (em princípio, seu comprimento não pode ser aumentado)
Para uma cadeia não-constante, nenhuma memória adicional é alocada (se seu comprimento for aumentado, uma nova alocação de memória será necessária)
Se um usuário inicializa uma string com StringInitInit, mais memória é alocada do que o necessário, porque o tamanho do buffer é explicitamente definido pelo usuário e na maioria dos casos não será aumentado (o usuário já pensou em qual buffer final ele precisa e definiu seu tamanho explicitamente)
Os resultados da execução mostram que o compilador age de forma contrária à lógica:
Para uma cadeia constante é alocada mais memória do que o necessário (em princípio, seu comprimento não pode ser aumentado)
Para uma cadeia não-constante, nenhuma memória adicional é alocada (se seu comprimento for aumentado, uma nova alocação de memória será necessária).
Se um usuário inicializa uma string com StringInitInit, mais memória é alocada do que o necessário, porque o tamanho do buffer é explicitamente especificado pelo usuário e, na maioria dos casos, não será aumentado (o usuário já pensou em qual buffer final ele precisa e especificou seu tamanho explicitamente)
O tamanho de pré-alocação de amortecedores para cordas é uma questão interna do compilador.
Mudaremos o manuseio das cordas muitas mais vezes.
Adicionou StringLen ao teste, e inicializou a corda de forma diferente. A documentação diz uma coisa, o comportamento real é diferente.
E o tampão neste caso mostra 0 em vez de 260.
A documentação especifica quando 0 é devolvido e é apropriado para o caso especificado
A documentação indica quando 0 é devolvido e é apropriado para o caso indicado
A documentação não corresponde em nada ao comportamento atual!
E os resultados são diferentes ))Qual é a diferença entre os dois tipos de inicialização?
E não está claro de onde vem o número 260 da esquerda.
A documentação não corresponde em nada ao comportamento atual!
Documentação: Um valor de 0 significa que a string é uma constante e que o conteúdo do buffer não pode ser alterado.
A cadeia é inicializada com um "_" constante e o compilador considera a cadeia condicionalmente (para fins de eficiência) uma constante - por que não? Por que existe uma contradição? Tanto mais que não são realizadas mais operações com ele.
E em geral não está claro de onde vem o número 260 da esquerda.
O moderador explicou de onde, e por que no caso de
não aparece - razão para verificar
O moderador esclareceu de onde
Acho que consegui com o número 260, o próprio compilador aloca o tamanho inicial do bufferStringBufferLen a 260.
Se o comprimento da corda for inferior a 260, a StringBufferLen imprimirá 260, não o comprimento real da corda!
E se o comprimento da corda for maior que 260, então o valor real da corda é impresso.
Portanto, usando a função StringBufferLen, com um comprimento de corda inferior a 260 caracteres, não teremos o comprimento real da corda, e sempre teremos 260.
Isto deve ser um erro.
Assim que o comprimento exceder 260 caracteres, teremos o comprimento real da corda.
p.s. como a documentação está desatualizada, é muito enganosa.
Ou seja, usando a função StringBufferLen, com um comprimento de corda inferior a 260 caracteres, não teremos o comprimento real da corda, e sempre teremos 260.
Isto deve ser um erro.
Assim que o comprimento exceder 260 caracteres, teremos o comprimento real.
Estritamente falando, o comprimento das cordas: StringLen e comprimento do buffer: StringBufferLen são funções bastante raras. E, em geral, podem não coincidir.
Isso faz com que haja pelo menos dois casos questionáveis:
Os resultados da execução mostram que o compilador age de forma contrária à lógica:
Os resultados da execução mostram que o compilador age de forma contrária à lógica:
O tamanho de pré-alocação de amortecedores para cordas é uma questão interna do compilador.
Mudaremos o manuseio das cordas muitas mais vezes.