Re: [boost] Another implementation of properties.

Subject: Re: [boost] Another implementation of properties.
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-03-03 16:15:31

Hi Germán,
----- Original Message ----- 
From: "Germán Diago" <germandiago_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, March 03, 2010 5:33 PM
Subject: [boost] Another implementation of properties.

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

I don't like this as the size of each property is increased by sizeof(void*).

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

You should be able to don't store them at all using the template parameters (see attached files)
 
> 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.

I don't think this is necessary if you have an operator T&(), but maybe I'm wrong.
 
>   - 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.
> 
> Caveats:
>   - Needs c++0x compiler for now.

I have not seen at the implementation but I suppose you use it to retrieve the property type. 
Have you tried with Boost.Typeof?

>    - Not enforced the read-only access for properties for now. I need
> extended friend declarations for that, and the operator= would be made
> private with friend class. But for now it's not reinforced.
> 
> I think this implementation is pretty usable as-is. It's just a matter
> of extending it. I don't use the offset trick because I think it does
> not work
> with classes with virtual members, but I'm not sure.

Why offsetof is a C++ standard macro that should work in any case. 

if f is a field of a type T 
reinterpret_cast<T*>(reinterpret_cast<char*>(this)-offsetof(T,f)))

should point to the T instance, isn't it?
Someone tolds that this works only for POD. Could you clarify?

I'm not telling that the use of this trick is good. I just wants to know if this can be used as proposed.

I think that properties that have no associated storage should take no space on the class instance. 
If we want a syntax such as

c.prop = x

we need a 'prop' member that will take at least 1 byte(if no more). For example

struct P1 {};
struct P2 {};
struct S {
        int i;
        P1 p1;
        P1 p2;
};

sizeof(P1)=1
sizeof(P2)=1
sizeof(S)=8

Is for this reason that I think we need a function syntax:

c.prop() = x

In this case, I agree with Stefan, I don't see a real advantge of

class Person {
      int getAge() const { .... };
      void setAge(int age) { ... };
      PROPS_RWPROPERTY(Age);
      Person() : Age(this) {}
};

over 

class person {
    int age_;
public:
      int age() const { return Age_ };
      int& age() { return Age_ };
      person() : age(0) {}
};

I don't think that I will use a property library that uses more memory than needed, if the library doesn't provides more features that just access and modification of the property.

I have attached an implementation that uses template parameter member functions, maybe this can help you for your library.
Note that I'm not proposing the attached files as an alternative proposal, as I have said, the flat implementation is enough to me if properties don't offer more. It is just to show another way to implement what you are looking for.

Best, 
Vicente