including a header file twice in c++

Header files are simple beasts. When you #include <header> all that happens is that the contents of header basically get copy-pasted into the file. To stop headers from being included multiple times, include guards are used, which is why in most header files you'll see something akin to

#ifndef SOME_HEADER_FILE_GUARD 
#define SOME_HEADER_FILE_GUARD

//Contents of Header

#endif

It simply gets skipped over, due to preprocessor code along the following lines:

#ifndef MY_HEADER_H
#define MY_HEADER_H

<actual header code here>

#endif

So if you include twice, then MY_HEADER_H is already defined and everything between the #ifndef and #endif is skipped by the preprocessor.

Include guard prevents the content of the file from being actually seen twice by the compiler.

Include guard is basically a set of preprocessor's conditional directives at the beginning and end of a header file:

#ifndef SOME_STRING_H
#define SOME_STRING_H

//...

#endif 

Now if you include the file twice then first time round macro SOME_STRING_H is not defined and hence the contents of the file is processed and seen by the compiler. However, since the first thing after #ifdef is #define, SOME_STRING_H is defined and the next time round the header file's content is not seen by the compiler.

To avoid collisions the name of the macro used in the include guard is made dependent on the name of the header file.

It depends. With the exception of <assert>, the standard requires the second (and later) includes of a standard header to be a no-op. This is a characteristic of the header, however; the compiler will (at least conceptually) read and include all of the header text each time it encounters the include.

The standard practice for avoiding multiple definitions in such cases is to use include guards: all of the C++ code in the header will be enclosed in something like:

#ifndef SPECIAL_NAME
#define SPECIAL_NAME
//  All of the C++ code here
#endif SPECIAL_NAME

Obviously, each header needs a different name. Within an application, you can generally establish conventions based on the filename and location; something like subsystem_filename, with characters not legal in a C++ symbol (if you're using them in your filenames) mapped (and very often everything upper cased). For libraries, the best practice would be to generate a reasonably long random sequence of characters; far more frequent (although certainly inferior from a quality of implementation standpoint) is to ensure that every such symbol begin with a documented prefix.

A system library can, of course, use reserved symbols (e.g. a symbol starting with an underscore followed by a capital letter) here, to guarantee that there is no conflict. Or it can use some entirely different, implementation dependent technique. Microsoft, for example, uses a compiler extension #pragma once; g++ uses include guards which always start with _GLIBCXX (which isn't a legal symbol in user code). These options aren't necessarily available to you.