Здравствуйте, niXman, Вы писали:
X>возможен ли сабж(пусть и платформозависимый)? интересует linux/windows.
Возможен, конечно (если поток — это дисковый файл, а не stdout другой программы). Но возможно и написание парсеров, которым не требуется второй раз просматривать уже прочитанное.
получить байт/символ из файла без извлечения из потока
есть некоторый парсер, посимвольно читающий файл. очень часто прочитанный символ нужно вернуть обратно в поток, что сильно сказывается на производительности.
хранение этого байта в своем коде — не сильно помогает, т.к. постоянно приходится проверять этот байт.
возможен ли сабж(пусть и платформозависимый)? интересует linux/windows.
спасибо.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re: получить байт/символ из файла без извлечения из потока
Здравствуйте, niXman, Вы писали:
X>есть некоторый парсер, посимвольно читающий файл. очень часто прочитанный символ нужно вернуть обратно в поток, что сильно сказывается на производительности. X>хранение этого байта в своем коде — не сильно помогает, т.к. постоянно приходится проверять этот байт.
X>возможен ли сабж(пусть и платформозависимый)? интересует linux/windows.
X>спасибо.
std::istream::peek не поможет?
Re: получить байт/символ из файла без извлечения из потока
Здравствуйте, niXman, Вы писали:
X>привет!
X>есть некоторый парсер, посимвольно читающий файл. очень часто прочитанный символ нужно вернуть обратно в поток, что сильно сказывается на производительности. X>хранение этого байта в своем коде — не сильно помогает, т.к. постоянно приходится проверять этот байт.
X>возможен ли сабж(пусть и платформозависимый)? интересует linux/windows.
Хм ты про peek что ли, или?
Re[2]: получить байт/символ из файла без извлечения из потока
Здравствуйте, night beast, Вы писали:
NB>std::istream::peek не поможет?
забыл указать, но нет, по двум причинам: 1)стандартные потоки в проекте не используются(по крайней мере в той его части, с которой работаю я), 2)стандартные потоки жутко тормознутые..
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[3]: получить байт/символ из файла без извлечения из потока
Здравствуйте, niXman, Вы писали:
NB>>std::istream::peek не поможет? X>забыл указать, но нет, по двум причинам: 1)стандартные потоки в проекте не используются(по крайней мере в той его части, с которой работаю я), 2)стандартные потоки жутко тормознутые..
тогда не совсем понятно, какой ответ ты ожидаешь услышать
посмотри на ungetch...
Re[3]: получить байт/символ из файла без извлечения из потока
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, night beast, Вы писали:
NB>>std::istream::peek не поможет? X>забыл указать, но нет, по двум причинам: 1)стандартные потоки в проекте не используются(по крайней мере в той его части, с которой работаю я), 2)стандартные потоки жутко тормознутые..
А какте потоки тогда имеются в виду?
Re[2]: получить байт/символ из файла без извлечения из поток
сейчас я почитал определение стуктуры FILE и сделал хак в виде разыменования мембера _IO_read_ptr. производительность выросла весьма неплохо, но этот способ непереносим, почти никак...
еще вариант — отображать файл в память... но нужно тестить...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, night beast, Вы писали:
NB>тогда не совсем понятно, какой ответ ты ожидаешь услышать
предложение в виде какой-нить хитрой POSIX API или WIN API
NB>посмотри на ungetch...
ща.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[4]: получить байт/символ из файла без извлечения из потока
Здравствуйте, niXman, Вы писали:
X>сейчас я почитал определение стуктуры FILE и сделал хак в виде разыменования мембера _IO_read_ptr. производительность выросла весьма неплохо, но этот способ непереносим, почти никак...
либо банально прочитать файл в память...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[3]: получить байт/символ из файла без извлечения из поток
Здравствуйте, niXman, Вы писали:
X>сейчас я почитал определение стуктуры FILE и сделал хак в виде разыменования мембера _IO_read_ptr. производительность выросла весьма неплохо, но этот способ непереносим, почти никак...
X>еще вариант — отображать файл в память... но нужно тестить...
Про ungetc() тебе уже рассказали.
Отображение в память использует, например, Clang.
The God is real, unless declared integer.
Re[4]: получить байт/символ из файла без извлечения из поток
Здравствуйте, night beast, Вы писали:
NB>посимвольно читать файлы как-то не принято.
Вообще-то весь обычный ввод-вывод — что stdio, что iostreams — именно это и делает на своём уровне во всяких printf и scanf.
С ОС общается порциями, но у ТС речь не об этом.
X>>еще вариант — отображать файл в память... но нужно тестить... NB>имхо лучше.
И там тоже будет работа байтами. Вся разница в том, что подкачка будет происходить невидимо для кодера (и эффективнее, если звёзды сошлись правильно — madvise политика совпадает с нужным для данной задачи).
The God is real, unless declared integer.
Re[5]: получить байт/символ из файла без извлечения из поток
Здравствуйте, netch80, Вы писали:
X>>>еще вариант — отображать файл в память... но нужно тестить... NB>>имхо лучше.
N>И там тоже будет работа байтами. Вся разница в том, что подкачка будет происходить невидимо для кодера (и эффективнее, если звёзды сошлись правильно — madvise политика совпадает с нужным для данной задачи).
ключевой момент выделил.
не должен парсер знать, откуда к нему данные приходят.
не его область ответственности.
Re[6]: получить байт/символ из файла без извлечения из поток
Здравствуйте, night beast, Вы писали:
X>>>>еще вариант — отображать файл в память... но нужно тестить...бесплатных NB>>>имхо лучше.
N>>И там тоже будет работа байтами. Вся разница в том, что подкачка будет происходить невидимо для кодера (и эффективнее, если звёзды сошлись правильно — madvise политика совпадает с нужным для данной задачи).
NB>ключевой момент выделил. NB>не должен парсер знать, откуда к нему данные приходят. NB>не его область ответственности.
Скажите это авторам Clang, который без mmapʼа не сработает.
А в общем случае — да, основной тип лексеров/парсеров, представленных (в бесплатных/OSS решениях) это потоковые. Понятно, откуда это, но имеет свои проблемы. Например, ungetc() гарантируется переносимо только на один символ (но любой; а его аналог для iostreams — только идентичный прочтённому(!)) Соответственно, если не делать своё управление буфером ввода, то и парсер должен быть LL(1), LR(1) или сходно, и лексер перед ним должен быть с просмотром не более чем на 1 символ (облом вспоминать, как это научно называется). Если язык требует большего — начинаются костыли.
The God is real, unless declared integer.
Re[7]: получить байт/символ из файла без извлечения из поток
Здравствуйте, netch80, Вы писали:
N>>>И там тоже будет работа байтами. Вся разница в том, что подкачка будет происходить невидимо для кодера (и эффективнее, если звёзды сошлись правильно — madvise политика совпадает с нужным для данной задачи).
NB>>ключевой момент выделил. NB>>не должен парсер знать, откуда к нему данные приходят. NB>>не его область ответственности.
N>Скажите это авторам Clang, который без mmapʼа не сработает.
ну, я как раз за такой вариант
может не совсем удачно свою мысль выразил.
Re[3]: получить байт/символ из файла без извлечения из поток
Здравствуйте, niXman, Вы писали:
X>сейчас я почитал определение стуктуры FILE и сделал хак в виде разыменования мембера _IO_read_ptr. производительность выросла весьма неплохо, но этот способ непереносим, почти никак...
X>еще вариант — отображать файл в память... но нужно тестить...