Q:

C++ memory preallocation for vector via constructor fails

I use VS2013 (Win7 64).  I discovered some strange behavior.  When I reserve memory using the reserve method, the code works, but when I reserve via constructor, it throws bad_alloc
const int elemNumber = 100000000;
try
{
    //std::vector<int>* intVector = new std::vector<int>(elemNumber); // throws bad_alloc
    std::vector<int>* intVector = new std::vector<int>();
    intVector->reserve(elemNumber); //OK

    std::chrono::time_point<std::chrono::system_clock> start, end;
    start = std::chrono::system_clock::now();

    for (int i = 0; i < elemNumber; ++i)
    {
        intVector->push_back(i);
    }

    end = std::chrono::system_clock::now();
    std::chrono::duration<double> elapsed_seconds = end - start;
    std::cout << "Time interval: " << elapsed_seconds.count() << endl;
    delete intVector;
    cout << "Done" << endl;
}
catch (bad_alloc exc)
{
    cout << exc.what() << endl;
}

What could be the reason? 

A:

hlt has already answered this in a comment...

The constructor doesn't reserve, it resizes.  Is it possible you just run out of memory? 

...so posting an explanation as community wiki...
This...
std::vector<int>* intVector = new std::vector<int>(elemNumber); // throws bad_alloc

...needs to populate the vector with default-constructed elements, so it's writing to all the pages of memory needed for elemNumber ints, and the initial size() is elemNumber, while...
std::vector<int>* intVector = new std::vector<int>();
intVector->reserve(elemNumber); //OK

...is just reserving virtual addresses for the memory - the OS doesn't need to find actual backing memory until elements are added later; the initial size() is still 0. 
The program then goes to push_back lots of elements - for the first case, they're in addition to those default-constructed elements already in the vector, which is why it's running out of memory. 
Remember too that the memory momentarily used during resizing (caused by push_back beyond capacity) increases as the container gets bigger, as does the amount by which the container tends to pad out the capacity so it won't have to resize again too soon, and whatever memory's needed must be contiguous in virtual address space (which is primarily a potential issue here for a 32-bit app). 

A:

Take a look at the following example:
#include <iostream>
#include <chrono>
#include <vector>

int main()
{
    const int elemNumber = 5;
    try
    {
        std::vector<int> intVector(elemNumber); // throws bad_alloc

        std::chrono::time_point<std::chrono::system_clock> start, end;
        start = std::chrono::system_clock::now();

        for (int i = 0; i < elemNumber; ++i)
        {
            //intVector[i] = i;
            intVector.push_back(i);
        }

        //prints the vector
        for (auto& i : intVector)
        {
            std::cout << i << std::endl;
        }

        end = std::chrono::system_clock::now();
        std::chrono::duration<double> elapsed_seconds = end - start;
        std::cout << "Time interval: " << elapsed_seconds.count() << std::endl;
        std::cout << "Done" << std::endl;
    }
    catch (std::bad_alloc exc)
    {
        std::cout << exc.what() << std::endl;
    }

    std::cin.get();
    return 0;
}

The constructor first resizes the vector to have 5 elements.  After that it pushes 5 more elements to the vector making it double the size and the first 5 elements are initialized to 0. 
If you were to use the reserve function instead the size of the vector would only be 5*sizeof(int) with preallocated memory. 
Using:
vectorInt[i] = i;

instead together with the resize constructor will result in the vector being the same size as if you were to use reserve and will not throw std::bad_alloc. 
The reason for std::bad_alloc is most likely that you run out of memory. 