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


S>В компил-тайме не получится, т.к. тип пакета узнаю на основе поступающих данных.

Ну, если подсунуть компайл-тайм пакет, то вроде всё в компайле и отработает. Рантайм пакет конечно какая-то часть будет в рантайме работать

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

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

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

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

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

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

M>Ну, если подсунуть компайл-тайм пакет, то вроде всё в компайле и отработает. Рантайм пакет конечно какая-то часть будет в рантайме работать

Все в рантайме, конечно.

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

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

__>Установка данных частями это уже антипаттерн, так как можем легко поломать их консистентность. Он должен быть разбит на атомарные независимые вещи

Всегда все устанавливают данные пакета частями одну часть за другой

А какие альтернативы?

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

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

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

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

__>>Установка данных частями это уже антипаттерн, так как можем легко поломать их консистентность. Он должен быть разбит на атомарные независимые вещи

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

S>Единый буффер — может и не плохо, но если многопоточная среда — то усложняет значительно. Нужно по количеству потоков выделять n буфферов этих, ожидание, очередь. Возможно добавлю, если будет время, но для начала чтобы хотя бы лишние копии на пустом месте не создавались.
один из решений это возвращать что-то в духе buffer_view по аналогии с string_view, то есть невладеющий указатель

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

S>Компил-тайм этот редко где вообще нужен — в основном идет как ребус или хорохориться друг перед другом на форумах. В серьезных проектах он не используется или используется по минимуму — совсем простые вещи.

По-моему, ты злоупотребляешь обобщениями.

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

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

Если ты не террабиты собрался прокачивать, то существующие в плюсах оптимизации вполне себе справятся, а ты занимаешься херней

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

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

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

Не надо так делать: поменяется версия и всё по новой переписывать придётся.
Данные отдельно, отсылка данных отдельно.
Цепочка примерно такая: прикладные данные -> спец struct данных для сообщения -> серилизация в буфер (в зависимости от версии) -> отсылка буфера (и только если данные по настоящему большие (что для бинарных протоколов не характерно, то серилизация прямо в поток вывода).
В любом случае под каждое сообщение должна быть структура данных, иначе это write only код, замучаетесь поддерживать.

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

__>>Установка данных частями это уже антипаттерн, так как можем легко поломать их консистентность. Он должен быть разбит на атомарные независимые вещи
S>Всегда все устанавливают данные пакета частями одну часть за другой

У вас чтение или запись?

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

А можно рассказать какую всё таки задачу должен решать этот класс ?

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

_NN>А можно рассказать какую всё таки задачу должен решать этот класс ?

Уже писал выше — быть удобным способом работать с бинарным сетевым пакетом — позволять легким способом устанавливать/получать те или иные части пакета.

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

_NN>>А можно рассказать какую всё таки задачу должен решать этот класс ?

S>Уже писал выше — быть удобным способом работать с бинарным сетевым пакетом — позволять легким способом устанавливать/получать те или иные части пакета.

Не решает. Не удобно. Не легким способом.

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

S>>Уже писал выше — быть удобным способом работать с бинарным сетевым пакетом — позволять легким способом устанавливать/получать те или иные части пакета.
M>Не решает. Не удобно. Не легким способом.

А что вам удобно? Чем плохо обернуть массив байт пакета и получать/устанавливать те или иные части в удобном виде просто как вызов функции get|set?

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

S>А что вам удобно? Чем плохо обернуть массив байт пакета и получать/устанавливать те или иные части в удобном виде просто как вызов функции get|set?

Тепреть не могу аналогий, но в данном случае будет уместно, всё-таки.

Какую задачу решает, например, электрическая лампочка? Она обеспечивает освещение. А какую задачу решает мракобес, который сверлит в электрической лампочке отверстие, через которое удобно заливать керосин? Да никакую. Он просто не понимает принцип действия электрической лампочки, вот и всё.

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

S>>А что вам удобно? Чем плохо обернуть массив байт пакета и получать/устанавливать те или иные части в удобном виде просто как вызов функции get|set?
R>Тепреть не могу аналогий, но в данном случае будет уместно, всё-таки.

Зачем аналогии — можно же сразу конкретику — код:

MyPacket packet;

packet.setType(1);                        // Тип пакета = 1
packet.setNonce(0xABCDEF01);              // Nonce
packet.setTimestamp(std::time(nullptr));  // Временная метка

— что не так и какие альтернативы?

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

S>

S>MyPacket packet;

S>packet.setType(1);                        // Тип пакета = 1
S>packet.setNonce(0xABCDEF01);              // Nonce
S>packet.setTimestamp(std::time(nullptr));  // Временная метка
S>

S>- что не так и какие альтернативы?

Во-первых, говнокод. На кой хер у тебя в классе пакета такое количество модифицирующих аксессоров. Тебе действительно нужно многократно менять свойсва объекта пакета? Нафига? Сисшарп головного мозга какой-то.

Во-вторых, это ты скажи, что не так. И нафига тебе заливать керосин в электрическую лампочку.

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

S>Зачем аналогии — можно же сразу конкретику — код:

Ты, походу, снова нифига не понял.

Тебе вопрос задали

Автор: _NN_
Дата: 23.03 23:12

: какую задачу ты решаешь. На этот вопрос ты так и не ответил. Превращение C++ в C# — это не задача — это заливание керосина в электрическую лампочку.

Теперь дошла аналогия?

P.S. Задача могла бы звучать, например, так: "помогите спроектировать класс пакета, а то у меня какая-то фигня получается".

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

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

S>>

S>>MyPacket packet;

S>>packet.setType(1);                        // Тип пакета = 1
S>>packet.setNonce(0xABCDEF01);              // Nonce
S>>packet.setTimestamp(std::time(nullptr));  // Временная метка
S>>

S>>- что не так и какие альтернативы?

R>Во-первых, говнокод. На кой хер у тебя в классе пакета такое количество модифицирующих аксессоров. Тебе действительно нужно многократно менять свойсва объекта пакета? Нафига? Сисшарп головного мозга какой-то.

Ну это ж для примера. На самом деле из сеттеров setAuthCode в одном пакете типа uint64_t. Не устанавливаю сразу, т.к. удобнее внутри класса сформировать нужные поля для аутентификации.

Но геттеров больше, т.к. пакет работает в обе стороны — и формируем и парсим. И все в одном месте как бы.

R>Во-вторых, это ты скажи, что не так. И нафига тебе заливать керосин в электрическую лампочку.

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

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

R>Тебе вопрос задали

Автор: _NN_
Дата: 23.03 23:12

: какую задачу ты решаешь. На этот вопрос ты так и не ответил. Превращение C++ в C# — это не задача — это заливание керосина в электрическую лампочку.

Я ж писал — бинарный пакет с удобным доступом к частям пакета. В обе стороны — и формируем и парсим.

R>P.S. Задача могла бы звучать, например, так: "помогите спроектировать класс пакета, а то у меня какая-то фигня получается".

А как я могу понять что фигня, если оно работает?

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

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

S>Ну это ж для примера. На самом деле из сеттеров setAuthCode в одном пакете типа uint64_t. Не устанавливаю сразу, т.к. удобнее внутри класса сформировать нужные поля для аутентификации.

Я понял, что это для примера. Вопрос только, для какого примера. Какую задачу ты решаешь? Да никакую — так получается. Борешься с неприятным С++, чтобы сделать его приятным, как С#.