[comp.lang.c++] testing this==0

thomasw@hpcupt1.HP.COM (Thomas Wang) (06/27/90)

/ hpcupt1:comp.lang.c++ / harris@uncecs.edu (Mark Harris) / 10:59 am  Jun 26, 1990 /

>#include <stdio.h>
>struct test{
>  int a;
>  test(){
>    if(this==0)puts("zero");
>    else puts("nonzero");
>  }
>};

Testing or setting 'this' to 0 should not be done any more.  This is what I
use for testing heap versus stack objects:

// explain function
// Is this object allocated from the stack?
// This code is machine dependent.  It assumes stack have a higher address
// than heap space.
char base_ref_t::is_stack_object()
{
  char x;
  return ((unsigned int) this) > ((unsigned int) &x);
}

>    Mark Harris                            mail:harris@ecsvax(UUCP/BITNET)

 -Thomas Wang
              (Everything is an object.)
                                                     wang@hpdmsjlm.cup.hp.com
                                                     thomasw@hpcupt1.cup.hp.com

dsr@luke.mitre.org (Douglas S. Rand) (06/27/90)

In article <1990Jun26.175953.16763@uncecs.edu>, harris@uncecs.edu (Mark
Harris) writes:
|>
|>Help!  I'm fairly new to C++, and I'm running into unexpected 
|>behavior from my new Borland compiler.  I thought that the value 
|>of 'this' was supposed to be zero at the start of an object's 
|>constructor if the object is being created on the heap.  I 
|>expected output 
|>  nonzero
|>  zero
|>in the program below, but I get
|>  nonzero
|>  nonzero
|>What gives?
|>
|>#include <stdio.h>
|>struct test{
|>  int a;
|>  test(){
|>    if(this==0)puts("zero");
|>    else puts("nonzero");
|>  }
|>};
|>
|>void main()
|>{
|>  test t;
|>  test *x=new test;
|>}
|>

`this' can never be zero in a constructor.  It's just been malloc'd or
allocated on the heap
and already has a distinct address.  If this wasn't true you couldn't
assigned values to 
the instance variables,  you'd have a zero pointer dereference.
                                  
Douglas S. Rand 
Internet:   <dsrand@mitre.org>
Snail:	    MITRE, Burlington Road, Bedford, MA 
Disclaimer: MITRE might agree with me - then again...

jimad@microsoft.UUCP (Jim ADCOCK) (06/28/90)

In article <1990Jun26.175953.16763@uncecs.edu> harris@uncecs.edu (Mark Harris) writes:
>
>Help!  I'm fairly new to C++, and I'm running into unexpected 
>behavior from my new Borland compiler.  I thought that the value 
>of 'this' was supposed to be zero at the start of an object's 
>constructor if the object is being created on the heap.  

While the (this==0) test in mentioned in passing in Stroustrup's 1986
text, I believe it should be considered part of the assignment-to-this
anachronism.  In fact, even the compilers I have seen that support the
assignment-to-this anachronism don't support the (this==0) test for
objects on the heap.  Only the very first C++ compiler I tried some
years ago ever actually support the (this==0) test.

The present definition on how things are suppose to work is as follows:
a) don't assign to this, if you need to modify memory allocation behavior,
overload operator new. b) if operator new ever returns zero, it is guaranteed
that initialization will not be performed -- the constructor body will not even
be executed, so in the following constructor:

class mything
{
public:
	mything() { if (this==0) printf("Non-conforming compiler!\n"); }
};

the printf should never occur, even if operator new fails to successfully
allocate memory.

[see E&S for the detailss]

So the question becomes: is there a standard, portable way to test whether
allocation is being done on the stack, heap, or wherever?  Answer: nope!
There are lots of non-standard, non-portable ways to test this, however.
Possibly the most portable thing to do is to test if this is in a region
reasonably considered stack, since stack is typically contiguous [heap need
not be.]  Could still cause you troubles in a lightweight threaded application,
however.