[comp.lang.c++] ++ bug ?

levitte@garbo.bion.kth.se (Tommy Levitte) (10/14/89)

A few articles ago, somebody talked about extending C++ with the operators ++@
and @++ . I didn't understand the use of it, thinking C++ handled it the right
way anyway.

I wanted to check, though, and made the following test:

// ----------8<-------------------------------------------
#include "stream.h"

class complex
{
	int Re,Im;
public:
	complex() {this->Re=0; this->Im=0;}
	complex(int Re) {this->Re=Re; this->Im=0;}
	complex(int Re,int Im) { this->Re=Re; this->Im=Im;}
	complex operator=(int i) { this->Re=i; this->Im=0; return *this;}
	complex operator++() { return *this=*this+1; }
	complex operator+(int i) { return complex(this->Re+i,this->Im); }
	int re() { return this->Re; }
	int im() { return this->Im; }
};

ostream& operator<<(ostream& foo,complex& bar)
{
  return foo << "(" << bar.re() << "," << bar.im() << ")";
}

main()
{
	complex h,i,j,k;

	h=i=1;
	j=h++; cout << j << " " << h << "\n";
	k=++i; cout << k << " " << i << "\n";
}

//----8<-------------------------------------------------------------

This was compiled (translated, I mean) by AT&T C++ version 1.2 .
The output is the following :

   (2,0) (2,0)
   (2,0) (2,0)


Now, my question is : Is this a bug in version 1.2 or should C++ act like
that ???? It looks like use implemented operator++ always behaves like ++v,
even when you have written v++ !!!!!!

With a "normal" behaviour, the output should be :

   (1,0) (2,0)
   (2,0) (2,0)


Does anybody have an explanation to this ???

Tommy Levitte 
	gizmo@nada.kth.se
	gizmo@kicki.stacken.kth.se
	gizmo@ttt.kth.se
--
Tommy Levitte 
	gizmo@nada.kth.se
	gizmo@kicki.stacken.kth.se
	gizmo@ttt.kth.se

jima@hplsla.HP.COM (Jim Adcock) (10/17/89)

It is well documented almost everywhere that when overloading pre/post inc/dec
that C++ does not distinguish between pre and post.  Hence the discussion
on @++ vs ++@

bitbug@chaya.sun.com (James Buster) (10/20/89)

In article <6590302@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
>It is well documented almost everywhere that when overloading pre/post inc/dec
>that C++ does not distinguish between pre and post.  Hence the discussion
>on @++ vs ++@

In "The C++ Programming Language, by Bjarne Stroustrup", on page 171, it says:

	"When the operators ++ and -- are overloaded, it is not possible to
	distinguish prefix application from postfix application"

I interpreted this to mean that the *member function* cannot distinguish
between prefix and postfix application, but that the compiler will ensure
that the member function will be called at the appropriate time (vis' a vis'
prefix or postfix application). I believe that this is the most reasonable
thing to do.

--------------------------------------------
	     James Buster
	Mad Hacker Extraordinaire
       bitbug@lonewolf.ebay.sun.com
	 bitbug%lonewolf@sun.com
	 sun.com!lonewolf!bitbug
--------------------------------------------
--------------------------------------------
	     James Buster
	Mad Hacker Extraordinaire
       bitbug@lonewolf.ebay.sun.com

sakkinen@tukki.jyu.fi (Markku Sakkinen) (10/20/89)

In article <126542@sun.Eng.Sun.COM> bitbug (James Buster) writes:
-In article <6590302@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
->It is well documented almost everywhere that when overloading pre/post inc/dec
->that C++ does not distinguish between pre and post.  Hence the discussion
->on @++ vs ++@
-
-In "The C++ Programming Language, by Bjarne Stroustrup", on page 171, it says:
-
-	"When the operators ++ and -- are overloaded, it is not possible to
-	distinguish prefix application from postfix application"
-
-I interpreted this to mean that the *member function* cannot distinguish
-between prefix and postfix application, but that the compiler will ensure
-that the member function will be called at the appropriate time (vis' a vis'
-prefix or postfix application). I believe that this is the most reasonable
-thing to do.

Unfortunately, your interpretation is wrong.
A longer reflection will show that "calling at the appropriate time"
would not be quite enough.
There was a longer explanation in my article referred to in the header;
I assume you had not seen it when posting yours.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland