In article <2u9lk1$klf@gomer.aldus.com>, Gary Powell <gary_powell@aldus.com> writes:
> Re: operator.()
>
> Ok if the author of the paper can't complain I will.
>   I assertain that the committee made a mistake in not allowing
>   overloading operator.().  As far as I can tell the reason for rejection
>   is that for a class foo such that:

I stopped supporting  operator.()  when I discovered that everyone who
proposed it meant something different by it.

Too bad, really.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
 (Training and consulting in C, C++, UNIX, etc.)

mat@mole-end.matawan.nj.us wrote:
: In article <2u9lk1$klf@gomer.aldus.com>, Gary Powell <gary_powell@aldus.com> writes:
: > Re: operator.()
: >
: > Ok if the author of the paper can't complain I will.
: >   I assertain that the committee made a mistake in not allowing
: >   overloading operator.().  As far as I can tell the reason for rejection
: >   is that for a class foo such that:

: I stopped supporting  operator.()  when I discovered that everyone who
: proposed it meant something different by it.

Yes.  Back when I thought it was a great idea I thought it should check
the 'current' class and then the forward class -- quite a bit more
than what I gather most people mean by it.

phil

In article <CrMIKK.Hst@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
| Everyone favoured a proposal that would provide
|smart references but the operator.() proposal did not.

This is clearly an error.  Operator.() does allow one to write
reasonable smart references.  Its just that the process of using
operator.() to help create those smart references doesn't happen
quite in the manner that some committee members suggest *should*
be the manner.  Rather than investigating the proposal for operator.()
*as it was made* they instead proposed *something different* and
then showed how *their* proposal failed to work.  This left the
original proposal effectively unconsidered.

>>>>> "J" == Jim Adcock <jimad@microsoft.com> writes:

J> Operator.() [as proposed by Adcock] does allow one to write
J> reasonable smart references.  Its just that the process of using
J> operator.() to help create those smart references doesn't happen
J> quite in the manner that some committee members suggest *should* be
J> the manner.

I suppose "doesn't happen in the manner that should be the manner" is
a reasonable definition of unreasonable.  Ok, we disagree; so what?

J> Rather than investigating the proposal for operator.()
J> *as it was made* they instead proposed *something different* and
J> then showed how *their* proposal failed to work.  This left the
J> original proposal effectively unconsidered.

Says the author of the original proposal!  It seems to be common that
the author of a paper claims that X never read it, or that X didn't
study it seriously, rather than admit that X was not impressed by the
argumentation in that paper.

