Re: Complexity of new hardware

Ours just looks like this (I'm sure this isn't unique to us):

class MyClass : public BaseObject
{
public:
	MyClass();
	~MyClass();

	HYP_CLASS(MyClass, BaseObject); // make this class part of
reflection
	HYP_CLASS_CREATABLE(); // lets you create one of these in the editor
	
	HYP_PROPERTY(Int32Property, "My property description, for editor", \
Int32, 12, 0); 	
	HYP_PROPERTY(StringProperty, "My property description, for editor",
\ 		String, "stringDef", 0);

	// and so on

private:
	// these don't partake in reflection
	int m_someMember;
	void* m_pSomeOtherMember;
};


No parsing or code generation needed. These properties insert a single
variable of the declared type in the class; you can access it directly via
the mangled name or through getters/setters (getInt32Property() for
example). The rest is done in macros and static init. It's primarily for the
convenience of data editing and marshaling from the editor output format;
there are no method calls in this system. It's worked well for us; once the
headache of putting together the property templates and macros is done,
there's nothing left but to use it.

But I agree with Jon, it would be nicer if there were something in C++ that
provided the same functionality in a first-class system; at this point I
really am just re-implementing the part of CLR reflection that we need.

Greg


------------------------------------------------------------------------------
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