Polymorphism support

[loki-astari]

Polymorphism support

[Loki-Astari]

Sorry.
That is an over-site in the documentation. I will take a look and add some examples.

To declare a derived class you use ThorsAnvil_ExpandTrait rather than ThorsAnvil_MakeTrait

Expanding on the Bigger Example

class MyDerived: public MyClass
{
     int data4 = 9;
     friend struct ThorsAnvil::Serialize::Traits<MyDerived>;

     public:
         using MyClass::MyClass;
};

ThorsAnvil_ExpandTrait(MyClass, MyDerived, data4);

If I serialized an object of MyDerived It would look like this:

      MyDerived      item(12, 23.8, "Look");
      std::cout << jsonExport(item);

Should result in:

    {
         "data1":  12,
         "data2": 23.8,
         "data3": "Look",
         "data4": 9
    }

I will have some time to write this up and compile (and thus test) this weekend.

[123tris]

I'm developing a game engine with a friend in C++ and as I'm working on the editor I need to be able to flexibly serialize all kinds of classes and preferably in the most automatic and least intrusive way as possible to save time and enforce OOP (a class that manages serialization should manage all the serialization itself thus serialization code should not be found in classes that need to be serialized, obviously that's quite difficult in C++ without reflection or introspection).

So for example we would have a scene that contains a map of pointer gameobjects which contains a vector of pointer components and those components could be any possible class that has derived from it. Would you think your library would be a good fit for something that flexible?

[Loki-Astari]

You use pointers excessively (I understanding for the polymorphic Component) but do you need it for the GameObject? You should check out https://codereview.stackexchange.com and see if a code review would help.

To Answer your question:

Not Directly. (Missing a polymorphic feature).
Just two minor tweaks.

So for pointers these don't work without a helper function. You need to write a function to convert them to references. Another un-document feature (I will have to look up how I did that). Its been a while since I used it but I am sure it is there.

Also it does not handle polymorphic types out of the box. But I think I can add a feature to deal with that. I'll look into it this weekend if I get a chance.

[123tris]

We need GameObject to be a pointer because when referencing GameObject we don't want to create a copy of it all the time but want to change it directly. Also there is a large amount of data saved into GameObject when running the game which should be stored on the heap and not on the stack.

Thank you for your responses, I look forward to hearing from your updates of the library when you find the time!

[Loki-Astari]

We need GameObject to be a pointer because when referencing GameObject we don't want to create a copy of it all the time but want to change it directly.

That does not preclude it being an object of a vector.

 std::vector<GameObject>    objects;

// STUFF
objects[1].doStuff();   // Does not create a copy.
                                     // Operator [] returns a reference.

Also storing pointers is very error prone.
Basically in modern C++ you never use pointers (you should be using unique_ptr<>). I would encourage you to get a code review of your design at https://codereview.stackexchange.com

Also with the addition of move semantics in C++11 must objects are moved (not copied). This should be relatively cheap operations.

Also there is a large amount of data saved into GameObject when running the game which should be stored on the heap and not on the stack.

Referring to the stack and heap is an incorrect way of looking at C++ (unlike Java, C++ does not have a concept of heap and stack (yes they are used underneath but they are not part of the language construct)) and trying to think about heap and stack will lead you to do things inefficiently.

PS. You should be thinking in terms of Automatic/Static/Thread/Dynamic storage duration objects. These are how you think of memory in C++ (not heap/stack). And you should never be interacting directly with dynamically allocated objects they should be controlled via automatic objects (i.e. smart pointers or containers).

[123tris]

GameObject is barely ever referenced directly through the scene unless it is scene management so it won't be called through the list variable that it is stored in. It is mainly referenced through Component which looks like this: https://puu.sh/xEDvo/f145e4c4bb.png and components reference the GameObject that they're attached to. This is the GameObject class: https://puu.sh/xEEb6/60031484d2.png

We are already using smart pointers to store them, I simply didn't write smart pointer as I wanted to write it shortly as I believed specifying it to be of little significance (I'm aware that serialization of objects should be done through smart pointers). The reason for GameObject and Component to be std::shared_ptrs is because we want multiple pointers to the same resource.

P.S. I made screenshots of the code as it seemed to be too long to put it inside of the comment

[Loki-Astari]

This is now supported.
See: https://github.com/Loki-Astari/ThorsSerializer/blob/master/doc/example3.md