🚀 go-pugleaf

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