Superklug, понятно, что если разбирать буфер ручками, то конец найти можно. Но это лишает тебя возможности использовать стандартные потоки. Можно написать свой вариант потока, который будет отслеживать конец, конечно. Но поток тогда будет сильно проприетарный - только для одного формата. Неудобно, короче. Дополнительный параметр - размер буфера  очень сильно облегчит дело. Так что я бы переписала (добавив, как уже предлагалось, в начало размер) или как-то по-другому передав размер. В strstream
тогда это запихивается элементарно: кажется там есть конструктор с адресом и размером.
При записи я бы тоже использовала strstream, ибо доставать c_str из string некузяво: а вдруг там 0 где-нибудь? Понятно, что и размер добыть можно, но лучше уж буфер.

Наверняка подобное уже писали. Что-то типа memory stream как наследник от стандартного потока stl.
Может в boost::iostreams есть?

Ну сам подумай: откуда, не зная размера буфера, этот гипотетический поток узнает где конец? У клиента спрашивать будет?
Можешь, конечно, порыться в strstream и посмотреть как он конец отслеживает, может там что-то можно кастомизировать. Но ей-богу, неправильно это. По соотношению "сложность реализации"\"полезность" вариант с добычей размера несомненно зашкаливает в положительном смысле. 

Superklug

Я не про это, я ищу возможность посчитать полный размер блока без итерации, не пойму в чем проблема хранить полный размер? Зачем искусственно создавать себе проблемы?

Добавлено через 53 секунды

и по твоему это легче, чем просто добавить размер в начало буфера?

Доверюсь вашему авторитетному мнению...
Копаться в stl гиблое дело) Я даже пробовать боюсь...

Спасибо вам за терпение!  

Добавлено через 1 минуту и 46 секунд

Конечно не легче.. Просто интерфейсы DLL функций и бинарный формат были обговорены. Не хотел менять. Сейчас пойду убеждать в необходимости параметра size)

Так формат не меняется, просто работать с данными надо начинать со смещения +2 и все, формат тот же, там одна арифметическая операция с указателем добавляется, думаю это просто. В любом случае, архитектура должна подстраиваться под нужды задачи а не наоборот.

Это сообщение отредактировал(а) azesmcar - 18.6.2010, 12:56

azesmcar, думаю, будет логичней в функции передавать не void*, а const Buffer *. где Buffer это структура типа { size_t size; void *data; }. По сути, это твой же вариант, только более красивый. 

ну автор не хотел менять интерфейс DLL, а вообще да, согласен  

Только не 2, а как минимум 4. Икнуть не успеешь, как 64 К перестанет хватать...

 Насчет структуры... не знаю... плотный поток данных иногда бывает более предпочтительным. Тем более, что никто не мешает написать:
struct CBufffer
{
   size_t m_Size;
   BYTE  mBuf[1];
};
если уж с указателями возиться влом.

Ну да, я писал об этом в самом начале, это уже в зависимости от задачи  

В итоге написал функции для сериализации/десериализации непосредственно для void*.
В случае ошибки всплывает исключение memory access.

Вроде все нормально работает...