🚀 go-pugleaf

// When following program is compiled by g++ version 2.2.2 on a SUN4
// (SPARCstation IPX, running SunOS 4.1.2) with the command
//
//       g++ test.cc
//
// no error messages occur, although some nasty things happen to
// unsuspecting constant objects.
//
//
// First we have a small class definition:


class A {
public:
  A (int a = 0) {}
};


// Second we make a type definition (the usefulness of which will become
// evident later):


typedef A type;                     // (***); see below


// Next we define some variables and functions returning constant and
// non-constant objects by value as well as by reference and by pointer:


      type	var;
const type	cvar	= type (0);

      type	func	() {return var;}
const type	cfunc	() {return cvar;}
const type     &crfunc	() {return cvar;}
const type     *cpfunc	() {return &cvar;}


// Besides the assignment operator there are two ways to manipulate objects,
// namely by passing them to functions by reference or by pointer. We define
// some functions in the following (they do manipulate their arguments,
// although this is not visible outside their scope):


void takeref	(type &r) {r = type (0);}
void takeptr	(type *p) {*p = type (0);}


// Now the actual program starts. Although constant and/or temporary
// objects are manipulated, the compiler happily finishes its work
// without warning the astonished user at all:


main () {

  takeref (crfunc ());		//           constant object  (1)
  takeref (*cpfunc ());		//           constant object  (2)
  takeref (cfunc ());		// temporary constant object  (3)
  takeptr (&cfunc ());		// temporary constant object  (4)
  cfunc () = cvar;		// temporary constant object  (5)
  takeptr (&func ());		// temporary          object  (6)
  takeref (func ());		// temporary          object  (7)
  func () = cvar;		// temporary          object  (8)

}


// However, if you change the above type definition (***) to
// 
// typedef int type;
// 
// the compiler issues warnings: "invalid lvalue in unary `&'" (to state-
// ments (4) and (6) ) and "invalid lvalue in assignment" (to (5) and (8)).
// 
//
// As occurring quite often, statements number (1) and (2) puzzled me
// first and made me investigate all possible ways of object manipulation.
// Besides the above listed examples I did not find any suspicious ones
// without a compiler warning.
//
// Staments number (1) and (2) are compiler bugs in my opinion, because they
// would enable you to change any constant you like very easily. I am not
// quite sure if numbers (3) to (8) are allowed by the C++ language or simply
// not very sensible (apart from possible side effects of 'takeref' and
// 'takeptr'). (3) to (5) seem to be worthy of a warning, though. Also note
// that the assignment operator '=' is *not* overloaded for class A.
// I would be glad if anybody could give some information about that topic.
// 
// ------------------------------------------------------------------------
// Thomas Sudbrak,  <thomas.sudbrak@gmd.de>   Phone : +49/2241/14-2493 )
// German National Research Center for Computer Science (GMD), I3.KI
// P.O. Box 1316, W-5205 St. Augustin 1, Germany