Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!jarthur!uci-ics!rfg
From: rfg@ics.uci.edu (Ronald Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: The type yielded by "new T[expression]"
Message-ID: <26072ACA.7352@paris.ics.uci.edu>
Date: 21 Mar 90 07:18:34 GMT
References: <26068361.27247@paris.ics.uci.edu>
Reply-To: rfg@ics.uci.edu (Ronald Guilmette)
Organization: UC Irvine Department of ICS
Lines: 80

In article <26068361.27247@paris.ics.uci.edu> rfg@paris.ics.uci.edu (Ronald Guilmette) writes:
>I believe that there exists a ghastly violation of strong typing rules
>currently built into the C++ language.  I'd like somebody to explain
>this to me and defend it (if possible).

---------------------------------------------------------------------------
// This is a follow-up to my previous posting regarding new and delete
// on arrays.  The current situation is much worse that I thought.

// Consider the following simple program:

	extern "C" int printf (const char *, ...);

	class class0 {
	public:
	  class0 ();
	  ~class0 ();
	};

	class0::class0 () { printf ("constructor called\n"); }

	class0::~class0 () { printf ("destructor called\n"); }

	typedef class0 array_of_class0[];	// unknown dimension
	typedef class0 array_of_3_class0[3];	// known dimension

	array_of_class0 *p1;
	array_of_3_class0 *p2;

	int main ()
	{
	  //p1 = (array_of_class0 *) new array_of_class0;
	  p2 = (array_of_3_class0 *) new array_of_3_class0;

	  delete p1;
	  delete p2;

	  return 0;
	}

// The first invocation of "new" (i.e. the one commented out above) is
// clearly nonsensical and should be illegal.  There is no way for the
// compiler to know how big an array to allocate.

// Both cfront (2.0) and g++ (1.37.1) flag this as a error (if it is
// uncommented).  That's the good news.  The bad news is that I can't
// find where in the manual the illegality of such statements is documented.

// The second invocation of "new" is perfectly legal, and both cfront and
// g++ accept it.

// As I noted in my previous posting however, I don't feel that the cast
// should be necessary (but it currently is).  I prefer a simple rule
// that says that "new T" always yields a value of type "T*" regardless
// of whether or not type T happens to be an array type.

// When executed, the second invocation of "new" should print the string
// "constructor called" three times.  When compiled with cfront, this is
// exactly what happens.  When compiled with g++, the "constructor called"
// message is only printed once.  This is obviously a bug in g++.

// The two delete statements are both rejected by cfront 2.0.  It says:
// "error: delete of array of arrays".  This is clearly a bug in cfront.

// g++ rejects the first delete statement only, issuing the message:
// "invalid use of array with unspecified bounds".

// g++ accepts the second delete statement, but the run-time effects are
// not what you would expect.  Execution of this statement does not cause
// *any* "destructor called" messages to be printed.  In my opinion,
// execution of this statement should cause three "destructor called"
// messages to be printed.

// In my opinion, *both* delete statements should be legal C++.  Execution
// of the first delete statement should have the same effect as:
//
//		delete [] (class0 *) p1;

// Obviously, more work is needed on refining these points on the language
// definition.