Hi All,

Properties has been disccussed before as proposal for the new C++
standard.
I found two solutions with templates in this group.
BUT it is NOT properties.

class A {
  void set_p( int n );
  property<int> p;
...
};

A a;

Real property assignment
a.p = 3;
Should call member function of A not property<int> operator=()!

So, to correct initialize property you have to pass A* inside
property<int> in constructor or some init function - this is
convoluted.

I'd like to have Object Pascal like properties.

// a.p=3 calls a.p_set( 3 );
// int i=a.p calls a.p_get();
property p read p_get() write p_set( int );

// You can only read member p_;
property p read p_;

and so forth.

Sincerely yours,
Vadim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

vadima@waterint.com (VAdim) wrote in message news:<ac9acec7.0205031242.1f080ea3@posting.google.com>...
> Hi All,
>
> Properties has been disccussed before as proposal for the new C++
> standard.
[snip]
> I'd like to have Object Pascal like properties.

While i agree that properties can not be created easily in C++ i also
have some problems to see their use. I would prefer the following
approach:

class C
{
   int myval; // property-based value
public:
   int  val() const { return myval;}
   int& val() { return myval;}
};

Now you can use val() almost like a property as found in e.g. Borland
C++, just add the paranthesis:

C c;
c.val() = 7;  //  instead of c.val = 7;

This slight inconvenience is okay in my opinion, and it stops making
you wonder why e.g. the function void f(int &i) can not be called with
c.val.

Kind regards
Peter Koch Larsen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

> class C
> {
>    int myval; // property-based value
> public:
>    int  val() const { return myval;}
>    int& val() { return myval;}
> };
>
> Now you can use val() almost like a property as found in e.g. Borland
> C++, just add the paranthesis:
>
> C c;
> c.val() = 7;  //  instead of c.val = 7;
>

This is not Ok again.
c.val()=7; Can't check rvalue (7) for valid range or whatever.

I'd prefer
public:
  int val;

I hope next C++ standard will have properties support.

VAdim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

vadima@waterint.com (VAdim) wrote in message news:<ac9acec7.0205060411.6007978e@posting.google.com>...
> Hi,
[bad code snipped]
> This is not Ok again.
> c.val()=7; Can't check rvalue (7) for valid range or whatever.
>
> I'd prefer
> public:
>   int val;
>
> I hope next C++ standard will have properties support.
>
Hi VAdim

Yeahhh.... i was a bit hasty; my previous post was influenced by some
code, I had just used at my work. Neither the first nor the last time,
i guess ;-)
The proper code could be:

....
int val() const { return myval;}
int val(int i) const { myval = i; return myval;}

...and thus you should write c.val(7) rather than c.val(7).

But still a simple and clean syntax, do you not agree?

If you insist, you *could* write a "val" function, that could return
an object which had an assignment operator that could do the job for
you. This approach could easily be automated some template mechanism.
My original point still stands, however: I see no big need for
properties in C++. Even though i do use Borland C++ now and then, i
*never* use their built-in extension of properties -not just because i
reduce portability (which really does not matter so much for my
current project) but most of all because i prefer the syntax mentioned
above.
I would still very much like you to explain the big advantage of
properties.

Kind regards
Peter Koch Larsen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Peter Koch Larsen" <pkl@mailme.dk> wrote in message
news:61c84197.0205061313.6eda7ccb@posting.google.com...
> I would still very much like you to explain the big advantage of
> properties.

Properties provide a notational advantage in a slightly easier and clearer
notation while still allowing for the setting or getting of a property to be
controlled by a class member function rather than an actual data assignment
or access.

I use C++ Builder and I do like the ease by which one says
"object.SomeProperty = somevalue;" rather than
"object.SetSomeProperty(somevalue);" or "SomeVariable = object.SomeProperty"
rather than "SomeVariable = object.GetSomeProperty()", but of course they
are equivalent in functionality. The issue with adding properties to C++ is
therefore one solely of notation. Is it worth it ? I believe so, because it
represents this particular concept better through a clearer notation, but
many others seem to disagree.

