Re: [boost] Another implementation of properties.

Subject: Re: [boost] Another implementation of properties.
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-03-03 13:07:54

Germán Diago wrote:
> Hello. I've been trying to implement properties for c++0x, for now.
> I've come up with this solution for now.
> 
> You need g++ svn to test it. It's a partial implementation, since not
> every operator is overloaded.
> 
> Space overhead:
> 
>     - one pointer to the object per property instance.
>     - the pointer to the member functions is shared among every
> instance of the class, so it's a per-class and not per-instance
>       overhead, which is negligible.
> 
> Usage:
> 
> class Person {
> 
>        int getAge() const { .... };
>        void setAge(int age) { ... };
> 
>        PROPS_RWPROPERTY(Age);
> 
>        Person() : Age(this) {}
> };
> 
> You can:
>     - declare getters/setters const or nonconst.
>     - getters must have one parameter.
>     - setters must return void.
>     - it has some operators overloaded, but the idea is to overload
> all of them if the implementation is all right.
> 
>    - the property returns whatever you put in your getter and gets as
> a parameter what you put in the setter.
> 
> 
> If you declare the getters and setters to be VIRTUAL, you get virtual
> behaviour, so you can use virtual properties, even with pure
> virtual functions, and it will work.

So you have a lot of code here, but I am confused what problem you are solving.  What is the practical difference between using your property and just declaring a data member:

 class Person {
         public:
        int getAge() const { return Age; };
        void setAge(int age) { Age = age; };
         private:
        Age;
         public:
        Person() : Age() {}
 };

By the way, your EnableIf that doesn't use enable_if_c will eventually run into compiler bugs in MSVC8 and 9 because of the order it evaluates template instantiations.

Usually I think of properties as something attached to an instance of a class without the need to modify the class.

 class Person {
        string Name;
        Person() : Name() {}
 };

 Person p;

 Property<int, Person> Age(-1); //default age is -1, an error code

 Age.set(10, &p);
 assert(Age.get(&p) == 10);

Such a thing becomes rather complicated once you try to wire in removal of property values to the destructor of your object type and duplication of property values to the copy constructor without the need to know about all the kinds of properties that might be later associated with the class at the time the class is defined.  Add to that custom heaps for storing property values and clever schemes to look them up and you quickly run into a system that is quite complicated with singletons running around and issues with thread safety etc etc.  I think it is better to keep things simple where possible and understand clearly what the problem is and why the problem requires a complicated solution before implementing or using a complicated solution.

Regards,
Luke