You can argue that I (as one of the X's) should have done a better job
reading the paper, or that Jim Adcock should have done a better job
writing the paper, but you cannot argue that the proposal was not
considered.
    -- Dag Bruck

Re: operator.()

Ok if the author of the paper can't complain I will.
  I assertain that the committee made a mistake in not allowing
  overloading operator.().  As far as I can tell the reason for rejection
  is that for a class foo such that:

class foo {
public:
    foo();
    ~foo();
    operator.();
    setValue(char *x) : fcpValue(x) {};
    operator=(const char *);
private:
    char * fcpValue;
};

That a user of the class

fn()
{
    foo f;
    char cpTemp[] = { "Temp String};


    f.setValue(cpTemp)   // Cannot be accessed except thru operator.()
}


I however contend that the only place that the member fn setValue()
should be called is from a another member fn. ie:

foo::operator=(const char * ccpX)
{
     setValue(ccpX);
}

And that the purpose of creating a class which overloads operator.() is
not to have a "class" in the usual C++ sense but to hide some @#$%T^
feature of the platform you are using, ie on the MacInstosh memory is
accessed thru handles, requireing code to be written like this:

gn()
{
    WindowHandle hndl = (WindowHandle) NewHandle (sizeof (WindowObj));

    (*hndl)->value = 8;   // or some such assignment.
}

Since I try to write cross platform code for my company I want to treat
memory as direct access;

hn()
{
     WindowPtr wObj;     // Too much stuff on the stack and you are dead
                         // under Windows(tm)

     wObj.value = 8;     // The same on a UNIX platform. (When I really
                         // have a handle to a piece of memory.)
}

Instead I have a bunch of MACRO's which hide the memory allocation scheme
which is what I don't want for all the obvious reasons.

I think the committee doesn't write code for MAC's and Windows(tm) and
UNIX
platforms (core code) or they too would get sick of this and allow a
smart pointers
which overloaded operator.()


Bjarne is right I can do without the help of the language, after all I
am writing code now, and it works. It just that when the opportunity to
fix something which is wrong comes along I want to fix it. Not allowing
overloading of operator.() is just such a case.

Will I drop the use of C++ because I can't overload operator.()? Nope. It
is still way better than C. Do I hope that the vendors give us this
feature, you bet I do. How long will I have to wait? Maybe a couple of
years, so until then I will be quietly swearing in my cube coding away.

As for the argument that this can be abused, well, trust us, we are
after all, adults and can handle it. Trying to prevent
abuse by restricting overloading is a lost cause. Better to write
articles in C++ Report on techniques to do it right.

   -Gary-
Gary Powell  | Internet: gary.powell@aldus.com
411 1st Ave S.  | Tel:   (206) 622-5500
Seattle, WA 98104 |

In article <2so4c9$23q@news.bridge.com> rodb@bridge.com (Rod Burman) writes:
|John Max Skaller (maxtal@physics.su.OZ.AU) wrote:
|: In article <damian.770613944@bruce.cs.monash.edu.au> damian@cs.monash.edu.au (Damian Conway) writes:
|: >At the risk of reopening old wounds, may I have definitive answers to the
|: >following questions:
|: >
|: >1. Has the committee ever considered a formal proposal to allow overloading of
|: >   operator.()?
|
|:  Yes.

FWIW I wrote up the proposal to the committee some 4-5 years ago. Prior
to that, during review of the ARM rought drafts, I noted that the ARM stated
reasons for disallowing operator.() didn't make sense in the presence
of overloadable unary operator&()

My proposal for overloadable operator.() was simply that there was no
good reason to disallow this one particular operator, among all others
[ including such obscurities such as operator->*() ] and that given an
already existing definition for allowing "smart pointers" using
operator->(), a completely analogous and orthogonal implementation
of operator.() follows for "smart references" [and other handle classes.]
Of course, those who don't believe in orthogonal language design, but who
believe everything in a language should be designed piece-meal and
special case, don't buy this orthogonality argument....

|: >2. If so, on what grounds was it rejected?
|
|:  After long discussions, it was rejected because it was
|: not felt worth the effort and risk. That is, few on the extensions
|: committee felt it was certainly a good thing to add. Given
|: the doubts, extensions are generally rejected.

To anyone who tries to write a templated general purpose handle
class, the utility is obvious.  Anyone at all interested in this
subject should try writing such a class with and without operator.().
Without operator.() no such general purpose template handle class is
possible -- unless you invent new syntax, in which case you can
just erroneously use operator->() to represent forwarding.
Certainly without operator.() one cannot write *both* templated
"smart pointer" classes *and* "smart reference" classes.

|In his book The Design and Evolution of C++, Bjarne Stroustrup discusses this
|(pagee 242-5) and say he is dis-inclined to lend support because if you define
|operator. to work in the intuitive manner it must work on the implicit uses of
|. as well as the explicit ones, e.g for a class T with an operator.
|and objects t0 and t1 then:
|
| t0 = t1 is t0.operator=(t1) is t0.operator.().operator=(t1)
|      ^this . not expanded to stop recurssion
|
|i.e. for all operators except . you must call operator.() first (I think this
|is what he is saying, it applies explicitly to members, i.e. you can see the .
|is
| t0.fnc() and t1.data
|
|No this leads to two problems
| 1) it breaks the equivalence of a.m and (&a)->m

This equivalence was already broken with the introduction of overloadable
unary operator&() and operator->(), thus this cannot argue against
operator.()

| 2) you can't get at members of the actual "Smart reference" class

This statement is in error, as one quickly finds if one writes a class
using operator.().  Within the class one almost always accesses members
using "implied this", the '.' syntax is not used, and the problem is
simply not an issue.  In those obscure cases where one insists on explicitly
specifying the non-this target object, then good choices still exist
to how to get to that target object.  Its really not a problem.

In summary I continue to believe the committee members arguing against
this proposal made simple errors in their arguments, and thus the
decisions of the committee made on their recommendations were made
in error.

|Disclaimer: these are MY opinions not my employers, etc

Ditto

In article <CqzMzL.DrE@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

 ... operator.() ..

>In summary I continue to believe the committee members arguing against
>this proposal made simple errors in their arguments, and thus the
>decisions of the committee made on their recommendations were made
>in error.

 It doesnt work that way. No arguments against the proposal
were required. It is up to the proposer to convince those making
a decision. In this case, despite lengthy prior arguments,
none of the members of the extensions subgroup were convinced that
THEY could convince the committee as a whole. Only one
person did not vote to reject the proposal -- me. I abstained
because I was not present at previous discussions. I basically
thought the symmetry argument was the strongest. I'm now
proposing to ban overloading operator&. :-)

 Everyone favoured a proposal that would provide