Although adding properties is merely a matter of adding a notation to C++
where otherwise the same facility already exists in other ways in a more
standardized form, I believe that computer languages, and C++,  should
consider changes to the language in order to provide ease of notation for a
slightly different concept than what already exists. Notice I have said
"should consider". It doesn't mean by a long shot that I believe computer
languages, and C++ in particular, should add new syntax just to create
easier notation in every case. I do believe that such additions should be
carefully considered, especially in cases where the new syntax causes very
little problems in current code and usage and is a definite notational
advance for the clearness of a concept.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Edward Diener" <eldiener@earthlink.net> wrote in message news:<CHTB8.874$Yi6.616@newsread1.prod.itd.earthlink.net>...
> "Peter Koch Larsen" <pkl@mailme.dk> wrote in message
> news:61c84197.0205061313.6eda7ccb@posting.google.com...
> > I would still very much like you to explain the big advantage of
> > properties.
>
> Properties provide a notational advantage in a slightly easier and clearer
> notation while still allowing for the setting or getting of a property to be
> controlled by a class member function rather than an actual data assignment
> or access.
I agree there's a slight notational convenience, but only a slight
one. Notice that if you have a function int f(void), users do not
normally quibble that it's inconvenient that you have to write int
i;... i = f(); rather than the shorter and more convenient i = f; in
my opinion, the inconvenience is in the same order of magnitude.
>
> I use C++ Builder and I do like the ease by which one says
> "object.SomeProperty = somevalue;" rather than
> "object.SetSomeProperty(somevalue);" or "SomeVariable = object.SomeProperty"
[snip]
Why those redundant "Get" and "Set" prefixes? I would prefer to
compare
"object.SomeProperty = somevalue;" with
"object.SomeProperty(somevalue);" and
 "SomeVariable = object.SomeProperty" with
"SomeVariable = object.SomeProperty()".
> are equivalent in functionality. The issue with adding properties to C++ is
> therefore one solely of notation. Is it worth it ? I believe so, because it
> represents this particular concept better through a clearer notation, but
> many others seem to disagree.
I do agree that the lack of parenthesis saves you from a little
typing. I do find the "parenthesis-stuffed" C++ version clearer,
however. You have no doubt that you are calling a function (which do
hint that you might get an exception and that you can not call by
reference. Also, for performance-intensive calculations, you might
consider putting the function outside a loop if the call could be
expensive).
[snip]

> Although adding properties is merely a matter of adding a notation to C++
> where otherwise the same facility already exists in other ways in a more
> standardized form, I believe that computer languages, and C++,  should
> consider changes to the language in order to provide ease of notation for a
> slightly different concept than what already exists. Notice I have said
> "should consider". It doesn't mean by a long shot that I believe computer
> languages, and C++ in particular, should add new syntax just to create
> easier notation in every case. I do believe that such additions should be
> carefully considered, especially in cases where the new syntax causes very
> little problems in current code and usage and is a definite notational
> advance for the clearness of a concept.
I agree. Be careful with additions - especially if all they provide is
a slight change of notation. If i were to argue for properties, i
would rather try to argue from the "ease of change" point of view. If
you have public members in your class, changing those members to
private with controlled access via properties will be easier. Still i
would argue against properties in C++.
Kind regards

Peter Koch Larsen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Peter Koch Larsen wrote:
> Notice that if you have a function int f(void), users do not
> normally quibble that it's inconvenient that you have to write int
> i;... i = f(); rather than the shorter and more convenient i = f; in
> my opinion, the inconvenience is in the same order of magnitude.

In some programming languages, such as Ada, you *do* just write "f"
to call a function with no parameters. The argument for this is just
like the argument for properties, namely that you can replace a
variable with a function without changing user code. In fact, in Ada
enumeration literals are considered to be parameterless functions
which return their value of the appropriate type. And since Ada has
overloading by return type, this allows different enumeration types
in the same scope to have identical literals which are distinguished
by context. This would be nice for C++ to have.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener:
> > Properties provide a notational advantage in a slightly
> > easier and clearer notation while still allowing for the
> > setting or getting of a property to be controlled by a
> > class member function rather than an actual data
> > assignment or access.

