Comments on: Reflection in C++ – part 2 http://msinilo.pl/blog/?p=521 Random gamedev ramblings Sun, 05 Sep 2010 06:59:46 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: admin http://msinilo.pl/blog/?p=521&cpage=1#comment-18211 admin Mon, 30 Nov 2009 09:16:44 +0000 http://msinilo.pl/blog/?p=521#comment-18211 Arseny - good points, thanks for sharing. About b) - surely you need to store number of elements as well? In such case there's no reason not to encapsulate it in some kind of object (ptr+size pair) and have custom save handler (like in vector example here). Arseny – good points, thanks for sharing. About b) – surely you need to store number of elements as well? In such case there’s no reason not to encapsulate it in some kind of object (ptr+size pair) and have custom save handler (like in vector example here).

]]> By: Arseny Kapoulkine http://msinilo.pl/blog/?p=521&cpage=1#comment-18206 Arseny Kapoulkine Mon, 30 Nov 2009 06:30:07 +0000 http://msinilo.pl/blog/?p=521#comment-18206 My experience with serialization is a bit different. a. Layouts do differ; even without platform-specific types and multiple inheritance, this struct barbase { int a; }; struct bar: barbase { virtual void foo(); double b; }; has size=24 in MSVC (Win/X360) and size=16 in GCC (Win/PS3). b. We frequently use pointers to arrays, so vector-specific solution is not sufficient. Since our meta-info is in code form, there is a special pointerToArray construct; we were planning to switch to PDB/ELF (via libbfd) parsing for reflection for quite some time now, we'll require some sort of annotation support for sure. c. Saving platform-specific types is a necessary thing (although we expose them in Windows export code to be able to serialize them, of course). d. LIP and SIP are more or less orthogonal; our LIP patches pointers, but SIP is slightly more complex than simple iteration and pointer following e. Something we also use is so-called post-constructors - a bits of code attached to specific classes that execute after the whole graph that contains those classes gets loaded; you can rely on pointer values inside objects you're pointing to there. My experience with serialization is a bit different.

a. Layouts do differ; even without platform-specific types and multiple inheritance, this
struct barbase { int a; };
struct bar: barbase { virtual void foo(); double b; };
has size=24 in MSVC (Win/X360) and size=16 in GCC (Win/PS3).

b. We frequently use pointers to arrays, so vector-specific solution is not sufficient. Since our meta-info is in code form, there is a special pointerToArray construct; we were planning to switch to PDB/ELF (via libbfd) parsing for reflection for quite some time now, we’ll require some sort of annotation support for sure.

c. Saving platform-specific types is a necessary thing (although we expose them in Windows export code to be able to serialize them, of course).

d. LIP and SIP are more or less orthogonal; our LIP patches pointers, but SIP is slightly more complex than simple iteration and pointer following

e. Something we also use is so-called post-constructors – a bits of code attached to specific classes that execute after the whole graph that contains those classes gets loaded; you can rely on pointer values inside objects you’re pointing to there.

]]>