smart references but the operator.() proposal did not.
Bjarne investigated a proposal that did but found it
too hard to use. My proposal to use

 using *member;

to do it is unlikely to be written up because its unlikely
to be accepted at this stage of the process. So we'll have to
live without smart references. Smart pointers dont really work
either.

--
        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 <1994Jun7.185542.24912@ed8200.ped.pto.ford.com> haubert@ed8200.ped.pto.ford.com (Phil Haubert) writes:
>>maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>>       class X  {
>>               Y *y;
>>               using *y; // I have suggested
>>       };
>

 Note: I have not written an actual proposal and it would
probably not be accepted at this time even if it were perfect.

>If I understand this correctly, it is conditional forwarding with
>class members preferred over those of the class forwarded to.

 Yes. I think so. This allows you to "override"
which ever of the delegated methods is not appropriate.

>
>1) Is there a private/protected version or just public?

 Should depend on the location of either the member
or the using statement. (Probably the latter, not sure).
Naturally protection of the delegated to
class (Y above) has to be observed.

>
>2) Are multiple usings allowed in an inheritance hierarchy?

 Sure. Multiple usings in the one class!
>
>3) Are the forwardings transitive?

 Yes.
>
>4) What ambiguity resolution is necessary?

 I think like the rest of C++ the lookup is name
(not signature) based. So there cant be any new ambiguities
between the boss and the delegate: the delegate (Y) only responds
if the boss (X) doesnt. (And the delegate is prefered to the parent)

 Ambiguity resolution between MULTIPLE usings in the
one class, however, will be required.  If two delegates in
the SAME class have an f and f is called/accessed its ambiguous.
(Per  name: f(int) and f(long) are ambiguous -- as if
the delgates were bases)

In addition, inheritance of delegation is required.

>
>5) What is the search order in the presence of multiple inheritance,
>   virtual inheritance, multiple forwardings, etc.

Do you search normally then for delegates? Or do you search
search the class normally then for delegates before searching bases?

Method 1 implies a base class method hides a delegated method
in a derived class permanently. No good.

Method 2 implies a delegated method hides a base method.

 struct Y { virtual void f(); };
 struct B { void f(); };
 struct X : B { Y* y; using y;};
 X x; x.f();

Here the delegate X::y->f() is prefered over the "inherited"
base method B::f() which it hides. However, a dispatch through
the base:

 B* b = &x;
 b->f();

calls b->B::f() not b->X::y->Y::f(). This could be changed so that
in fact a delgate can override a virtual function. Dont know.
In that case b->f() would call the delegate.
What do you think?

Actually -- the latter is more "natural" because it can be viewed
as "injecting" wrapper functions for the delegate automatically.
however that conflicts with the notion that such wrappers are
hidden by class methods .. no it doesnt :-) The wrapper simply
isnt generated in these cases. no thats no good either:
virtuals override on a signature basis. Hiding is on a name basis.

This would need more work. It looks good but since its unlikely
to be approved I dont know if its worth the effort.

>
>6) Can you proxy a namespace? (no object would be associated)

 No.

--
        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 <damian.770682681@bruce.cs.monash.edu.au> damian@cs.monash.edu.au (Damian Conway) writes:
>maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>>If you want to participate in the discussion and influence
>>the decision makers now is your chance. SAY SOMETHING
>>(or stop complaining that the committee isnt accessible to the public:
>>I've done what I can to make it more acessible, its your urn
>>to contribute now)
>
>I take it this is directed to the audience in general as I have never
>complained of the lack of accessibility of the committee.

 Yes, I apologise for wording that is such a way as may
have been construed as directed at you personally, Damien.
Some people have complained about lack of public access -- me, for example!
I think those complaints are partly justified, and I will do what
I can to provide information.

>Indeed it amazes me
>how much time, patience and restraint they lavish on the c++ newsgroups.

 In my case it is not entirely "altruism". I provide
information to this forum because I get valuable information
and insights back from other contributors.

 For example someone fairly recently posted a proper
solution to the template specialisation problem using inheritance
notation -- please contact (my mail box gets scrubbed regularly
due to lack of disk space). There is no chance of the committee
accepting it, but it worked and nothing else actually does. :-)
>
>>>damian,
>>>(very much in need of operator.())
>
>> Why?
>
>Smart references and cleaner iterators.

 Yes, I understand that but why operator.()?
There are two other possible solutions I know of:

 class X : public Y *y { .. } // Bjarne has tested and rejected
 class X  {
  Y *y;
  using *y; // I have suggested
 };

