Notice that some compilers are indeed generating directly machine code, and some of them are even generating machine code in the same process that is running the compiler (a typical example of that last case is the SBCL implementation of Common Lisp: every time you interactively type some expression in its REPL, it is getting translated to machine code then executed).
Other compilers are generating some other form of code. That could be object files (containing notably a mix of machine code with relocation directives for the linker), assembler code, etc... It is not unusual for a compiler to emit C codeemit C code (which is further compiled by some existing C compiler).
The "object code" terminology may be ambiguous: I use it for the output form of any compiler (so C++ code could be object code for me, in a compiler translating to C++). Some people are restricting "object code" to object files (e.g. ELF files with relocation info).
Read more about JIT compilation (consider using some JIT libraries like asmjit, libjit, LLVM, GCCJIT, ...) and optimizing compilers.
The interesting thing today is that computers are fast enough today to make the following scenario reasonable: you code a compiler to C, and an interactive REPL which reads some expression, compile it to C code (often a few hundred of lines), forks a compilation of that generated C code into a plugin, then finally dynamically loads that generated plugin (using dlopen ...) is fast enough to be acceptable by your user.
Notice also that optimization is more and more required (to take advantage of current processors) and that it is much more costly than emitting C -or assembler- code and tranlating that. (If you generate C code, you leverage on the optimization abilities of your C compiler).
