Как буфер узнает, сколько символов нужно передать из внешнего файла во время операции очистки?
Скажем, у меня есть операция ввода:
file >> x;
Если внутренний буфер file пустой underflow() будет вызываться для импорта символов с внешнего устройства во внутренний буфер file, Это определяется реализацией, если буфер будет частично или полностью заполнен после этой операции очистки. Принимая это во внимание, возможно ли, что если x является строкой, и я ожидаю, что входное значение определенной длины, что буфер имеет право передавать меньше символов, чем это? Может ли это случиться?
Решение
Нет реального ограничения на количество символов underflow() делает доступным Единственным реальным ограничением является то, что поток, который не достиг EOF, должен сделать доступным хотя бы один символ. С уважением конкретно std::filebuf (или же std::basic_filebuf<...>) поток может быть небуферизованным (если setbuf(0, 0) назывался), в этом случае он действительно делал бы доступными отдельные символы. В противном случае поток будет пытаться заполнить свой внутренний буфер и положиться на операционную систему, чтобы базовая операция вернула подходящее количество байтов, если их еще мало.
Я не уверен, что понимаю ваш вопрос: операция file >> x вернется один раз x полностью прочитано, что может произойти, если поток, указанный как file достиг своего конца или когда найден символ пробела (и если с «строкой» вы имеете в виду char*ненулевое значение хранится в file.width() также учитывается). Что касается основного потока буфера, ясно x может потребоваться многократное чтение базового представления, т. е. непредсказуемое количество обращений к underflow() сделаны. Учитывая, что внутренний буфер файла, вероятно, соответствует размеру блока диска, я ожидаю, что не более одного вызова underflow() сделан для «нормальных» струн. Тем не менее, если чтение файла является огромным и не содержит пробелов, многие обращения к underflow() может быть сделано. Учитывая, что потоку необходимо найти пробелы, он не может предсказать, сколько символов необходимо в первую очередь.
Другие решения
Других решений пока нет …