and BOTH these solutions work better as a smart reference than
operator.(), which requires an explicit . to be written: it
doesnt work with operators or parameter passing.
(At least that is the final proposal by Jim Adcock that the
extensions group considered).


 I suspect a REAL smart reference requires a lot more
extension than merely syntax. For example operator->
does not work properly as a smart pointer which, say,
loads an object from disk if its not in memory(you can do that)
and also discards it when not needed or memory gets low
(thats a bit harder).

 I think the old C++ "do before" "do after" that was
dropped is what might actually be needed. I dont know.
Its kind of hard to experiment without a compiler you can
modify. Its also hard for the committee to add an extension
that isnt supported with some experience. Catch-22.


--
        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 <770922786@amazon.cs.duke.edu> dsb@duke.cs.duke.edu (Scott Bigham) writes:
>
>You are writing a templated container class in the shape of an array.
>To avoid the possibility of dangling references, your operator[] returns
>a proxy class, as described by Coplien and others:
>
>Since T might be a pointer type, you add the member function
>Array<T>::ArrayProxy::operator->().  But what if T is a class type?
>
>    struct fred {void member_fn();};
>
>    void f(Array<fred> &A)
>    {
> A[0].member_fn(); // "error:  no member function
>     //  Array<fred>::ArrayProxy::member_fn()"
>    }
>
>The obvious thing to do here is overload operator.() in the same way as
>operator->().

 Nope. Both Bjarnes idea and mine handle that.
If member_fn() cant be found in the Proxy, lookup what it "proxies"
for. The problem is that operator.() doesnt handle:

 f(A[0]);
 A[0] + A[1];

which require a smart reference: but there is no "." there
so operator.() is not invoked**. On the other hand both
Bjarne's proposal and mine handle that. (operator+ is looked up
in Proxy, then "fred", and I suppose globals taking a fred would
have to be searched for too.


** according to the rules for operator.() layed down by Jim Adcock.

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

>maxtal@physics.su.OZ.AU (John Max Skaller) writes:

>       class X  {
>               Y *y;
>               using *y; // I have suggested
>       };

I like this syntax, reminiscent of namespaces. A couple questions:

If I understand this correctly, it is conditional forwarding with
class members preferred over those of the class forwarded to.

1) Is there a private/protected version or just public?

2) Are multiple usings allowed in an inheritance hierarchy?

3) Are the forwardings transitive?

4) What ambiguity resolution is necessary?

5) What is the search order in the presence of multiple inheritance,
   virtual inheritance, multiple forwardings, etc.

6) Can you proxy a namespace? (no object would be associated)

-phil

At the risk of reopening old wounds, may I have definitive answers to the
following questions:

1. Has the committee ever considered a formal proposal to allow overloading of
   operator.()?

2. If so, on what grounds was it rejected?

3. If it was rejected on the grounds specified in the ARM (namely: existing
   meaning for all objects), will overloading of the unary & operator be
   prohibited?

damian,
(very much in need of operator.())

John Max Skaller (maxtal@physics.su.OZ.AU) wrote:
: In article <damian.770613944@bruce.cs.monash.edu.au> damian@cs.monash.edu.au (Damian Conway) writes:
: >At the risk of reopening old wounds, may I have definitive answers to the
: >following questions:
: >
: >1. Has the committee ever considered a formal proposal to allow overloading of
: >   operator.()?

:  Yes.
: >
: >2. If so, on what grounds was it rejected?

:  After long discussions, it was rejected because it was
: not felt worth the effort and risk. That is, few on the extensions
: committee felt it was certainly a good thing to add. Given
: the doubts, extensions are generally rejected.

: >3. If it was rejected on the grounds specified in the ARM (namely: existing
: >   meaning for all objects), will overloading of the unary & operator be
: >   prohibited?

:  I have proposed banning overloading unary operator&.

In his book The Design and Evolution of C++, Bjarne Stroustrup discusses this
(pagee 242-5) and say he is dis-inclined to lend support because if you define
operator. to work in the intuitive manner it must work on the implicit uses of
. as well as the explicit ones, e.g for a class T with an operator.
and objects t0 and t1 then:

 t0 = t1 is t0.operator=(t1) is t0.operator.().operator=(t1)
      ^this . not expanded to stop recurssion

i.e. for all operators except . you must call operator.() first (I think this
is what he is saying, it applies explicitly to members, i.e. you can see the .
is
 t0.fnc() and t1.data

No this leads to two problems
 1) it breaks the equivalence of a.m and (&a)->m
 2) you can't get at members of the actual "Smart reference" class

