Re: Complexity of new hardware

The desire to keep the reflection definitions brief and part of the actual
class definition is actually contrary to our design goals for the system.

We anticipated very richly annotated reflection definitions and we didn't
want that information obscuring the class definitions.  This isn't a system
for publishing the memory layout of POD types to make writing objects to
disk and making endian conversion easier; it is framework for publishing
arbitrary metadata for C++ constructs.

To give you an idea, we have over 60,000 lines of reflection definitions in
our codebase and most of it is stuff I don't want to see when I'm reading
the header for a class.  A lot of it has to do with user interface design
and telling the cinema system which properties can be animated in what ways.
There is also stuff that doesn't tie directly to an actual member of a
class, like a fake "field" that reads data in an old format and writes
nothing--performing automatic version upgrade during serialization.

The redundant part of the system that I have the most mixed feelings about
is the manual specification of the name of a field.  Macros could have
automated that in most cases.  Having the name be explicit, however, has
proven useful on numerous occasions.  Our engineers like the flexibility to
refactor the code without having to worry about breaking serialization or
scripting.  It is perfectly valid to let a variable name in C++ diverge from
the string name in the reflection field.  It is also valid, and incredibly
useful, to remove a field entirely from a class and replace its
corresponding reflection entry with a getter/setter that emulates the old
field's behavior.

Adrian

-----Original Message-----
From: Alen Ladavac [mailto:[email protected]] 
Sent: Monday, April 20, 2009 6:16 AM
To: Adrian Stone
Cc: 'Game Development Algorithms'
Subject: Re: [Algorithms] Complexity of new hardware

Adrian wrote at 4/19/2009:
> http://gameangst.com/?p=107

The syntax approach is really interesting, but I find the overall
format too verbose. Still too much redundant data for my taste.

We use something much more terse:

meta ver(1) class ENGINE_API CDecalConfig : public CResource {
public:
  CDecalConfig(void);
  ~CDecalConfig(void);
  // ... functions ...
  
  MD_DECLARE;
public:
  _( 1) Vector2f dc_vSize; _("Size (m)")
  _( 2) IDENT dc_idTextureUVMap; _("Texture UV map")
  _( 3) IDENT dc_idShadowUVMap; _("Shadow UV map")
  _( 4) Ptr<CShaderPreset> dc_pspShader; _("Material")
flags(SMF_NEW|SMF_DELETE|SMF_BROWSE)
};

This of course, requires a custom parser, but I think it is very much
worth the extra typing later on. I find all the approaches that force
you to repeat yourself to be dangerous. You can easily forget to list
one of the variables. With the preprocessor approach, in contrast, you
immediately see everything about a member when you look at its
declaration.

Also, using per-class C++ code that creates meta objects at boot time,
as you mention in the article, is really heavy on the final executable
size, and linker performance. We used that previously, but trying to
ship with that for Xbox1 forced us to rewrite it to use static data
per class, which is then read by the reflection code at boot time to
generate the needed objects. That approach makes handling templates
more complicated, though.

Alen



------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list