Path: utzoo!mnetor!tmsoft!torsqnt!hybrid!scifi!bywater!uunet!world!wmm
From: wmm@world.std.com (William M Miller)
Newsgroups: comp.lang.c++
Subject: Re: Distinguishing lvalue/rvalue operator[]
Message-ID: <1991Mar4.031900.16827@world.std.com>
Date: 4 Mar 91 03:19:00 GMT
References: <1991Mar3.202134.17812@mathcs.sjsu.edu>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 57

horstman@mathcs.sjsu.edu (Cay Horstmann) writes:
> I recently suggested to distinguish lvalue and rvalue operator[] by
> passing in an additional int for one of them, just like pre- and
> post operator++ are distinguished in 2.1. Joe Buck suggested this is
> unnecessary--one can have operator[] return an access class with
>      X& Access::operator=( X& ); // for lvalue usage
>      Access::operator X(); // for rvalue usage
> I just tried this out and it broke my code right away. The line
>      a[i].print();
> didn't compile--print() is not a member function of Access!

So what's the big deal?  Just add an inline Access::print() member function
that forwards the call to X::print().  Admittedly, that could be a pain if
you're working with an X that has dozens of members (and, at least for
current compilers, there will be some runtime overhead involved in the
initialization of references to data members that are to be accessed
transparently), but I haven't seen anything you want to do that's
prohibitively hard or impossible to do in the current language.  In my
experience, this problem doesn't arise all that often, and if you do run
into it all the time, it would be pretty straightforward to program a filter
that automatically produced an Access class for a given X.

> I repeat my call for two versions of this operator. William Miller had three
> arguments against it.
> (1) There is an alternate solution.
>     I hope my argument against this is conclusive.

I don't think so.

> (2) It breaks existing code
>     Isn't it possible to map both lvalue and rvalue [] to the same
>     operator[](int) if an operator[](int,int) is not present?

Actually, my argument was not that it breaks existing code, only that it
would have to break existing code if it were made genuinely parallel with
the treatment of operator++(), and that making it different from
operator++() introduces a rather gratuitous additional complexity.  It's
certainly possible to treat it as you suggested; it is also possible to
change the definition of how operator++() is treated to work the same way.

> (3) It makes operator[] special.
>     I agree. On the other hand, it may well reasonable to have some operators
>     special. The assignment operator= is clearly special. So is operator->.
>     In fact, it probably makes sense to have both unary operator* and
>     operator[] lvalue/rvalue aware because their C analogs are. In contrast,
>     operator++ shouldn't have this awareness because the C analog doesn't
>     either.

I'm not sure what you mean by C analogs of operator[]() and unary
operator*() having "awareness" of lvalueness -- the C analogs always return
lvalues unconditionally; the results are only converted into rvalues when
used in a non-lvalue context.  On the other hand, the C++ operators like
operator++() do return lvalues or rvalues, depending on their use and
arguments.

-- William M. Miller, Glockenspiel, Ltd.
   wmm@world.std.com