|
Boost : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-05-23 05:26:01
Hi,
I am using simple class properties facility for some time and found it quite
useful. Actually it's nothing fancy - simple helper classes to eliminate
repetitive setter/accessor methods (and no need for language extensions).
Essentially if you need simple readwrite property with trivial access
methods in you class you would instead of writing:
T member;
void set_member( T const& ) {...}
T const& get_member() {...}
would write:
readwrite_property<T> member;
Now any time you need to get a member value you would write
T t = obj.member;
while if you need to update the value:
obj.member.value = t;
It's not more nor less safe as usual get/set scheme.
If you need readonly object property that get initialized in constructor and
never updated you could use
readonly_property template for example like this:
class node {
public:
readonly<std::string> p_name;
....
};
Now everywhere (almost) you could just use n.p_name. To get an access to
name member functions you could use operator-> like this:
n.p_name->size();
And nobody would be able to update readonly property value.
Finally if you need to provide a write access for readonly property you
could use another form of readonly_property template. Unfortunately during
language limitations (inability to declare template parameter as friend) you
would need to use macro, for example like this:
class foo {
public:
BOOST_READONLY_PROPERTY( int, (foo)(Friend2) ) p_value;
...
};
Now only class foo and Friend2 have a write access to the value of the
property p_value;
If boosters find this functionality worth reusing I am ready to prepare
document page describing it's usage.
If we don't find this header eligible for review I would like to ask then
for permission to at least put these templates in boost namespace (currently
boost::unit_test), for it inconvenience for me to keep it in deep namespace
for rest of my current development.
Header you could see here:
Regards,
Gennadiy.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk