In article <306@dawes.win.net> beman@dawes.win.net (Beman Dawes)
writes:

|> In article <19940521.2332@naggum.no>, Erik Naggum (erik@naggum.no) writes:

|> >can I move that . be treated as -> when the left-hand argument is a pointer
|> >to a class?  could this be considered before the standard is cast in stone?

|> Ten years ago the deSmet C compiler did exactly that for pointers
|> to stucts.  It was quite a nice feature, IMHO.  I have wondered
|> several times if it would cause problems with C++ as defined today.

In the case of a class with an overloaded operator->(), both operators
are legal on the class, but with different semantics.
--
James Kanze                       email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <306@dawes.win.net> beman@dawes.win.net (Beman Dawes) writes:
>
>In article <19940521.2332@naggum.no>, Erik Naggum (erik@naggum.no) writes:
>
>>can I move that . be treated as -> when the left-hand argument is a pointer
>>to a class?  could this be considered before the standard is cast in stone?
>
>Ten years ago the deSmet C compiler did exactly that for pointers
>to stucts.  It was quite a nice feature, IMHO.  I have wondered
>several times if it would cause problems with C++ as defined today.

 Existing practice?

 I have a proposal sitting on my PC to add four new operations
to C++:

 1) add member to pointer yielding pointer : ptr . mem
  definition: ptr . mem = &(ptr->mem)

 2) add member to pointer to member yielding
  pointer to member  :  ptm . mem

 3) add pointer to member to pointer yielding pointer : ptr .* ptm

 4) add pointer to member to pointer to member yielding
  pointer to member  ptm .* ptm


All these operations just add an offset in the obvious way.

The problem adding (1) is basically the committee's attitude,
which is being influenced by the public's demand for a
Standard NOW! (not to mention a schedule). (1) is not
essential -- PROOF: have a look at its trivial one
line definition! (The fact that this makes the editorial
work of including the feature trivial does not
convince people programmers wont consider it "extra complexity").

The problem for (2) or (4) is different. This is a functional
deficiency in the language. There is no way to emulate
this functionality except by using unsafe hackery like
the 'offsetof' macro.

Unfortunately, a lot of committee members think pointers
to members are best forgotten, or at best do not rate
attention at this point in the Standardisation process.

Because of the priorites of the committee, I probably
wont bother even submitting the proposal.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <19940521.2332@naggum.no>, Erik Naggum (erik@naggum.no) writes:

>can I move that . be treated as -> when the left-hand argument is a pointer
>to a class?  could this be considered before the standard is cast in stone?

Ten years ago the deSmet C compiler did exactly that for pointers
to stucts.  It was quite a nice feature, IMHO.  I have wondered
several times if it would cause problems with C++ as defined today.

-- Beman

beman@dawes.win.net    Voice: (804) 787-8228  Fax: (804) 787-4323