Does #define in C put the thing exactly or give spaces before and after?

The C standard specifies that the source file is analyzed and parsed into preprocessor tokens. When macro replacement occurs, a macro that is replaced is replaced with those tokens. The replacement is not literal text replacement.

C 2018 5.1.1.2 specifies translation phases (rephrasing and summarizing, not exact quotes):

1. Physical source file multibyte characters are mapped to the source character set. Trigraph sequences are replaced by single-character representations.

2. Lines continued with backslashes are merged.

3. The source file is converted from characters into preprocessing tokens and white-space characters—each sequence of characters that can be a preprocessing token is converted to a preprocessing token, and each comment becomes one space.

4. Preprocessing is performed (directives are executed and macros are expanded).

5. Source characters in character constants and string literals are converted to members of the execution character set.

6. Adjacent string literals are concatenated.

7. White-space characters are discarded. “Each preprocessing token is converted into a token. The resulting tokens are syntactically and semantically analyzed and translated as a translation unit.” (That quoted text is the main part of C compilation as we think of it!)

8. The program is linked to become an executable file.

So, in phase 3, the compiler recognizes that #define kk xx+k-x consists of the tokens #, define, kk, xx, +, k, -, and x. The compiler also knows there is white space between define and kk and between kk and xx, but this white space is not itself a preprocessor token.

In phase 4, when the compiler replaces kk in the source, it is doing so with these tokens. kk gets replaced by the tokens xx, +, k, -, and x, and k is replaced by the tokens +, -, 6, +, and -. Combined, those form xx, +, +, -, 6, +, -, -, -, and x.

The tokens remain that way. They are not reanalyzed to put + and + together to form ++.

As @EricPostpischil says in a comprehensive answer, the C pre-processor works on tokens, not character strings, and once the input is tokenised, whitespace is no longer needed to separate adjacent tokens.

If you ask a C preprocessor to print out the processed program text, it will probably add whitespace characters where needed to separate the tokens. But that's just for your convenience; the whitespace might or might not be present, and it makes almost no difference because it has no semantic value and will be discarded before the token sequence is handed over to the compiler.

But there is a brief moment during preprocessing when you can see some whitespace, or at least an indication as to whether there was whitespace inside a token sequence, if you can pass the token sequence as an argument to a function-like macro.

Most of the time, the preprocessor does not modify tokens. The tokens it receives are what it outputs, although not necessarily in the same order and not necessarily all of them. But there are two exceptions, involving the two preprocessor operators # (stringify) and ## (token concatenation). The first of these transforms a macro argument -- a possibly empty sequence of tokens -- into a string literal, and when it does so it needs to consider the presence or absence of whitespace in the token sequence.

(The token concatenation operator combines two tokens into a single token if possible; when it does so, intervening whitespace is ignored. That operator is not relevant here.)

The C standard actually specifies precisely how whitespace in a macro argument is handled if the argument is stringified, in paragraph 2 of §6.10.3.2:

Each occurrence of white space between the argument’s preprocessing tokens becomes a single space character in the character string literal. White space before the first preprocessing token and after the last preprocessing token composing the argument is deleted.

We can see this effect in action:

/* I is just used to eliminate whitespace between two macro invocations.
 * The indirection of `STRING/STRING_` is explained in many SO answers;
 * it's necessary in order that the stringify operator apply to the expanded
 * macro argument, rather than the literal argument.
 */
#define I(x) x
#define STRING_(x) #x
#define STRING(x) STRING_(x)

#define PLUS +

int main(void) {
  printf("%s\n", STRING(I(PLUS)I(PLUS)));
  printf("%s\n", STRING(I(PLUS) I(PLUS)));
}

The output of this program is:

++
+ +

showing that the whitespace in the second invocation was preserved.

Contrast the above with gcc's -E output for ordinary use of the macro:

int main(void) {
  (void)   I(PLUS)I(PLUS)3;
  (void)   I(PLUS) I(PLUS)3;
}

The macro expansion is

int main(void) {
  (void) + +3;
  (void) + +3;
}

showing that the preprocessor was forced to insert a cosmetic space into the first expansion, in order to preserve the semantics of the macro expansion. (Again, I emphasize that the -E output is not what the preprocessor module passes to the compiler, in normal GCC operation. Internally, it passes a token sequence. All of the whitespace in the -E output above is a courtesy which makes the generated file more useful.)