Ok... I'm new at this business, so this should be easy for some of the experts
out there.

I know about operator overloading and I can implement it to some degree without
consulting the manuals too much, but I'm stuck on this one:

    a[1]=x;

Ok.  "a" is an object that I have created and I've overloaded the [] operator
to allow me to return a value at position "1" (in this case) from my object.
However, in this case, I'm not needing output, I'm trying to _assign_ a value
to that position.  I know how to overload the "=" operator, but _how_ do you
do _both_ operators at the same time?

Perplexed++
(any ideas?)
e-mail me if you have an answer!  This one's been bugging me.
 - Brad
--
 Disclaimer: "I really don't care."

 |) |) /\ |\  | Brad S. Choate                      | 1314 E. Market, Apt. 6
 |) |\ || |/  |                                     | Searcy, AR  72143
 --------_--  | choate@acs.harding.edu              | (501) 279-2584
  <||()/\|[   | V.P., Software Extensions, Inc.

In <1992Jul21.144856.583@ualr.edu> choate@acs.harding.edu (Brad S. Choate) writes:

*****> For starters, this type of question belongs in comp.lang.c++.

>Ok... I'm new at this business, so this should be easy for some of the experts
>out there.

>I know about operator overloading and I can implement it to some degree without
>consulting the manuals too much, but I'm stuck on this one:

>    a[1]=x;

>Ok.  "a" is an object that I have created and I've overloaded the [] operator
>to allow me to return a value at position "1" (in this case) from my object.
>However, in this case, I'm not needing output, I'm trying to _assign_ a value
>to that position.  I know how to overload the "=" operator, but _how_ do you
>do _both_ operators at the same time?

*****> operator= has got nothing to do with it unless the thing that []
 returns is itself a class object (in which case operator= would
 be overloaded in _that_ class--whether operator= is overloaded
 in _this_ class is irrelevant...unless you're doing something
 non-canonical).  operator[] should return a reference to the
 thing...that's it; the assignment just happens.

  class IntVect {
   int *v;
  public:
   // ...
   int &operator[]( int i ) { return v[i]; }
  };

 This is a naive example in that it doesn't do bounds-checking nor
 automatic "growing."
--
 - Paul J. Lucas    University of Illinois
   AT&T Bell Laboratories  at Urbana-Champaign
   Naperville, IL   pjl@cs.uiuc.edu

In article <1992Jul21.232959.13540@sunb10.cs.uiuc.edu> pjl@sparc1.cs.uiuc.edu (Paul Lucas) writes:
|*****> operator= has got nothing to do with it unless the thing that []
| returns is itself a class object (in which case operator= would
| be overloaded in _that_ class--whether operator= is overloaded
| in _this_ class is irrelevant...unless you're doing something
| non-canonical).  operator[] should return a reference to the
| thing...that's it; the assignment just happens.

The overloading of operator= becomes relevant IF some committee members
succeed in changing the language such that functions cannot be invoked
on temporaries.  Then the common approach of returning a SmartRef from
operator[] fails:

bitarray[100] = TRUE; // code in error if functions cannot
                      // be invoked on temporaries!

because this really means:

bitarray.operator[](100).operator=(TRUE);

where operator[] is returning a temporary SmartBitRef that in turn has
its operator= on it.

In <1992Jul23.012111.16784@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

>In article <1992Jul21.232959.13540@sunb10.cs.uiuc.edu> pjl@sparc1.cs.uiuc.edu (Paul Lucas) writes:
>|*****> operator= has got nothing to do with it unless the thing that []
>| returns is itself a class object (in which case operator= would
>| be overloaded in _that_ class--whether operator= is overloaded
>| in _this_ class is irrelevant...unless you're doing something
>| non-canonical).  operator[] should return a reference to the
>| thing...that's it; the assignment just happens.

>The overloading of operator= becomes relevant IF some committee members
>succeed in changing the language such that functions cannot be invoked
>on temporaries.

 Why do they want to do that?  If I want to call functions on
 temporaries, that's my business (and I accept any consequences).
 I think that compiler warnings are sufficient.
--
 - Paul J. Lucas    University of Illinois
   AT&T Bell Laboratories  at Urbana-Champaign
   Naperville, IL   pjl@cs.uiuc.edu

In article <1992Jul23.154922.26676@sunb10.cs.uiuc.edu> pjl@sparc11.cs.uiuc.edu (Paul Lucas) writes:
| Why do they want to do that?  If I want to call functions on
| temporaries, that's my business (and I accept any consequences).
| I think that compiler warnings are sufficient.

Remember, if you say that warning are sufficient, then you are also saying
that not having warnings is sufficient, because warning represent a compiler
implementation, not a language specification.  Errors are part of the language,
warnings are implementation specific.

Why would they not allow functions on temporaries?  Beats me, but someone
is proposing this.  I don't know the details.  Perhaps it relates to all
the committee discussions about trying to invent special case rules for
handling the lifetimes of temporaries?   As opposed to handling the lifetimes
of temporaries just like all other objects?

In <1992Jul27.193701.6815@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

>In article <1992Jul23.154922.26676@sunb10.cs.uiuc.edu> pjl@sparc11.cs.uiuc.edu (Paul Lucas) writes:
>| Why do they want to do that?  If I want to call functions on
>| temporaries, that's my business (and I accept any consequences).
>| I think that compiler warnings are sufficient.

>Remember, if you say that warning are sufficient, then you are also saying
>that not having warnings is sufficient, because warning represent a compiler
>implementation, not a language specification.  Errors are part of the language,
>warnings are implementation specific.

 True.  Perhaps the inclusion of warnings (and the ability to
 selectively turn them off) is what will differentiate vendor X's
 compiler from vendor Y's.  People could put this down on their
 requirements list when shopping for a compiler; if a vendor's
 compiler isn't robust, they could shop elsewhere.  Marketing by
 word-of-mouth will hopefully prod compiler vendors to include
 warning also.

>Why would they not allow functions on temporaries?  Beats me, but someone
>is proposing this.  I don't know the details.  Perhaps it relates to all
>the committee discussions about trying to invent special case rules for
>handling the lifetimes of temporaries?   As opposed to handling the lifetimes
>of temporaries just like all other objects?

 Hello?  Anybody on the comittee want to answer this?
--
 - Paul J. Lucas    University of Illinois
   AT&T Bell Laboratories  at Urbana-Champaign
   Naperville, IL   pjl@cs.uiuc.edu