Добавил в тест StringLen, и инициализировал строку по другому. В документации одно, по факту совсем другое поведение. И буфер в этом случае показывает 0 а не 260.
В документации указано, когда возвращается 0 и он подходит для указанного случая
Документация вообще не соответствует текущему поведению!
Документация: Значение 0 означает, что строка – константная и содержимое буфера менять нельзя.
Строка инициализирована константой "_" и компилятор считает строку условно (для целей эффективности) константной - почему бы и нет? В чем противоречие? Тем более что далее с ней не происходит никаких операций.
С числом 260 вроде понял, компилятор сам выделяет буферу StringBufferLen начальный размер в 260. И если длина строки меньше 260, то StringBufferLen выводит именно 260, а не реальную длину строки! А если длина строки больше 260, тогда выводиться реальное значение строки.
То есть пользуясь функцией StringBufferLen, с длиной строки менее 260 символов, мы не получим реальную длину строки, и будем получать всегда 260. Видимо в этом и есть ошибка. Как только срока превысит 260 символов, тогда получаем реальное значение длины.
p.s. так как документация устаревшая это жесть как вводит в заблуждение.
То есть пользуясь функцией StringBufferLen, с длиной строки менее 260 символов, мы не получим реальную длину строки, и будем получать всегда 260. Видимо в этом и есть ошибка. Как только срока превысит 260 символов, тогда получаем реальное значение длины.
Строго говоря длина строки: StringLen, а длина буфера: StringBufferLen - довольно редкая функция. И в общем случае они могут и не совпадать
Итого два как минимум сомнительных случая:
voidOnStart()
{
string s1 = "_";
Print(StringBufferLen(s1)); //(1)//Ожидалось 260 вместо 0 - строка s1 далее может быть увеличенаStringInit(s1,1,'_');
conststring s2 = s1;
Print(StringBufferLen(s2)); //(2)//Ожидалось 0\1 вместо 260 - строка s2 константная и не может быть далее увеличена
}
The strategy tester optimization bug has not been fixed yet.
Please correct.
The optimization setting I use is balance + sharp ratio, but an abnormal optimization value is displayed as in the screenshot, and normal optimization due to this abnormal value is generated in the subsequent optimization generation. It is impossible.
Оптимизация, которую я использую, - это баланс + резкое соотношение, но ненормальное значение оптимизации отображается, как на скриншоте, и в последующем генерации оптимизации создается нормальная оптимизация из-за этого ненормального значения. Это невозможно
Преаллоцированный размер памяти строки - это внутреннее дело компилятора и нельзя на него закладываться.
Результаты выполнения показывают, что компилятор действует вопреки логике:
Для константной строки памяти выделяется больше чем нужно (ее длину увеличить будет нельзя принципиально )
Для неконстантной строки дополнительной памяти не выделяется (при увеличении ее длины, потребуется новое распределение памяти)
Если пользователь инициализирует строку через StringInitInit, то памяти выделяется больше, чем нужно, потому что размер буфера пользователем задан явно и в подавляющем большинстве случаев он не будет увеличен (пользователь уже сам подумал какой конечный буфер ему нужен и задал его размер явно)
Результаты выполнения показывают, что компилятор действует вопреки логике:
Для константной строки памяти выделяется больше чем нужно (ее длину увеличить будет нельзя принципиально )
Для неконстантной строки дополнительной памяти не выделяется (при увеличении ее длины, потребуется новое распределение памяти)
Если пользователь инициализирует строку через StringInitInit, то памяти выделяется больше, чем нужно, потому что размер буфера пользователем задан явно и в подавляющем большинстве случаев он не будет увеличен (пользователь уже сам подумал какой конечный буфер ему нужен и задал его размер явно)
Размер преаллокации буферов под строки - это внутреннее дело компилятора.
Мы еще неоднократно будем менять работу со строками.
Добавил в тест StringLen, и инициализировал строку по другому. В документации одно, по факту совсем другое поведение.
И буфер в этом случае показывает 0 а не 260.
В документации указано, когда возвращается 0 и он подходит для указанного случая
В документации указано, когда возвращается 0 и он подходит для указанного случая
Документация вообще не соответствует текущему поведению!
А результаты разные ))В чём разница двух видов инициализации?
И вообще не понятно откуда лезет левое число 260.
Документация вообще не соответствует текущему поведению!
Документация: Значение 0 означает, что строка – константная и содержимое буфера менять нельзя.
Строка инициализирована константой "_" и компилятор считает строку условно (для целей эффективности) константной - почему бы и нет? В чем противоречие? Тем более что далее с ней не происходит никаких операций.
И вообще не понятно откуда лезет левое число 260.
Модератор пояснил откуда, а почему оно в случае
не появляется - повод для проверки
Модератор пояснил откуда
С числом 260 вроде понял, компилятор сам выделяет буферу StringBufferLen начальный размер в 260.
И если длина строки меньше 260, то StringBufferLen выводит именно 260, а не реальную длину строки!
А если длина строки больше 260, тогда выводиться реальное значение строки.
То есть пользуясь функцией StringBufferLen, с длиной строки менее 260 символов, мы не получим реальную длину строки, и будем получать всегда 260.
Видимо в этом и есть ошибка.
Как только срока превысит 260 символов, тогда получаем реальное значение длины.
p.s. так как документация устаревшая это жесть как вводит в заблуждение.
То есть пользуясь функцией StringBufferLen, с длиной строки менее 260 символов, мы не получим реальную длину строки, и будем получать всегда 260.
Видимо в этом и есть ошибка.
Как только срока превысит 260 символов, тогда получаем реальное значение длины.
Строго говоря длина строки: StringLen, а длина буфера: StringBufferLen - довольно редкая функция. И в общем случае они могут и не совпадать
Итого два как минимум сомнительных случая:
Результаты выполнения показывают, что компилятор действует вопреки логике:
Результаты выполнения показывают, что компилятор действует вопреки логике:
Размер преаллокации буферов под строки - это внутреннее дело компилятора.
Мы еще неоднократно будем менять работу со строками.