C++ class to compute similarity coefficients
I have to admit that I don't have any familiarity with this particular problem, so I can't offer any great advice on it. That said, I do see a few things in your code that I think could be improved.
Scope
One thing I would recommend is moving variables closer to the place where they are used. You're currently defining all variables at the beginning of the function, and that makes it harder to tell what might have been changed when reading the body of the function. In PearsonSimilarity() you're using aVal, bVal, and the vectors in the first for loop. The expected values are not used until the second for loop (inside an if). I would move their declarations into the else clause of the if because of this. Further, I would move each declaration to its own line. Your lines are very long and hard to read because I have to scroll to see everything on them.
In fact, it might make sense to break up the function and call 2 smaller functions - one which calculates the commonItemCounter and the arrays, and another which processes the arrays. That's up to you.
Performance
One big thing I see that could be improved is to remove all calls to pow(). In each case you are squaring the input value. pow() is a very expensive function, and it's a single instruction to just multiply a value by itself. I would first pull the value out of the array, and then use it multiple times, like this:
    for (int i = 0; i &lt; aValues.size(); i++)
    {
        double a = aValues [ i ];
        double b = bValues [ i ];
        double ab = abValues [ i ];
        aExpectedValue += a / commonItemCounter;
        bExpectedValue += b / commonItemCounter;
        aSquaredExpectedValue += (a * a) / commonItemCounter;
        bSquaredExpectedValue += (b * b) / commonItemCounter;
        abExpectedValue += ab / commonItemCounter;
    }

Another thing that I see that is likely to be slow is that commonItemCounter is defined as an int but is used to calculate floating point values. You should declare it as a double. And then, once you have, it might make sense (measure to be sure) to invert it and multiply by it instead of dividing by it. (This might be a non-issue on modern systems, but has been an issue in the past.)
Early Returns
Early returns are helpful when you have some &quot;early out&quot; conditions such as the input being out-of-range or degenerate in some way. That's not the case here, and it can be confusing to follow. In this case, I'd recommend having a return value and only a single return statement at the end like this:
double result = 0.0;
if (aValues.size() &gt; 0)
{
    for (int i = 0; i &lt; aValues.size(); i++)
    {
        // ... rest of loop here
    }
    double denominator = sqrt(...stuff...)
    if (denominator != 0.0)
    {
        result = (abExpectedValue - (aExpectedValue * bExpectedValue)) / denominator;
    }
}
return result;

It's fewer levels of ifs (less cyclomatic complexity) and easier to understand the flow.