From 7772857028927431056 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,8366734ec6aad121 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1994-06-15 10:53:21 PST Path: nntp.gmd.de!Germany.EU.net!netmbx.de!zib-berlin.de!informatik.tu-muenchen.de!schuenem From: schuenem@Informatik.TU-Muenchen.DE (Ulf Schuenemann) Newsgroups: comp.std.c++ Subject: Re: new foo[0] Date: 15 Jun 1994 17:52:10 GMT Organization: Technische Universitaet Muenchen, Germany Lines: 67 Distribution: world Message-ID: <2tnf4a$cev@hpsystem1.informatik.tu-muenchen.de> References: <2tk0dq$6ej@hpsystem1.informatik.tu-muenchen.de> <2tn7pc$9v0@hpsystem1.informatik.tu-muenchen.de> NNTP-Posting-Host: hpbroy5.informatik.tu-muenchen.de Originator: schuenem@hpbroy5.informatik.tu-muenchen.de > Say that "TPA pa" declares a pointer to an array of Ts. The difference to > conventional pointers "T *p" would be: > ... I would like to correct myself: pa = new T - illegal: pa must point to an array, new T isn't ^^ (not ps) delete - illegal: pa(!=NULL) points to an array, not just one object And I would like to add another rule for TD being derived from T: pa = new TD[i] - illegal, as there is no runtimeinfo for how to address pa[1] C/C++ calulates offsets into arrays statically. So &(p[1]) is always the same as (p+sizeof(T)). But with subtyping p can point to an object of derived class TD that is bigger than sizeof(T). Then with p = new TD[2] p[1] will not refere to the second object in the array, but to some address after the baseobject inside p[0] ! This may be especially painfull if delete[] calls the destructors of T with the this-pointer pointing to something that is not a (subobject-) T. If we do not want undefined behavior and not want to forbid "pa = new TD[i]", i.e. if we want to correctly refere to the objects in an array, the offset has to be calculated at runtime with the size of the objects curretenly in the array. This information can be retrieved somehow via the dynamic type of the first element in the array for classes (current RTTI) OR if new[] not only stored the number of elements in an array, but also info about the size of the objects currently in the array. To not break existing code, and because it requires a pointer to the beginning of the array, runtime-offset-calculation should only be performed for indexing of pointer-to-array TPA (however TPA looks like in concrete syntax) Then we could circumvent the constraint described below by using a TPA p instead of a T*p: [In "Re: ANSI draft bug and subsequent compiler bugs" Schwarz = jss@lucid.com (Jerry Schwarz) wrote:] Schwarz> Schwarz> When you delete an array the (static) type of the pointer must be that Schwarz> of the actual type of the array objects. In other words if you do Schwarz> Schwarz> delete [] p ; Schwarz> Schwarz> where p has type "pointer to T". Then p must originally have been Schwarz> allocated with Schwarz> Schwarz> new T[...] ; Schwarz> Schwarz> This constraint is imposed so that the compiler knows how large Schwarz> the elements of the array are and what destructor to call on Schwarz> them is. Schwarz> Schwarz> It is true that the system could be required to stash away this Schwarz> information (and since RTTI has been added to the language it will be Schwarz> required to) and use it at the delete, but the current working paper Schwarz> does not impose that overhead on runtime systems. Schwarz> Schwarz> I don't know if there is a proposal before the committee to change Schwarz> this requirement. Schwarz> Schwarz> -- Jerry Schwarz(jss@lucid.com)