You can find REPLs for C++ with an online search, but my advice would be different. I do the following with Java, but equivalent tools for C++ exist.
First, I use a sophisticated IDE (Eclipse) that, among other things, does error highlighting as I type. A typed language like C++ permits many errors to be caught early, normally in the compiler, but they can be pushed back into the development environment prior to formal compilation. That works for most syntax errors and for many structural errors, such as omitting a declaration.
Second, I use Test Driven Development to build serious code. I just JUnit, which is tailored for Java, of course, but there are equivalent "units" (TDD frameworks) for most languages. The rule here is "no code without a failing test". The idea is that before you write any code you write a test for it based on the specification you have or that you create on the fly. The test captures your intent directly. You write the test for a function before you begin to write the function. It fails of course, since it can't even compile. But the IDE can automatically insert the stub for the function into the code. You then provide the function body and run the test again. If it fails you need to think again.
But TDD is even better than that, since when you run the "test" you are actually running all of the tests; the test suite. So, if something used to work and now an earlier test breaks you get immediate feedback on it and, since the only thing you changed is that one method body, the source of error is usually pretty obvious. Moreover, tests are run independently of each other so that a failure of one test doesn't cascade into other failures that obscure the problem.
This is a workflow quite different from that of a REPL, so it takes some practice. But the IDE can do many things for you in addition to what is described here. The best of them have a plugin architecture in which you can easily add additional tools as needed.
Two additional notes. First, is that I use the same tools and techniques when programming Python and Ruby.
Second, having built many compilers, you should understand that the actual difference between a processor for a compiled language and an interpreted one is surprisingly small. The processing for the interpreted language has everything but the final stage code generator. But if it is to be efficient, it still creates an intermediate form of the program, possibly a tree or even an abstract assembler language version. Some of the optimization can be omitted, but only the late-stage optimizations, normally. So, an IDE for an interpreted language isn't so odd.