Peter Koch Larsen:
> I agree there's a slight notational convenience, but only a slight
> one. Notice that if you have a function int f(void), users do not
> normally quibble that it's inconvenient that you have to write int
> i;... i = f(); rather than the shorter and more convenient i = f; in
> my opinion, the inconvenience is in the same order of magnitude.

The main advantage of property notation is it looks
like data member access, rather than the fact it
saves a few key strokes.

> > I use C++ Builder and I do like the ease by which one says
> > "object.SomeProperty = somevalue;" rather than
> > "object.SetSomeProperty(somevalue);" or
> > "SomeVariable = object.SomeProperty"

> [snip]
> Why those redundant "Get" and "Set" prefixes?

Don't read too much into it. It's just a convention.

> I would prefer to
> compare
> "object.SomeProperty = somevalue;" with
> "object.SomeProperty(somevalue);" and
>  "SomeVariable = object.SomeProperty" with
> "SomeVariable = object.SomeProperty()".

> > are equivalent in functionality. The issue with adding
> > properties to C++ is therefore one solely of notation.
> > Is it worth it ? I believe so, because it represents this
> > particular concept better through a clearer notation, but
> > many others seem to disagree.

> I do agree that the lack of parenthesis saves you from a little
> typing.

Again, it isn't the typing. It's what Betrand Meyer
calls "uniform access" (http://www.elj.com/elj/v1/n1/bm/urp/ )

Although to me property notation often looks
clearer, also.

> I do find the "parenthesis-stuffed" C++ version clearer,
> however.

And you are entitled to your opinion. I would
guess C++ programmers split roughly 50/50 on
this issue (with those who have actually used a
language which supports properties being on
the whole more positive about them). Because
I don't see any consensus for change I don't
expect properties to appear in C++0x.

> You have no doubt that you are calling a
> function (which do hint that you might get an
> exception and that you can not call by reference.
> Also, for performance-intensive calculations, you
> might consider putting the function outside a loop
> if the call could be expensive).

Compare the following two lines of code in a
C++-like language:

a.b( c );
d.e = f;

Either of these could throw an exception, involve
a call by reference and take so long to execute
that you'd want to move them outside your inner
loops. This is just as true if the language is today's
C++ as if it were a C++-like language that supports
properties.

[snip]

By the way, you can "sort-of, kind-of" support
properties in today's C++. A simplified, but still
compilable, example:

#include <iostream>
using namespace std;

template <
    typename T,
    typename Parent,
    T (Parent::*GetFnPtr)(),
    void (Parent::*SetFnPtr)(T)>
class property
{
public:
    explicit property(Parent* parent) :
        m_parent( parent )
    {}

    operator T() const { return (m_parent->*GetFnPtr)(); }

    property& operator=(const T& rhs)
    {
        (m_parent->*SetFnPtr)( rhs );
        return *this;
    }

    property& operator=(const property& rhs)
    {
        (m_parent->*SetFnPtr)( (rhs.m_parent->*GetFnPtr)() );
        // Leave parent pointer alone.
        return *this;
    }

private:
    Parent* m_parent;

    // Disable copy ctor. If the parent wants to be CopyConstructible its
    // copy ctor should call the property's explicit ctor instead - this
    // object needs the correct parent pointer, which a copy ctor is
    // unable to supply.
    property(const property&);
};// class property

class test
{
    int m_foo;

public:
    int GetFoo() { cout << "Get Foo\n"; return m_foo; }
    void SetFoo(int value)
    {
        cout << "Set Foo\n";
        m_foo = value;
    }

    property<int, test, &test::GetFoo, &test::SetFoo> Foo;

    test() :
        m_foo( 1 ),
        Foo( this )
    {}
};// class test

int main()
{
    test t1;
    t1.Foo = 7;
    int i = t1.Foo;
    t1.Foo = t1.Foo;
    cout << i << " " << t1.Foo;
}

The general nastiness of the template, extra storage
requirements (one pointer-to-parent per property) and
non-idiomatic nature of properties in C++ are enough
to put most people off using such things though.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]