привет!

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

спасибо.

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

X>вопрос в том, есть ли смысл для файлового IO использовать не буферизируемый IO, а буферизацию реализовать на свое уровне для того, чтоб в качестве буфера использовалась не дефолтная память, а память выделенная с использованием указанного аллокатора?

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

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

L>Если твоя библиотека выделяет память внутри себя,
десериализация — да, выделяет при создании объектов в процессе десериализации. тут понятно, что нужно предоставить возможность указывать аллокатор.
но вопрос относится именно к своим файловым потокам. т.е. буферизированный файловый поток, в какой памяти создает буфер по умолчанию? — правильно, сам где-то выделяет память. так вот вопрос в том, что раз уж библиотечка предоставляет возможность указать желаемы аллокатор, то, возможно, имеет смысл и буфер используемый для буферизированного IO брать у аллокатора, а не где-то там где ОС/библиотека его выделяет?

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

X>десериализация — да, выделяет при создании объектов в процессе десериализации. тут понятно, что нужно предоставить возможность указывать аллокатор.
X>но вопрос относится именно к своим файловым потокам. т.е. буферизированный файловый поток, в какой памяти создает буфер по умолчанию? — правильно, сам где-то выделяет память. так вот вопрос в том, что раз уж библиотечка предоставляет возможность указать желаемы аллокатор, то, возможно, имеет смысл и буфер используемый для буферизированного IO брать у аллокатора, а не где-то там где ОС/библиотека его выделяет?

IMO, библиотека просто должна иметь возможность сериализовать в произвольный кусок памяти, который я потом сам смогу скормить функции записи в файл без избыточной буферизации. Может я хочу писать через WriteFile в файл, открытый с флагом FILE_FLAG_WRITE_THROUGH? Хотя в этом случае, наверное, можно в stringstream какой-нибудь сериализовать.

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

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

L>Может я хочу писать через WriteFile в файл, открытый с флагом FILE_FLAG_WRITE_THROUGH?
да не вопрос. реализуй свой IO объект — и будет тебе счастье.

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

X>но вопрос относится именно к своим файловым потокам. т.е. буферизированный файловый поток, в какой памяти создает буфер по умолчанию? — правильно, сам где-то выделяет память. так вот вопрос в том, что раз уж библиотечка предоставляет возможность указать желаемы аллокатор, то, возможно, имеет смысл и буфер используемый для буферизированного IO брать у аллокатора, а не где-то там где ОС/библиотека его выделяет?

Мне кроме как MapViewOfFile (и прочий MMF) ничего в голову не идёт пока.

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

MD>Мне кроме как MapViewOfFile (и прочий MMF) ничего в голову не идёт пока.
а это вообще не понял к чему?

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

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

L>>IMO, библиотека просто должна иметь возможность сериализовать в произвольный кусок памяти,
X>так было раньше.
X>отказался потому, чтоб небыло всякий "промежуточностей", ибо не всегда нужна возможность хранить где-то в памяти, пусть и только в качестве буфера.
X>сейчас же, юзер имеет возможность в своем IO классе, писать данные хоть напрямую в сокет. в общем — больше свободы.
Т.е. чтобы просто сериализовать свой класс в буфер, я должен написать вот такой враппер для массива? Серьезно?

L>>Может я хочу писать через WriteFile в файл, открытый с флагом FILE_FLAG_WRITE_THROUGH?
X>да не вопрос. реализуй свой IO объект — и будет тебе счастье.
И на каждый возможный use case тоже по своему IO объекту писать? Generic programming это не тогда, когда много темплейтов, это когда не нужно писать boilerplate код

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

X>привет!

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

не вижу особого смысла
1) от библиотечки сериализации в первую очередь требуется сама сериализация
2) если используется абстракция стрим, то логично предоставить наиболее часто используемые на практике стримы, чтобы пользователям было проще использовать библиотеку:
а) в сырой буфер
б) в файл
в) в блоб (vector<byte>)
г) на экран
д) в стандартные стримы (std::ostream и производные)


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

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

U>2) если используется абстракция стрим, то логично предоставить наиболее часто используемые на практике стримы, чтобы пользователям было проще использовать библиотеку:
сейчас библиотечка предоставляет file_[i/o]stream и mem_[i/o]stream.
от поддержки std-stream`ов было решено отказаться, в виду их тормознутости в сравнении с.

U>тяжело представляю, где это может случится в сериализации, поэтому и тут аллокаторы скорее всего нет смысла просовывать.
это нужно для десериализации не простых типов, таких как std::string,std::vector,etc...

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

X>от поддержки std-stream`ов было решено отказаться, в виду их тормознутости в сравнении с.
но предоставлю адаптер, конечно.

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

X>сейчас библиотечка предоставляет file_[i/o]stream и mem_[i/o]stream.
я бы рекомендовал убрать все switch из кода mem_ostream (используй memcpy или аналог), иначе есть опасность доступа к невыровненным данным -> UB. плохо скажется на портируемости библиотеки

X>это нужно для десериализации не простых типов, таких как std::string,std::vector,etc...

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

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

X>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Мне кроме как MapViewOfFile (и прочий MMF) ничего в голову не идёт пока.
X>а это вообще не понял к чему?

Про аллоцирование буферов для IO — выделил памяти заранее нужным аллокатором, замапал туда регион файла, поработал, размапал, вернул в пул аллокатора. Или я неверно понял вопрос.

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

U>я бы рекомендовал убрать все switch из кода mem_ostream (используй memcpy или аналог), иначе есть опасность доступа к невыровненным данным -> UB. плохо скажется на портируемости библиотеки
хм.. switch сейчас дает некоторый прирост... позже попробую оценить этот прирост, возможно им можно пренебречь...

U>тут скорее нужна фабрика типов, а не аллокатор
либо я чего-то не понимаю, либо что-то еще...
поясни плиз.