There are times when you want a header body to be included more than once so wouldn't use include guards or pragma once. However, if you're posting in For Beginners, then you don't need to worry about those situations for a while longer. Most of the situations where you would want to do something like that involve preprocessor metaprogramming such as with boost::preprocessor. Another example of a header without include guards is the standard C library header assert.h and the standard C++ library header cassert. You can disable or enable asserts for a region of code by #defining or #undefing NDEBUG and reincluding those headers.

3) By using #pragma once you are not being "portable". That means your program is going to work only on windows, on the compiler that comes with visual studio (cl).

Slightly incorrect. Quite honestly I can't think of a single compiler worth using that doesn't respect #pragma once... and I've used it with GCC and Clang all the time. The reason I say "slightly" is because on some oddball obscure platform with a strange compiler there may not be support for it, and that is when you need to use the header include guards instead.

3) By using #pragma once you are not being "portable". That means your program is going to work only on windows, on the compiler that comes with visual studio (cl).
The correct (i.e. portable) way is to do it like this:
#ifndef SOME_FILE_H
etc

Yes and no.

1. "pragma once" is not as badly supported as portrayed (http://en.wikipedia.org/wiki/Pragma_once).
2. it is more straightforward and is trivial to "fix" (as it is superbly unambiguous) if target implementation does not support it.
3. i would welcome more pressure for other compiles to support it too as not supporting it is embarrassing.

If one makes some library for many platforms/compilers then one should use the old kind of guards tho.

'pragma' is used to express implementation dependent preprocessor statements. The idea, the use of 'once' that is, (as far as I know) is specific to the compiler that Visual Studio uses. Such a technique isn't portable if you wanted to jump to a different compiler.

It is a far, far better idea to use header guards (defining a macro constant and testing for its existence) because all parts of the construct are standard compliant.

With respect to whether you should use it everywhere take a look at translation units and use the '/C' and '/P' flags for cl.exe; that spits out a pre-processed source file. Really the idea only needs to be used in header files because they are the only things that should really be 'included'.

There's no harm in using it in every file. In fact it probably makes your life easier in the long run in case you start re-adding the file elsewhere. That said, if you can guarantee you'll never include the file in another header then you can leave it out because it's not needed. Like I said though, probably easier to just get into the habbit of guarding every header for the delayed convenience.

I would use #pragma once because it's simpler and leaves less room for programmer error. It is supported across all major compilers (gcc, msvc, clang, intel...). In the event that you discover that you need to support an old compiler, you can run a script such as this one to replace #pragma once with include guards.

I've only once encountered a header file in which I wouldn't want to include #pragma once. By default, you should be doing it for every header file.