@winser Если вы хотите готовую материализацию типа такого: superNetwork.send(MySuperCLass& myClass), то такого нет, вам всеравно прийдеться писать руками сериализацию членов класса или использовать внешню кодогенерацию, как например google protobuf. Класс для сериализации я вам предложил boost::ptree, пишите все в него, потом сохраняете в стрим, берете оттуда строку, ее как кусок памяти отправляете, на клиенте все наоборот делается.
@winser если делать в лоб, к сожалению прийдется писать руками код типа такого mVal1 = controllerSettings.get("Val1");
mVal2 = controllerSettings.get("Val2");
mVal3 = controllerSettings.get("Val3");
Что планируется вам делать с этими типами, если создавать, то больше подойдет патерн - абстрактная фабрика, и в место типов можно получать делегаты создающие обьекты этих типов.
Вы немного не верено меня поняли, либо я не не очень понятно и выразился, я насчет вектора имел ввиду, что как раз глупо выделять из него интерфейс и так далее. Далее насчет тестирования меша и порядка вызова тестов:
1. В любом случае вы увидите все упавшие тесты.
2. Вектор такой же базовый тип данных как и число, вы же не опасаетесь, что складывая 2 числа их сложение может поломаться а из за этого поломается у вас меш?
Если сильно смущает, то выделяйте тогда уж тесты в 2 группы:
1) базовая (все мат функции и тд.)
2) все остальное, тестирование сложных классов.
У нас очень похожий подход, проект разбит на несколько библиотек, которые можно тестировать отдельно. Например библиотека Core - в ней сидит класс вектор. Библиотека Render, в ней класс Mesh.
3. Я все же считаю, что ничего страшного не происходит - цель тестов упасть, если что то не так, отказавшись от юниттестов на вектор или на меш вы сделаете только хуже.
Ну главная причина - на билдсервере формат отчета гуглотестов поддерживался, сходу вышло запилить :) А так все как у всех - есть солюшн, внем куча проектов либ, и несколько проектов екзешников с минимальным функционалом, юниттесты пишутся для классов из либ. Один из экзешников - запускает юниттесты.
Лучший вариант не использовать параметров в конструкторе а иметь функцию init которая принимает все необходимые параметры. Если все таки очень хочется, то вопервых необходимо параметр static T instance; вынести из функции в класс:
static T* instance; (или static unique_ptr instance)
тогда можно будет управлять жизнью объекта (но обьект не будет создан автоматом при вызове GetInstance ) и реализовать функцию Create с нужными параметрами, которая и будет создавать класс.
Если важно то не сделает, кучу раз приходилось в играх под иксбокс делать такие оптимизации с условными переходами. В данный момент занимаюсь написанием физики, и такие оптимизации реально помогают.
