Performance and safety of local array as parameter

I just want to make sure there aren't any potential problems with this. It compiles and runs fine, but am I risking any weird memory effects? Do I need to be especially concerned about exceptions in this case?

//.开发者_如何学运维..constructor of some class
myobj(int length, int *vars)
{
    // do stuff with vars
}

// inside some other code somewhere
int vars[3] = {5,6,7};
myobj *o = new myobj(3,vars);

(Edit.) I'm just concerned because I know pointers to objects on the stack should always be used with caution. To be specific about my usage, I'd mainly like the fastest way to pass in a variable number of arguments of the same type. So is this a bad way to do it? Thanks..

Postscript. All the answers were very helpful, thanks! I'll see whether the performance matters enough to use this method, or perhaps if I can solve the problem another way altogether.

There's nothing inherently wrong with this. However, there are a few things you need to be careful of:

• Don't keep a pointer to vars around after you return (or at least, after it goes out of scope). vars is only valid until you leave the scope that it was declared in.
• Make sure you don't run off the end of the vars array.

It's more common style in C++ to use, e.g. a std::vector<int> & parameter, or some other container type. This has two major reasons for it: By passing as a reference, it makes it more obvious that you may not be meant to keep a pointer to the object, and by passing a vector, the size of the array is kept along with the array itself (and you can expand the array if need be as well). However, this is a matter of style, and there is overhead to vector, so if performance is at a premium, this approach is perfectly reasonable.

If your myobj class for some reason stores the pointer to the int[], then you open the doors to all sorts of trouble -- when the original vars array goes out of scope, you're left with a dangling pointer; you cannot easily copy your class; you have to think about exception safety; etc etc.

Much preferable to use a standard library container that takes care of your problems, like Steve suggests.

Referring to the title of your question, if you really just pass the array to "some free function" then perhaps this may be excusable, but you explicitly say that you're using it in the constructor of a dynamically allocated object. That just reeks of trouble.

This is fine so long as you don't overrun the array in the called constructor, or otherwise abuse the memory involved.

It's not great C++ though - what's wrong with using const vector<int>& as the parameter?

In particular, don't store a pointer to your stack-based array in the myobj instance that's created from it - ie. you have to copy the input int values into the class, unless you use something like boost::shared_array.