Personally I looked at Lois Goldthwaite's so far, as well as the pas mailing list discussions and Herb Sutter's Exceptional C++ Style #17

In my personal opinion, this Item ... well .. is not completely correct (at best). It obviously doesn't cover class properties case and this is big omission ( by class properties many people mean different things, but I mean class data member for which you *required* to provide public read and/or/possibly write access). In my experience properties are met very frequently. Another things is that I really hate T& direct_member_access() pseudo-encapsulation interface. IMO it rather facilitate encapsulation breakage by providing direct access to class internals. Even get/set interface is better. But properties provide IMO interface that better then all others. The reason I stick to the simplest properties model (without custom get/set) is that I found that in majority of the cases this is good enough. Though I could definitely see a place for more advanced needs/solutions.

for a variety of opinions on them, I think a Boost version makes sense as long as their is a public health warning about over indulgence :-)

Kevin

Gennadiy

Jason Hise wrote:

Reece Dunn wrote:

...

I have worked on a property implementation that is available under the boost sandbox (if you want a zip distribution I can create one): boost-sandbox/boost/property boost-sandbox/libs/property

My version supports various property implementations (aliased, set/get, value) and supports scalar (single-value) and rank1 (1D array) properties.

Your various types of properties look interesting, and I definitely think that indexable properties are definitely a neat idea. However, there are two issues that I think could be improved. First, it would not appear that you support write-only properties.

This is easy to support by providing your own property implementation that provides: template< typename T > struct writeonly_property { void set( const T & v ); }; or, for rank1 (indexed) properties: template< typename T, typename Index > struct writeonly_property { void set( Index i, const T & v ); }; The design is such that you can supply your own class that supports the get and/or set operations and pass that to the scalar_property template (for single-valued properties) or rank1_property (for 1D array properties). In the larger picture, I would like to support a generic property template, similar to the likes of Boost.Function and Boost.Signal that would deduce the rank from the form that get/set take.

Second, it appears that your set type is fixed, meaning that if it is possible to assign an A to a B, it may not be possible to assign an A to a B property.

This is true.

Mine avoids this problem by templating the set method to take any type, allowing compilation to fail if the type client code attempts to use is invalid.

True. This would mean templatizing scalar_property and rank1_property that implement the various operators based on get/set operations as well.

I could be incorrect in my assessment of your code, as I have not compiled it myself, so please correct me if I am wrong.

The assessment is correct. There is also an issue w.r.t. using default generated copy assignment/constructor for classes that use properties and I don't have an ideal (library-based) solution for this. Regards, Reece