From -1435955861420630924 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,49dc144769c6b88f X-Google-Attributes: gidf78e5,public From: "Crosbie Fitch" Subject: Re: Empty objects (was Re: Are there any plans to make "properties" standard?) Date: 1999/06/28 Message-ID: <7l87d4$3fc$1@soap.pipex.net>#1/1 X-Deja-AN: 495139935 X-NNTP-Posting-Host: mailhost.peppersghost.com Approved: stephen.clamage@sun.com (comp.std.c++) References: <7jprhq$e8r@cocoa.brown.edu> <376278B4.C9EDDB26@acm.org> <37734C93.672DA531@dera.gov.uk> X-Priority: 3 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Complaints-To: abuse@uk.uu.net X-Trace: soap.pipex.net 930586852 3564 193.130.150.161 (28 Jun 1999 16:20:52 GMT) Organization: at Lewes, East Sussex, UK X-MSMail-Priority: Normal NNTP-Posting-Date: 28 Jun 1999 16:20:52 GMT Newsgroups: comp.std.c++ Originator: clamage@taumet David Bruce wrote in message news:37734C93.672DA531@dera.gov.uk... > > Right, so the real question for c.s.c++ is not ``how do we do properties'' > but rather ``what changes would need to be made to C++ to allow this natural > use of objects to be implemented (space) efficiently'', this being not only > the root cause but also a more general problem. > > I'm aware that the issue is that (member) objects are not permitted to have > the same address, so I guess I'm asking *why* that's so important, and what > an alternative C++ where it wasn't the case would look like. > > For example, given that C++ has references, when do we really need to take > the address of (member) objects (as distinct from their pointer-to-member > `address')? (Identity comparisons are perhaps the most obvious case, but > maybe if one could compare objects for identity directly -- e.g., a > non-overloadable operator=== ? -- rather than by comparing their addresses > this might be less significant.) What else could go wrong if two (member) > objects did have the same address? Well, we already have one mechanism for specifying that only one instance of a class is required in a multiple-inheritance graph, i.e. virtual inheritance. How about using that keyword to specify that a class defined within another can share an instance with its containing class. I've already posted the following (25th), but it seems not to have appeared yet. NB I've since realised that someone might actually want to define a member class that virtually inherits from a virtual base of the containing class (rarely perhaps...). * * * Having tried to achieve properties in C++, I conclude that the one single thing that would make them possible is if there was a facility to expose a member variable that was derived from, and colocated with, the containing class, e.g. (Relax, sit down, pour a shot of whisky, ...) class A { protected: int m_n; public: class PropN: virtual private A public: operator int() const { return m_n+17; } PropN& operator=(const int& n) { m_n=n-17; } }; A():m_n(-17) { } PropN n; }; 1) PropN objects are colocated with their container 2) A must already be constructed by the time PropN's constructor is called, but PropN can explicitly call an additional A constructor if it needs to 3) PropN members are constructed after all 'normal' members (can be explicitly constructed if desired) 4) If PropN has no members it takes no storage (at least not in A). 5) Without 'virtual' PropN would be an instance of A (and would be recursive) so is still an error. 6) The name spaces or scopes of PropN and A are recursive, but users don't have to go A::PropN::A::m_n, etc.? 7) Multiple properties having data members may get as tricky to implement as multiple inheritance 8) I don't think there's currently going to be any code that looks like the above. 9) If any code calls new PropN() then a new A is constructed as normal. (Nurse! The ECT machine, quick!) [ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]