привет!

есть некоторый парсер, посимвольно читающий файл. очень часто прочитанный символ нужно вернуть обратно в поток, что сильно сказывается на производительности.
хранение этого байта в своем коде — не сильно помогает, т.к. постоянно приходится проверять этот байт.

возможен ли сабж(пусть и платформозависимый)? интересует linux/windows.

спасибо.

Здравствуйте, niXman, Вы писали:

X>есть некоторый парсер, посимвольно читающий файл. очень часто прочитанный символ нужно вернуть обратно в поток, что сильно сказывается на производительности.
X>хранение этого байта в своем коде — не сильно помогает, т.к. постоянно приходится проверять этот байт.

X>возможен ли сабж(пусть и платформозависимый)? интересует linux/windows.

X>спасибо.

std::istream::peek не поможет?

Здравствуйте, niXman, Вы писали:

X>привет!

X>есть некоторый парсер, посимвольно читающий файл. очень часто прочитанный символ нужно вернуть обратно в поток, что сильно сказывается на производительности.
X>хранение этого байта в своем коде — не сильно помогает, т.к. постоянно приходится проверять этот байт.

X>возможен ли сабж(пусть и платформозависимый)? интересует linux/windows.

Хм ты про peek что ли, или?

Здравствуйте, night beast, Вы писали:

NB>std::istream::peek не поможет?
забыл указать, но нет, по двум причинам: 1)стандартные потоки в проекте не используются(по крайней мере в той его части, с которой работаю я), 2)стандартные потоки жутко тормознутые..

Здравствуйте, niXman, Вы писали:

NB>>std::istream::peek не поможет?
X>забыл указать, но нет, по двум причинам: 1)стандартные потоки в проекте не используются(по крайней мере в той его части, с которой работаю я), 2)стандартные потоки жутко тормознутые..

тогда не совсем понятно, какой ответ ты ожидаешь услышать
посмотри на ungetch...

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, night beast, Вы писали:

NB>>std::istream::peek не поможет?
X>забыл указать, но нет, по двум причинам: 1)стандартные потоки в проекте не используются(по крайней мере в той его части, с которой работаю я), 2)стандартные потоки жутко тормознутые..

А какте потоки тогда имеются в виду?

сейчас я почитал определение стуктуры FILE и сделал хак в виде разыменования мембера _IO_read_ptr. производительность выросла весьма неплохо, но этот способ непереносим, почти никак...

еще вариант — отображать файл в память... но нужно тестить...

Здравствуйте, night beast, Вы писали:

NB>тогда не совсем понятно, какой ответ ты ожидаешь услышать
предложение в виде какой-нить хитрой POSIX API или WIN API

NB>посмотри на ungetch...
ща.

Здравствуйте, bnk, Вы писали:

bnk>А какте потоки тогда имеются в виду?
сорри, тоже забыл указать: stdio

вообще, это не столь важно, потому как я имею возможность реализовать IO по своему усмотрению, лишь бы производительность была хорошая...

Здравствуйте, niXman, Вы писали:

NB>>посмотри на ungetch...
X>ща.

поправка, ungetc

Здравствуйте, niXman, Вы писали:

посимвольно читать файлы как-то не принято.

X>еще вариант — отображать файл в память... но нужно тестить...

имхо лучше.

Здравствуйте, niXman, Вы писали:

X>сейчас я почитал определение стуктуры FILE и сделал хак в виде разыменования мембера _IO_read_ptr. производительность выросла весьма неплохо, но этот способ непереносим, почти никак...

либо банально прочитать файл в память...

Здравствуйте, niXman, Вы писали:

X>возможен ли сабж(пусть и платформозависимый)? интересует linux/windows.

Возможен, конечно (если поток — это дисковый файл, а не stdout другой программы). Но возможно и написание парсеров, которым не требуется второй раз просматривать уже прочитанное.

Здравствуйте, niXman, Вы писали:

