Boost logo

Boost :

From: Björn Karlsson (bjorn.karlsson_at_[hidden])
Date: 2001-11-06 09:25:58


> -----Original Message-----
> From: Gennadiy E. Rozental [mailto:rogeeff_at_[hidden]]
> Sent: den 5 november 2001 23:17
> To: boost_at_[hidden]
> Subject: [boost] Re: Class properties utility classes
>
> P.S. Does anybody know conformable alternative?
>

Sure; at least for some applications, some contained classes and with some
additional costs...

The property is (often) a public member, right?
So if you have the following classes:

struct BreakMyEncapsulation
{
        BreakMyEncapsulation(int iRO) : RO(iRO) {}
        readonly_property<int> RO;
};

struct BreakMyEncapsulationAgain
{
        BreakMyEncapsulationAgain(int iRO) : RO(iRO) {}
        const readonly_property<int> RO;
};

struct BreakMyEncapsulationIfYouCan
{
        BreakMyEncapsulationIfYouCan(int iRO) : RO(iRO) {}
        const readonly_property<const int> RO;
};

You can always do:

int main(int argc, char* argv[])
{
        BreakMyEncapsulation test1(1);
        BreakMyEncapsulationAgain test2(2);
        BreakMyEncapsulationIfYouCan test3(3);

        // Easy, but will a client ever try it?
        test1.RO = readonly_property<int>(42);
        // Harder, which might be acceptable for changing readonly values
from inside the class
        const_cast<readonly_property<int>&>(test2.RO) =
readonly_property<int>(42);
        // You are now entering undefined territory
        (readonly_property<int>&)test3.RO = readonly_property<int>(42);

        std::cout << test1.RO.get() << test2.RO.get() << test3.RO.get() <<
std::endl;
        return 0;
}

Of course, this involves creating a temporary that is assigned to the member
variable. If considered a bug, this can easily be avoided by protecting
assignment. I would rather view it as a feature, and document it as such.
This will no doubt raise new questions, such as efficient usage,
requirements for contained classes etc. Anyway, the issue probably needs to
be addressed.

Regards,

Bjorn


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk