sking@nowhere.uucp (Steven King) (10/20/90)
In article <58242@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: > >In article <1990Oct14.224706.1934@nowhere.uucp> sking@nowhere.uucp (Steven King) writes: >> >> And only if the object isnt a member (or base) of another object. >>Even tho' the translator knows this information (it does pass a flag to >>destructors) there is NOT a reliable mechanism to determine this from within >>a constructor. > >Good point. Embedded objects are another good example why C++ compilers >DO NOT typically support the (this==0) test to see if objects are on the >heap or not. I haven't seen a C++ compiler released in years that >supports this test. Correct me if you find a counter-example. The reason Actually, Cfront 2.0 does exactly this. ie class A { int x ; public: A(); ~A(); }; A::A() { x = 100 ; } A::~A() { x = 0 ; } results in: struct A { /* sizeof A == 4 */ int x__1A ; }; struct A *__ct__1AFv (__0this ) struct A *__0this ; { if (__0this || (__0this = (struct A *)__nw__FUi ( sizeof (struct A)) )) ^^^^^^^^ This isnt so much a test if the object is on the heap, but rather whether or not allocation is required. __0this -> x__1A = 100 ; return __0this ; } >that compilers DO NOT support this test is quite simple: Later changes in >the language require that constructors not be invoked on failed allocations. >So, if a failed allocator returns a null pointer [because its out of memory, >for example], then the constructor must short circuit to a no-op. >And how can a no-op check to see if (this==0) and take some specified action >if it is??? So, reasonable speaking, compilers have the option of supporting >today's definitions of how its suppose to work, or yesterday's definition. >Most compilers choose today's definition, guaranteeing that a constructor >will never be invoked when (this==0), making a (this==0) test inside a >constructor kind of pointless. > It is the body of the constructor that isnt executed... >> I wonder if there is enough of a need for this to consider adding it >>to the language... > >As mentioned above, it would do nothing to add support for the (this==0) >test inside a constructor, because constructors must short-circuit to a no-op >if (this==0), because constructors are never invoked on a failed allocation. >However, there's other practical reasons why the heap verses stack test >can't be done: Programmers have the option to dynamically allocate objects >on the stack using the placement version of new: > Actually, what I was referring to was the fact that Cfront passes a flag to the destructor to telling it if it was allocated on the stack. A::~A() { x = 0 ; } results in: char __dt__1AFv (__0this , __0__free ) struct A *__0this ; int __0__free ; { if (__0this ){ __0this -> x__1A = 0 ; if (__0this )if (__0__free & 1)__dl__FPv ( (char *)__0this ) ; } } If Cfront knows enough to do that, then it could also pass the flag to the constructor. The trade off would be the passing of arguement that usually isnt needed or wanted. And of course the flag to the destructor isnt visable to the programmer unless he wants to hack at the stack... I dont want to seem to be advocated such a change; I remain unconvinced of its neccessity. I only present this as an option. -- new && improved: sking@nowhere old && reliable: ...!cs.utexas.edu!ut-emx!nowhere!sking