You asked for a non-vector solution but let’s go over it because you might have rejected it for the wrong reasons. You shouldn’t worry about performance because at the hands of any competent compiler it is going to have pretty much the same overhead as any other standard conformant solution. On the other hand, there are some readability and safety concerns that I’ll go over below. Let’s look at the ways you can do it from most recommended to least.

std::vector

The community’s favorite container and for good reason. Not only can it be declared with a run-time size, but the size can be changed at any time. This facilitates use when size cannot be predetermined, eg when repeatedly polling for user input. Examples:

// Known size
size_t n;
std::cin >> n;
std::vector<int> vec(n);

// Unknown size
std::vector<int> vec;
int input;
while (std::cin >> input) { // Note: not always the best way to read input
    vec.push_back(in);
}

There’s not much downside to using std::vector. The known size case requires exactly one dynamic allocation. The unknown size requires more in the general case, but you wouldn’t be able to do any better anyway. So performance is more or less optimal.

Semantically, it might not be ideal for sizes that are constant throughout the execution. It might not be apparent to the reader that this container is not intended to change. It is not known to the compiler either so it will allow you to do something wrong like push_back into a vector that is logically of constant size.

std::unique_ptr (or std::shared_ptr)

The safest solution if enforcing static size is important to you.

size_t n;
std::cin >> n;
auto arr = std::make_unique<int[]>(n);

arr‘s size cannot change, though it can be made to release the current array and point to another one of different size. Therefore, if logically the size of your container is constant, this conveys intent in a clearer way. Unfortunately, it is also much weaker than std::vector even in the constant-size case. It is not size-aware, so you have to explicitly store the size. For the same reason it does not offer iterators and can’t be used in range for loops. It is up to you (and the project in question) if you want to sacrifice these features to enforce static size.

Initially I had recommended boost::scoped_array but after further thought I don’t believe it has much to offer over this solution so I’ll stick to the standard library.

new[] – delete[]

Technically a solution, but unless you are forced to use an old C++ standard or you are writing a low-level library that manages memory internally they are strictly worse than the std::unique_ptr or std::shared_ptr solution. They offer no more features, but are significantly less safe because you have to explicitly free the memory when you’re done with it. Otherwise, you will leak it and this might cause significant problems. To make matters worse, using delete[] properly can be non-trivial for programs with complicated flows of execution and exception handling. Please don’t use this when the above solutions are available to you!

size_t n;
std::cin >> n;
int* arr = new int[n];
...
// Control flow must reach exactly one corresponding delete[] !!!
delete[] arr;

---

Bonus: Compiler extension

Some compilers might actually be ok with the following code

size_t n;
std::cin >> n;
int arr[n];

Relying on this has severe drawbacks. Your code cannot be compiled on all C++ conformant compilers. It probably doesn’t even compile on all versions of the given compiler. Also, I doubt that the produced executable checks the value of n and allocates on the heap when needed meaning you can blow up your stack. This solution only makes sense when you know the upper bound of n is small and when performance is so important to you that you’re willing to rely on compiler-specific behavior to get it. These are truly exceptional cases.