Re: [boost] [property] interest in C# like properties for C++?

Subject: Re: [boost] [property] interest in C# like properties for C++?
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-10-21 16:40:43

Hi,

----- Original Message ----- 
From: "Sid Sacek" <ssacek_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, October 21, 2009 7:26 PM
Subject: Re: [boost] [property] interest in C# like properties for C++?

> 
> Sorry, 
> 
> Edward Diener is absolutely correct in this manner.
> 
> The C# language is very clear about what properties are, why they're part of the language, and how they're used.
> 
> Let me remind you that this topic is:  "interest in C# like properties for C++?"
> 
> 
>    x.count()   is not a property usage... it is a blatant accessor function call
> 
> 
> Think about these two lines of code:
> 
>    int x, y;
>    x = y = 100;
> 
> Now, if x and y were properties instead of variables, you would be able to write code like this:
> 
>    obj.x = obj.y = 100;
> 
> Now, how would you write that line of code using accessor functions? By any standard, it would be inferior to the syntax above.
> 
> -Sid Sacek

I agree completly.

in TBoost.STM we are defining transactional variables, which will return the address on the transaction cache or the value itself. This transactional variable follow the same schema than the properties.

    tx::int_t i;

    atomic(_) {
        i = 0;
    } end_atomic;

or 

    int res;
    atomic(_) {
        res = i+3;
    } end_atomic;

I think that it is very important that the user of properties don't change the way it used to use variables or fields. The oposit could be a drawback on soeme cases. For example, I have adapted the Bitfields libraries and provided some kind of trivial accessors. 

        struct Rgb565
        {
            uint16_t storage;
            BOOST_BITFIELD_DCL(uint16_t, storage, unsigned char, red, 0, 4);
            BOOST_BITFIELD_DCL(uint16_t, storage, unsigned char, green, 5, 10);
            BOOST_BITFIELD_DCL(uint16_t, storage, unsigned char, blue, 11,15);
        };

        Rgb565 r;
        r.storage= 0xffff;

        // Write to a bitfield. Note that parenthesis are needed around the bitfield
        r.red() = 23;

        // Read from a bitfield
        unsigned char b = r.blue();

Recently I have ported a big project from big to little endian and I used this class, but I needed to add the cuple of parenthesis '()' in each field access. I  would liked to provide instead a more natural interface so the user can do 

        Rgb565 r;
        r.storage= 0xffff;

        // Write to a bitfield. Note that parenthesis are needed around the bitfield
        r.red = 23;

        // Read from a bitfield
        unsigned char b = r.blue;

but I didn't know how.

The trick of self could works, but the issue is that an instance of any class use a minimal storage, and this was forbiden on my particular use case.
Could we define a property of a class that don't spend any memory at all in th embeeding class? 

Anyway, I think that a Property library will be welcome in Boost. I see two major non functional requirements to the sucess of such a library: efficiency and transaparent use.

Best,
Vicente