Is it good to send stack allocated object as a pointer parameter to some other function?

Question

Is it good to send stack allocated object as a pointer parameter to some other function?

Answer 1

If you are sure that the call is synchronous then it is perfectly valid to send the stack allocated object's address to the function. In case the call is asynchronous (i.e. the function you called passes the pointer to a different thread) then it will definitely creates issues as you might try to access the memory address from the different thread even after the stack allocated object is destoryed.

Answer 2

As long as the receiving function isn't assuming that it obtains ownership of the resource (and tries to free it), sure. A reference might be a better idea though.

Answer 3

Its is perfectly fine for a synchronous function call. If the call is asynchronous it might lead to crash when the stack object is deleted when it goes out of scope.

Answer 4

Yes, but the more common C++ idiom for this situation is to use a reference (and probably a const rreference) instead of a pointer. So instead of

void foo( sometype * p ) {
   p->func();
}

you write:

void foo( sometype & p ) {
   p.func();
}

This has the advantage that you don't need to dereference the object in the caller:

void afunc() {
   sometype t;
   foo( t );
}

and also gives a subliminal hint to the reader that you do not intend the function to take ownership of the object.

Answer 5

You should be careful not to store that pointer for further use. For example:

void store(int* param) {
     // Store pointer in some global storage for further use
     global_storage.add_param(param); 
}
void func() {
    int test_var = 5;
    store(&test_var); // Pass the pointer to the global storage
} 
// At this point stack object test_var will be destroyed
// Global storage contains a pointer, that points to some garbage

Answer 6

It's certainly valid, but with many caveats. Here are the top things to keep in mind (some already mentioned by others, some not.)

• The pointer in itself may imply that the resource ownership is passed to the called (i.e. they must free it after use). Here, a reference is in place.
• In many situations the function you need to call is already defined and you can't change it, you must study its behavior and make sure it doesn't assume it will own the object, store it statically or copy it elsewhere.
• If the function you are calling needs to take a null-pointer to indicate the absence of said parameter, you will have no choice of using a reference.
• Asynchronous calls are absolutely a no-no (unless, of course, you block until they are done using your local object and then return).
• The called function should never ever in any event access beyond the size of the object in question, this will destroy your stack and almost certainly crash your program!
• Calling a function that is susceptible to accessing bytes beyond the size of the object may be a security liability. In deed, this is the most common method for breaking into secure systems. This is called buffer overflow. (beyond the scope of your question, but you can read more here and here)