David Bruce <dib@dera.gov.uk> 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              ]

Pete Becker wrote (apropos Jerry Coffin's observation that properties can
naturally be encoded in C++ using objects):

> Yup. And if you do this through objects, then the containing class can
> end up with a half-dozen (perhaps, often many more) empty objects as
> members, inflating its size.

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?


Sincerely,

    David Bruce
________________________________________________________________________
post: DERA Malvern, St Andrews Road, Malvern, WORCS WR14 3PS, ENGLAND
mailto:dib@dera.gov.uk ** phone: +44 1684 895112 ** fax: +44 1684 894389
[The views expressed above are entirely those of the writer and do not represent the views, policy or understanding of any other person or official body.]




[ 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              ]