X>сейчас я почитал определение стуктуры FILE и сделал хак в виде разыменования мембера _IO_read_ptr. производительность выросла весьма неплохо, но этот способ непереносим, почти никак...

X>еще вариант — отображать файл в память... но нужно тестить...

Про ungetc() тебе уже рассказали.
Отображение в память использует, например, Clang.

Здравствуйте, night beast, Вы писали:

NB>посимвольно читать файлы как-то не принято.

Вообще-то весь обычный ввод-вывод — что stdio, что iostreams — именно это и делает на своём уровне во всяких printf и scanf.
С ОС общается порциями, но у ТС речь не об этом.

X>>еще вариант — отображать файл в память... но нужно тестить...
NB>имхо лучше.

И там тоже будет работа байтами. Вся разница в том, что подкачка будет происходить невидимо для кодера (и эффективнее, если звёзды сошлись правильно — madvise политика совпадает с нужным для данной задачи).

Здравствуйте, netch80, Вы писали:

X>>>еще вариант — отображать файл в память... но нужно тестить...
NB>>имхо лучше.

N>И там тоже будет работа байтами. Вся разница в том, что подкачка будет происходить невидимо для кодера (и эффективнее, если звёзды сошлись правильно — madvise политика совпадает с нужным для данной задачи).

ключевой момент выделил.
не должен парсер знать, откуда к нему данные приходят.
не его область ответственности.

Здравствуйте, night beast, Вы писали:

X>>>>еще вариант — отображать файл в память... но нужно тестить...бесплатных
NB>>>имхо лучше.

N>>И там тоже будет работа байтами. Вся разница в том, что подкачка будет происходить невидимо для кодера (и эффективнее, если звёзды сошлись правильно — madvise политика совпадает с нужным для данной задачи).

NB>ключевой момент выделил.
NB>не должен парсер знать, откуда к нему данные приходят.
NB>не его область ответственности.

Скажите это авторам Clang, который без mmapʼа не сработает.

А в общем случае — да, основной тип лексеров/парсеров, представленных (в бесплатных/OSS решениях) это потоковые. Понятно, откуда это, но имеет свои проблемы. Например, ungetc() гарантируется переносимо только на один символ (но любой; а его аналог для iostreams — только идентичный прочтённому(!)) Соответственно, если не делать своё управление буфером ввода, то и парсер должен быть LL(1), LR(1) или сходно, и лексер перед ним должен быть с просмотром не более чем на 1 символ (облом вспоминать, как это научно называется). Если язык требует большего — начинаются костыли.

Здравствуйте, netch80, Вы писали:

N>>>И там тоже будет работа байтами. Вся разница в том, что подкачка будет происходить невидимо для кодера (и эффективнее, если звёзды сошлись правильно — madvise политика совпадает с нужным для данной задачи).

NB>>ключевой момент выделил.
NB>>не должен парсер знать, откуда к нему данные приходят.
NB>>не его область ответственности.

N>Скажите это авторам Clang, который без mmapʼа не сработает.

ну, я как раз за такой вариант
может не совсем удачно свою мысль выразил.

Здравствуйте, niXman, Вы писали:

X>сейчас я почитал определение стуктуры FILE и сделал хак в виде разыменования мембера _IO_read_ptr. производительность выросла весьма неплохо, но этот способ непереносим, почти никак...

X>еще вариант — отображать файл в память... но нужно тестить...

int fseek ( FILE * stream, long int offset, int origin );

Здравствуйте, niXman, Вы писали:

X>хранение этого байта в своем коде — не сильно помогает, т.к. постоянно приходится проверять этот байт.

Файл может меняться в тот момент, когда идёт работа с ним?

X>возможен ли сабж(пусть и платформозависимый)? интересует linux/windows.

Для парсера — не в ту сторону смотришь. Какой тип грамматики парсишь и какой метод разбора применяешь?