|
Boost : |
From: Edward Diener (eddielee_at_[hidden])
Date: 2004-03-13 03:37:48
Bronek Kozicki wrote:
> Daniel Frey <daniel.frey_at_[hidden]> wrote:
>> BTW: These things are good to discuss. I think some of this should
>> make it to the documentation :)
>
> I'd like to point your attention to
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1600.html
Most of these ideas are taken from Delphi/C++ Builder, which is
understandable since one of the chief architects of .NET, Mr. Hejlsberg, was
one of the chief architects of Delphi/C++ Builder before he was hired away
by Microsoft. On comp.std.c++ I, and others, argued for properties in C++ a
while back along many of the same paths as taken in the article above. The
article even repeats the same arguments made for properties which I made on
comp.std.c++: syntactic sugar for getXXX()/setXXX() and support for RAD via
introspection. I find it amusing that while properties were part of
Delphi/C++ Builder 9 years or so, they were considered outside the bounds of
C++, but now they have been adapted by Microsoft for .NET in the past 3
years, they are now considered with much more importance and relevance as a
real possibility for a future C++.
>
> This is actually not a proposal, just a status of properties as being
> worked on by C++/CLI group. However please keep in mind, that once
> it's established, it will go (or may go?) on the fast-track of C++
> Committee. C++/CLI properties are going somehow across (hm, I do not
> know if that's
> a good word) ICF as proposed in N1611, as both may result in function
> call taking form:
> object.member_variable
>
> difference is that properties privide clean notion of getter/setter,
> while in ICF things appear to be more complicated.
ICF's notion of setting values when it must be done through member
functions, what it calls filtering which needs a proxy class, is much more
complicated than setting properties via a member function in the property
notation as exemplified in the above proposal ( and in Delphi/C++ Builder ).
For that reason I favor a separate proposal on properties, as exemplified
above, which is outside the bounds of ICF.
> On the other side
> properties do not seem to support template getter/setter .
I feel that properties, purely in the form of setter/getter functions and
without any special notation for RAD introspection, can be done using
templates and pure C++ notation, with boost::function serving as the glue
which ties the property to setter/getter functions. If I can work something
out along these lines I will post it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk