C (and, to a lesser extent, C++) absolutely
will die. The way the languages are managed guarantees this.
It's a myth that garbage collection is slow, and it's furthermore a myth that manual memory management is easy. So C (and, to a lesser extent, C++) will continue to lose ground for new projects to languages that take the requirement to manage memory off the programmer.
Furthermore, while C and C++ require low-level attention to detail in managing memory, they prohibit many low-level manipulations that you might want to use them for, if you're implementing e.g. an operating system kernel or a language runtime, by assigning them 'undefined behavior'. The C or C++ abstract machine, according to the actual language standard enforced by the compilers, is not noticeably closer to even the PDP-11 abstract machine than, say, Haskell's. (Haskell also has raw pointers, it also allows arithmetic on them, it also allows them to be converted to and from integers, and, in practice, any portable, defined-behavior low-level C code is going to end up using operations remarkably similar to what Haskell allows.)
So C (in particular) is too low-level for application code, but too high-level for system code; there is no realm where C is advisable for a new project. That leaves maintaining existing programs.
The problem here is that C and C++ long (10 years or more) ago abandoned the original X3J11 mandate to 'keep most existing programs working', in favor of aggressively using undefined behavior for optimizations. You can't keep breaking your existing programs without convincing some of their maintainers that re-writing in a new language is a better option, and without new programs that means that C and C++ will, inevitably, die, when the last program written in them is either abandoned or re-written after the compilers (yet again) break them with a new 'optimization'.