Using local variable assigned to return value of a function or using function directly

Yes, there is a fairly serious difference. In the first case, c is an lvalue, and it will not be destroyed until the end of the scope. This can delay useful things like reosurce cleanup. More problematically, it being an lvalue means that it cannot be moved, but must be copied, which is inefficient for many classes but downright illegal for some very important classes, like unique_ptr.

In the second case, the compiler cleans up the temporary right away, so all resources are released promptly, and it being an rvalue gives the compiler more freedom to optimize and permits move semantics.

This is still true when value is a member or member function, as the result of both can inherit value category from their parent object.

You should always scope objects to the minimum scope required, and if you don't need to access c later, then you should use the temporary.

Is there a difference? Yes, massively so. To the reader.

The compiler couldn't care less which way you write it. The code emitted, space used and time of execution are so close they're not worth spending one millisecond of thinking time on.

But your readers will care. In some situations the first form offers the opportunity to provide a useful variable name to help explain your intent. In other situations the lack of a declared variable makes it a single statement and could be easier to read, especially if there are lots of them.

Please, get over the idea you should care about what the compiler thinks and start to care more about what your readers think! And, by the way, you are one of those readers in six month's time.

Nope! It merely evaluates the getMyClass().value expression and sends it to the method's parameter. Of course, the parameter itself is a local variable scoped to the method.

The first form tells the compiler to create a new instance of MyClass. If getMyClass() returns a const reference to MyClass, you don't really need a new instance. Your compiler may optimize the new instance away, but under those circumstances, if MyClass::value() is a const function, I prefer to write

const MyClass& c = getMyClass();
calculate(c.value());

Even if getMyClass() returns a simple MyClass, technically you can still declare const MyClass& c; the compiler will simply force the new instance of MyClass to remain in existence as long as c is in scope, similar to what happens if you declare MyClass c, though there are arguments over whether this is a good coding practice (see here or here).

As has already been pointed out, the instance created by the first form continues to exist until the end of the scope, although you can minimize the effect in this case by adding an extra pair of { and }:

{
  MyClass c = getMyClass();
  calculate(c.value());
}

Personally, in most cases I prefer to create a local variable with a name that tells me something about what I'm passing to the calculate function, to make the code more self-documenting. An exception is when I have to call calculate several times in a row on different values, in which case it may be clearer what's happening if the calls occur on consecutive lines of code without declaring any new variables.