Topic: Should a future C++ include Properties, Design Time Interfaces and
Author: Don Griffin <dgriffin@farallon.com>
Date: 1997/07/09 Raw View
>Feels like this can be accomplished with existing C++ by having a
>template class serve as a proxy dummy object, with assignment and
>conversion operators overloaded.
I have done this before (for a bit vector class). It gives the right
syntax, but I found that my compiler did not do such a good job of
inlining this construct. It also adds several steps to the hopefully
simpler syntax of the proposed "property" feature. That is to say: I
would use properties (heavily?); I would not use proxy objects. The
cost overwhelms the benefits, IMO.
Don
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: ken@digitas.harvard.edu (Ken Shan)
Date: 1997/07/10 Raw View
Don Griffin (dgriffin@farallon.com) wrote:
> I have done this before (for a bit vector class). It gives the right
> syntax, but I found that my compiler did not do such a good job of
> inlining this construct. It also adds several steps to the hopefully
> simpler syntax of the proposed "property" feature. That is to say: I
> would use properties (heavily?); I would not use proxy objects. The
> cost overwhelms the benefits, IMO.
i agree that one "this" pointer per proxy object is a bit too much,
and not reasonable to ask a compiler (that doesn't explicitly know
about this kind of idiom) to optimize away.
However, it seems to me that the best solution is also what happens to
be existing practice, i.e., accessor methods. Although the syntax
would be different from simple member variable retrieval and
assignment, it is still sufficiently clean to be used on a large
scale. I'm one of the (few?) people who believe that member variables
should all be private.
--
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
If you want to eat fish, fish fish. Fish fish fish, for the same reason.
No Boom Today! Boom Tomorrow! Always Boom Tomorrow!
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: ken@digitas.harvard.edu (Ken Shan)
Date: 1997/07/08 Raw View
Don Griffin (dgriffin@farallon.com) wrote:
> Properties are supposed to provide member variable syntax while allowing
> the implementation to provide side-effects. Eg:
> foo->property = 10; // might actually invoke a method
> int n = foo->property; // ditto
> The idea is to hide the fact that "property" is anything other than a
> value associated with the object. The closest C++ equivalent would be:
> foo->property (10); // set
> int n = foo->property(); // get
Feels like this can be accomplished with existing C++ by having a
template class serve as a proxy dummy object, with assignment and
conversion operators overloaded.
--
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
If you want to eat fish, fish fish. Fish fish fish, for the same reason.
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]