Я обычно не ныряю так глубоко в техническую часть и использую более простое решение. Меня как человека, открывшего статью из любопытства, немного сбило с толку отличие названия и содержания.
Возможно в статье, на которую Вы ссылаетесь, есть много полезных и стоящих идей, но эту статью пишете Вы. Техника с применением шаблонов (Variadic Templates) имеет законное место быть — не зря же ее добавили в стандарт. И поэтому ваша статья была похоже больше на очередной пример использования, нежели на решение проблемы сериализатора. Поскольку тут нет жюри и присяжных, не принимайте близко к сердцу.
Я бы назвал эту технику как способ выхода из сложной ситуации. Создатели решили просто обойти ограничения c++ еще одним способом. Для пообного в других языкаъ давно существуют динамические типы и различные функции-делегаты (еще замыкания — Closures как JavaScript или Groovy).
И как я писал выше, старое доброе ООП решение тут бы подошло. Реализовать единый интерфейс и наследовать его теми классами которые сериализуются. И точно указывая какие поля сериализовать. А так получается, что сериализуемые объекты нужно выделять в отдельный класс т.к сериализатор берет объект целиком. В 99% случаев у ваших классов будут поля которые не нужно передавать при сериализации (в данном случае по сети), для той же безопасности или экономии трафика.
Я лично под сериализатором понимаю некий класс превращающий объекты в поток байт и обратно. Но если говорить про игру, любой читающий хотел бы увидеть нюансы конкретно для игр. Вот их в статье и не было.
В начале статьи стояла задача безопасности: «не доверяй данным присланным клиентом» — а хеширование куда пропало? Каким образом написание вроде-как-быстрого кода через использование Variadic Templates делает сообщение безопасным?
— Изначально, правильно писать игру так, чтобы клиент просто выводил данные и передавал команды игрока не имея возможности влиять на саму игру (кроме как на своем экране, если удастся изменить память игры или входящий трафик)
— Трафик должно быть непросто видоизменить (именно на это будут смотреть те кто будет давать вашей игре статус «безопасной») поэтому любой простейший метод шифрования необходим — для той же уверенности в достоверности сообщений. Ну и почему бы не сжать данные? это сэкономит трафик. (сжимают обычно до шифрования т.к сжатие зашифрованного файла ничего не сэкономит)
Вот эти детали ожидает человек, который видит название «сериализатор для сетевой игры». И не пишите пожалуйста — «если вам надо, то напишите» (из вашего ответа), мы говорили про статью, а не про то что мне надо:) Помоему, без возможности сериализовать вложенные объекты — вообще речи о решении задачи сериализации идти не может.
Всего хорошего и удачи в написании самых читаемых статей
Я с большим уважением отношусь к таким статьям, однако проблемы заявленные во вступлении не решены, кроме как использования возможностей обновленного стандарта.
Ну и имитация конца света с отключенными поисковыми системами и доступа к готовым библиотекам. (при отключенном интернете нам бы пришлось изобрести новый способ связи)
1) Например, причем тут безопасность? — Кроме использования шифрования в связке со сжатием (независимо от языка) далеко не уедешь.
В коде нет ничего об этом.
2) То что делает ваш сериализатор похоже на вывод CSV без запятых. А как быть с древовидными структурами?
Например в .net (да других платформах тоже) есть сериализатор работающий отлично от xml/json и т.п, все что нужно, так это добавить атрибут Serializable у своего класса (в java подобное делается через интрфейс). И никакого дублированного кода при высокой производительности. Причем сериализатор сразу позволяющий модифицировать удаленный объект (устанавливает удаленное подключение на заданный адрес при необходимости) ну или запишет в файл.
Даже если опустить прелюдию с готовыми решениями есть готовые паттерны (это про дублирующийся код) Например в книге GOF чтение дерева описывают в паттерне Visitor. И даже обыденное использование интерфейсов (абстрактных классов в c++ без реализации методов) лишит необходимости переопределять метод сериализации + полный контроль над тем что именно сериализуется для конкретного класса.
Вы не обязаны отвечать мне, просто такие вот мысли возникли. Возможно проблема в использовании слишком простого примера или я не рассмотрел возможность сериализации структур. Хотя тогда бы были какие-то упоминания про разделитель вложения уровней..(а упоминался только пробел)
Большое спасибо за статью, однако она должна как минимум иметь название по-скромнее. «Необычная Сериализация в C++11». И не нужно говорить в начале что все на свете проблемы тут порешаны на 20 строках кода:)
Я обычно не ныряю так глубоко в техническую часть и использую более простое решение. Меня как человека, открывшего статью из любопытства, немного сбило с толку отличие названия и содержания.
Возможно в статье, на которую Вы ссылаетесь, есть много полезных и стоящих идей, но эту статью пишете Вы. Техника с применением шаблонов (Variadic Templates) имеет законное место быть — не зря же ее добавили в стандарт. И поэтому ваша статья была похоже больше на очередной пример использования, нежели на решение проблемы сериализатора. Поскольку тут нет жюри и присяжных, не принимайте близко к сердцу.
Я бы назвал эту технику как способ выхода из сложной ситуации. Создатели решили просто обойти ограничения c++ еще одним способом. Для пообного в других языкаъ давно существуют динамические типы и различные функции-делегаты (еще замыкания — Closures как JavaScript или Groovy).
И как я писал выше, старое доброе ООП решение тут бы подошло. Реализовать единый интерфейс и наследовать его теми классами которые сериализуются. И точно указывая какие поля сериализовать. А так получается, что сериализуемые объекты нужно выделять в отдельный класс т.к сериализатор берет объект целиком. В 99% случаев у ваших классов будут поля которые не нужно передавать при сериализации (в данном случае по сети), для той же безопасности или экономии трафика.
Я лично под сериализатором понимаю некий класс превращающий объекты в поток байт и обратно. Но если говорить про игру, любой читающий хотел бы увидеть нюансы конкретно для игр. Вот их в статье и не было.
В начале статьи стояла задача безопасности: «не доверяй данным присланным клиентом» — а хеширование куда пропало? Каким образом написание вроде-как-быстрого кода через использование Variadic Templates делает сообщение безопасным?
— Изначально, правильно писать игру так, чтобы клиент просто выводил данные и передавал команды игрока не имея возможности влиять на саму игру (кроме как на своем экране, если удастся изменить память игры или входящий трафик)
— Трафик должно быть непросто видоизменить (именно на это будут смотреть те кто будет давать вашей игре статус «безопасной») поэтому любой простейший метод шифрования необходим — для той же уверенности в достоверности сообщений. Ну и почему бы не сжать данные? это сэкономит трафик. (сжимают обычно до шифрования т.к сжатие зашифрованного файла ничего не сэкономит)
Вот эти детали ожидает человек, который видит название «сериализатор для сетевой игры». И не пишите пожалуйста — «если вам надо, то напишите» (из вашего ответа), мы говорили про статью, а не про то что мне надо:) Помоему, без возможности сериализовать вложенные объекты — вообще речи о решении задачи сериализации идти не может.
Всего хорошего и удачи в написании самых читаемых статей
Ну и имитация конца света с отключенными поисковыми системами и доступа к готовым библиотекам. (при отключенном интернете нам бы пришлось изобрести новый способ связи)
1) Например, причем тут безопасность? — Кроме использования шифрования в связке со сжатием (независимо от языка) далеко не уедешь.
В коде нет ничего об этом.
2) То что делает ваш сериализатор похоже на вывод CSV без запятых. А как быть с древовидными структурами?
Например в .net (да других платформах тоже) есть сериализатор работающий отлично от xml/json и т.п, все что нужно, так это добавить атрибут Serializable у своего класса (в java подобное делается через интрфейс). И никакого дублированного кода при высокой производительности. Причем сериализатор сразу позволяющий модифицировать удаленный объект (устанавливает удаленное подключение на заданный адрес при необходимости) ну или запишет в файл.
Даже если опустить прелюдию с готовыми решениями есть готовые паттерны (это про дублирующийся код) Например в книге GOF чтение дерева описывают в паттерне Visitor. И даже обыденное использование интерфейсов (абстрактных классов в c++ без реализации методов) лишит необходимости переопределять метод сериализации + полный контроль над тем что именно сериализуется для конкретного класса.
Вы не обязаны отвечать мне, просто такие вот мысли возникли. Возможно проблема в использовании слишком простого примера или я не рассмотрел возможность сериализации структур. Хотя тогда бы были какие-то упоминания про разделитель вложения уровней..(а упоминался только пробел)
Большое спасибо за статью, однако она должна как минимум иметь название по-скромнее. «Необычная Сериализация в C++11». И не нужно говорить в начале что все на свете проблемы тут порешаны на 20 строках кода:)