Re: Reflection in game engine (c++)

Not a big fan of #5 I have used in few projects or reflection solutions in general which require custom tools/languages in your build system. I have opted for defining reflection in C++ with macros. There are few benefits:
- Can write any reflection logic since the refl. definition is essentially C++ code.
- All types use the same system (e.g. no special treatment of lightweight POD types needed)
- Easy to add reflection to classes as an afterthought without need to convert to a custom language
- Non-intrusive to your build system and no external tools slowing the build process
- Supports proper encapsulation
- Surpports data driven dynamic reflection, i.e. different class instances may expose different set of members based on data
- Easily debuggable
- Cross-platform

Downsides:
- Impacts your compilation time
- Not as neat syntax as custom language
- Need to repeat variable names for reflection

Cheers, Jarkko


On 2013-03-14, at 2:09 PM, Gabriel Sassone <[email protected]> wrote:

> Hello gents,
>    I wanted to experiment with reflection and I found different way to obtain it:
> 
>   1) Invasive macro based registration
>   2) Reflection visitor pattern
>   3) Parsing pdb/clang stuff and create a manual table of what you want/need
>   4) c++ custom parser that uses tags to create reflection informations (like a comment near a member, ...) (exuberant ctags???)
>   5) create serializable/reflected classes in a data format, then run a tool that generates headers and cpps
> 
> I am trying to figure out flaws and merits of each kind, and even if there are other solutions.
> I love the idea to have the possibility to serialize in and out structures, access fields and change values, stream in/out stuff from network ,and maybe link with scripting.
> 
> My goal is to have fast iteration times, both artists and programmers, and I achieved it for rendering programmers already with having json binarized configurable rendering, but still there are code stuff that are not easy to achieve.
> 
> Here are my thoughts, but I would like to hear your ideas and experiences!
> 
> 1) Very precise on what you can register/serialize, but painful to maintain or plug into an existing codebase
> 2) Less precise but you just need one method per class, that you can use to serialize/reflect. Still bad in maintaining, but better in plugging in.
> 3) You make the compiler do the work, then translate the informations you need in your format. Easy to maintain, to plug...maybe slow in parsing? Slow your build pipeline?
> 4) maybe easier than using pdbs, but less powerful (you cannot invoke methods on objects). should be faster than 3.
> 5) crazy idea. requires generation of code from outside...powerful like 4, so data reflection, but you cannot invoke methods if you want.
> 
> What are your experiences/thoughts?
> 
> Thanks to everyone that read this mail!
>  
>     Gabriel
> 
> _______________________________________________
> Sweng-Gamedev mailing list
> [email protected]
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com