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

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

S>>>На пример как?
__>>Для этого нужно целиком задачу понимать. Сформулируй ее как нить более цельно

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

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

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

S>>>На пример как?
__>>Для этого нужно целиком задачу понимать. Сформулируй ее как нить более цельно

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

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