From -8808278178261599973
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,1d4cb0b1f508085e
X-Google-Attributes: gidf78e5,public
From: ken@digitas.harvard.edu (Ken Shan)
Subject: Re: Should a future C++ include Properties, Design Time Interfaces and
Date: 1997/07/10
Message-ID: <5q0sqf$rl6$1@news.fas.harvard.edu>#1/1
X-Deja-AN: 255884108
References: <33B6D13D.BDD71D73@xs4all.nl> <33BBACD9.3C88@sni.de> <33C147F4.A9E911B@farallon.com> <5psaru$bns$1@news.fas.harvard.edu> <33C2C38C.26056935@farallon.com>
Pp-Warning: Illegal Received field on preceding line
X-Original-Date: 9 Jul 1997 20:37:35 GMT
Original-Received: by news.fas.harvard.edu with id  QAA27993
Organization: Digitas
X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUBM8Rn+OEDnX0m9pzZAQGh0AGAjKccLz2sy0uKUSstPiVtrJBoJZWXPZeS Db6DcDj+eYkwcW8zoS8wi/bTD7tmrnZ8 =RV2H
Newsgroups: comp.std.c++
Originator: fjh@mundook.cs.mu.OZ.AU


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                             ]