C++: Pointers and scope

int* test( )
{
    int a = 5;
    int* b = &a;
    return b;
}

Will the result of test be a bad pointer? As far as I know a should be deleted and then b would become a messed up pointer, right?

How about开发者_高级运维 more complicated things, not an int pointer but the same with a class with 20 members or so?

The term for what you're returning is a "dangling pointer". a is a local variable allocated on the stack, and it is no longer available once it goes out of scope (which is something completely different from garbage collection). Attempting to use the result of a call to test() will be undefined behavior.

On the other hand, if you didn't allocate a on the stack -- (int *a = new int(5);), then int *b = a; return b; would be just fine, although not as good as return new int(5). However, if you don't properly free the result later, you will have a memory leak.

Yes, it's a pointer to something that no longer exists, the local variable called a. Whether a is an int, an array, an instance of a class makes no difference. And c++ does not have garbage collection.

In this case, and in many others, you should of course return a copy:

int test( )
{
    int a = 5;
    return a;
}

This is true for classes as well as the built-in types.

The pointer b in this case points to an entity allocated from the stack. That memory will be available to the calling process as soon as this function returns.

If you need to create an object that will outlive the process which created it, you'll need to use malloc() or new to get a block of memory from the heap, and remember to free or delete it later.

Yes, this will give a dangling pointer. If you want the value to persist, you have a couple of possibilities. One is that since you apparently really want to return a value, do exactly that -- return the value instead of a pointer. Another is to allocate the object involved with new, and return a pointer to that dynamically allocated space. This makes deleting the object the responsibility of the caller, however, which can lead to memory leaks and such.

In the end, you generally want to figure out what scope the variable really needs, and have it owned by something (most often an object) with that scope, so it'll be created automatically on entry to the scope, and destroyed automatically on exit from the scope.

If you can't do that, you still need to figure out who "owns" the object, and will be responsible for destroying it as needed. Once in a while that's hard to pin down, and you need something like a reference-counted pointer to keep track of things. At least in my experience, these are used much more often than they really should be though. I've been writing C++ almost as long as anybody outside of AT&T, and haven't needed a shared_ptr yet. A few times, I've thought I'd need it, but eventually figured out a cleaner design the eliminated the requirement.