To 1) he (Bjarne) says so what? Bascially because we've already broken loads
of "equivalences" in C++ e.g. "t0 = t0 + t1" == "t0 += t1;" for builtin types
but not NECCESARILY for user classes, here I agree with him (not that he needs
my support)

On 2) surely all we need is some syntax to allow us to get at the smart ref
class say class s_ref with member void bind(T& t), can't we do this with "::"
say:
 s_ref sr;
 sr.bind(t);  // is sr.operator.().bind(t)
but we want
 s.s_ref::bind(); // this would stop the above conversion?
should we also be able to say things like:
 t0 Type::= t1;  // use Type::operator() -- if possible/appropriate

My vote is for orthogonality, i.e. we should if at all possible allow definitions
of operators . .* and :?, why not? If it doesn't cost me as long as I don't use
it? and doesn't open any holes in the type system (this I think is the real reason
the committee is "afraid" of operator.) After all neither ./.* nor :? would break
existing code or add new keywords the usual reasons for disallowing proposals :-)
This would leave :: and sizeof as the only un-overloadable functions, though I
think now we have bool, we could pacify pascal lovers even more by importing
bitsize -- that might even help with portability...
 Hope this makes sense I'm no language lawyer just a user...
  thanks for you attention Rod

Disclaimer: these are MY opinions not my employers, etc

maxtal@physics.su.OZ.AU (John Max Skaller) writes:

>>3. If it was rejected on the grounds specified in the ARM (namely: existing
>>   meaning for all objects), will overloading of the unary & operator be
>>   prohibited?

> I have proposed banning overloading unary operator&.
>The proposal was posted to this newsgroup a few days ago.
>Please READ it and say what you think. FYI the document
>number of the proposal is:

> ANSI/X3J16: 94-0114
> ISO/WG21: N0501
> "The ADDRESS-OF OPERATOR"
> John MAX Skaller
> maxtal@suphys.physics.su.oz.au

>If you want to participate in the discussion and influence
>the decision makers now is your chance. SAY SOMETHING
>(or stop complaining that the committee isnt accessible to the public:
>I've done what I can to make it more acessible, its your urn
>to contribute now)

I take it this is directed to the audience in general as I have never
complained of the lack of accessibility of the committee. Indeed it amazes me
how much time, patience and restraint they lavish on the c++ newsgroups.

>>damian,
>>(very much in need of operator.())

> Why?

Smart references and cleaner iterators.

damian

>>>>> "Max" == John Max Skaller <maxtal@physics.su.OZ.AU> writes:

Max> In article <damian.770613944@bruce.cs.monash.edu.au>

Damian>>  damian, (very much in need of operator.())

Max>  Why?

Smart refs. I'd love to be able to, say, check that an object's state
is valid without instrumenting every single function. I could do
things like insure that objects of a given class have no dangling
referances, which I don't think is possible within C++ now.

 Hayden
--
Hayden Schultz
haydens@ll.mit.edu
MIT Lincoln Lab
244 Wood St.
Lexington, MA, 02173
(617) 981-3685

In article <damian.770613944@bruce.cs.monash.edu.au> damian@cs.monash.edu.au (Damian Conway) writes:
>At the risk of reopening old wounds, may I have definitive answers to the
>following questions:
>
>1. Has the committee ever considered a formal proposal to allow overloading of
>   operator.()?

 Yes.
>
>2. If so, on what grounds was it rejected?

 After long discussions, it was rejected because it was
not felt worth the effort and risk. That is, few on the extensions
committee felt it was certainly a good thing to add. Given
the doubts, extensions are generally rejected.

>3. If it was rejected on the grounds specified in the ARM (namely: existing
>   meaning for all objects), will overloading of the unary & operator be
>   prohibited?

 I have proposed banning overloading unary operator&.
The proposal was posted to this newsgroup a few days ago.
Please READ it and say what you think. FYI the document
number of the proposal is:

 ANSI/X3J16: 94-0114
 ISO/WG21: N0501
 "The ADDRESS-OF OPERATOR"
 John MAX Skaller
 maxtal@suphys.physics.su.oz.au

If you want to participate in the discussion and influence
the decision makers now is your chance. SAY SOMETHING
(or stop complaining that the committee isnt accessible to the public:
I've done what I can to make it more acessible, its your urn
to contribute now)

The same proposal proposes allowing rvalues (temporaries)
to have their addresses taken: my support for banning
overloading operator& is contingent on that.
>
>damian,
>(very much in need of operator.())

 Why?

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