Boost logo

Boost :

Subject: Re: [boost] [property] interest in C# like properties for C++?
From: David Brownstein (dbrownstein_at_[hidden])
Date: 2009-10-23 16:25:14

-----Original Message-----
From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of Edward Diener
Sent: Friday, October 23, 2009 8:33 AM
To: boost_at_[hidden]
Subject: Re: [boost] [property] interest in C# like properties for C++?

Olaf van der Spek wrote:
> On Fri, Oct 23, 2009 at 3:40 PM, Edward Diener <eldiener_at_[hidden]>
>>> Maybe I should've said class reference. Take std::string for example.
>>> I'd be very interested if you've got code that supports for example
>>> name.size() where name is your reference property class. name->size()
>>> is no problem, but I'd like to have name.size().
>> I understand your point, and you are right, and this is a notational
>> weakness as compared with accessing the data directly.
>> I don't believe that one can define a dot ( '.' ) operator in C++ but
>> there is a metaprogramming way to hijack the dot operator. If there is I
>> would be glad to use it.
>> Actually I have rejected defining the -> operator for my reference
>> properties, because -> implies a pointer in standard C++ terminology and
>> do not think of reference properties "pointing" to their type object.
>> Instead my reference properties have currently no built-in forwarder
>> operator to the actual type object. One could currently use the more
>> laborious form of:
>> propertyReference<std::string> name;
>> std::string & avar = name; // read/write property reference getter
>> avar.size() = 10; // or
>> std::string::size_type sz(avar.size());
> Unacceptable
>> or one could use my getter member function so one could write:
>> propertyReference<std::string> name;
>> name.getReference.size() = 10; // or
>> std::string::size_type sz(name.getReference.size());
> Unacceptable
>> Using a member function rather than an operator in this case is just a
>> little more inconvenient.
> For me, the access syntax of properties is *the* reason for using them.
> Otherwise you might as well just add string& name() and void
> set_name(const string&) functions to your class.
> What are your goals/reasons to use properties?

You are not talking about the access syntax of properties, as I define
it, so your "Unacceptable"s mean little to me. Of course if the syntax
limitations of a property implementation vis-a-vis direct manipulation
of a data value is unacceptable to you, then you just wouldn't use it.

My interpetation of the access syntax of properties is:

1) For a readable value property, one can use the name of the property
to return the underlying value of the property and assign that value to
a variable.
2) For a writable value property one can set the value of a property by
assigning a value to it.
3) For a readable reference property, one can get a reference to the
4) For a writable reference property, one can get a non-const reference
to the property.

My main goals/reasons for properties are:
1) Syntactically treat a property as close as one can as a data member
while providing the ability to control the accessing of the data and the
setting of the data through callables ( functions, member functions,
functors, boost::function ).
2) Have properties be a type.
3) Have all value properties of an underlying T type share an underlying
base class and have all reference properties of an underlying T type
share an underlying base class.
4) Provide means beyond just member functions for getting and setting
values and getting references.

I have more than just these goals, but the above are the main ones.

Properties are in one way syntactic sugar for the plethora of
get/retrieve/etc. and set/put/etc. member functions. I also acknowledge
that it is syntactically impossible to manipulate properties as directly
as one can manipulate data members as far as I can see. But properties
are really not a substitute for data members but rather for get-like and
set-like functions whose purpose is to access and manipulate a data
value. After all, in my view of value properties, the data does not have
to exist in memory at all, and I believe this is consistent with the
implementation of properties in other languages.

Of course you can use "string & name()" and "void set_name(const string
&)" if you like instead, or you can even just have a public variable of
"string name" you directly access and manipulate. I can offer my
criticism of the first choice or the second choice but I think it is
already well known.

>> My member function is actually currently called "getValue" for my
>> property but I have decided that it is a confusing name since one is
>> getting a reference, and have changed it to "getReference".
> How about just get()?

I rejected this because of a feeling that some implementations of C++
may macroize ( create a C++ preprocessor macro ) from such a common term
as "get". The same goes for "set". I am aware that ideally macros should
  be all uppercase, but many implementations and header files which
should know better are deficient and forget this. Of course I can use
"get" and "set" as the OP did in his C#-like property implementation,
but I felt that getValue, setValue, getReference, and setReference were
less likely to clash.

Regarding goals for implementing properties, it seems to me that if a
properties implementation only provides convenient notation for accessing,
that would be unfortunate. IMO properties could be very useful by providing
a code generation facility so that users won't have to manually implement
setters and getters. This is my primary motivation for defining and using
properties - it was important enough that I wrote a simple property


Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at