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.