Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Код, который читает данные из базы, длину не вычисляет.
Еще как вычисляет. Неудачный пример.
PD> Нет такого в SQL SELECT, к примеру. Внутри себя этот SELECT на сервере я не знаю что делает, но мне на клиент в итоге строка попадает как последовательность ASCIIZ.
Неправда. Строка попадает в довольно сложном виде. Никаким ASCIIZ там и не пахнет — приезжает и длина, и признак null, а то еще и кодировка.
PD>Последовательность ASCIIZ — "сырые" данные, откуда они взялись — не важно.
Нет уж позвольте. Мне вот очень интересно — откуда взялись эти сырые данные, и почему у них отобрали длину.
PD>А в объекте string на входе конструктора эти же сырые данные (а как ты еще string сконструируешь, если не по ASCIIZ или по другому string ?)
Как это? Миллион способов сконструировать строку есть.
PD>, а вот в полученном объекте — уже с длиной. Т.е. длину при создании экземпляра string вычислили.
Все верно.
PD>Да ведь во входном мире ничего другого нет. Есть некий входной массив байт (из файла, из сети, ...).
Неправда. Это какой-то не тот мир, который я знаю. Файлы уже лет тридцать как снабжаются длиной. Совершенно незачем выполнять последовательное сканирование для ее определения. Я понимаю, что трудно заставить в это поверить человека, привыкшего работать с магнитной лентой, но это так
PD>Этот набор нам дают и все. И чем-то заканчивают, чтобы знали, когда остановиться.
В 21 веке пора привыкать к тому, что строка в 99.9999% обладает длиной. И потерять эту длину можно только отрезав ее в одном месте. Чтобы тут же начать вычислять ее в другом.
PD>gets банальный, например. А дальше уж наше дело — то ли string из него соорудить, длину мимоходом посчитав и время потратив, то ли не считать длину, отложить до того момента, когда понадобится (может, и не понадобится) . Кстати, в моем примере с конкатенацией я эту длину мог мимоходом вычислить.

>>Читал историю про маляра Шлемиэля?
PD>Нет.
Очень, очень напрасно. Вот здесь.