Yes, to the point that only two production quality GC C++ exist, C++/CLI and Unreal C++.
C++/CLI is only considered safe, as long as pure MSIL is being generated, and specific C and C++ features are forbidden, if you make use of them, the code is considered unsafe by the verifier, and some surprises might happen, just like with Objective-C.
Whereas Unreal C++ makes use of specific macros to mark the GC aware objects, and possible bad behaviour is covered by the fact that those objects are mainly used from Blueprints, not raw C++ code.
Actually, once C++ has reflection it'll be possible to get rid of the ugly macros and the "only" issue left is root-pointers/shadow stacks. Googling just now to find the boost_pfr library I noticed a newer one that would suit the bill ( https://github.com/boost-ext/reflect/ ).
Makes me itch to rewrite a small gc I wrote a couple of years back to use that to see how "painless" it's possible to make it without ugly MINIGC_AUTOMARK(..) macros ( https://github.com/whizzter/minigc )
Reflection will make it trivial to generate tracing code automatically, so roots are the only real issue. If you do like me and require that the roots be explicitly passed to collect, then the programmer can just make the shadow stack by hand.
Though of course this will still be a much simpler beast than the sort of concurrent GC you see in managed languages. Supporting that sort of GC is a whole other ballgame, needing safepoints inserted into functions and things like that.
C++/CLI is only considered safe, as long as pure MSIL is being generated, and specific C and C++ features are forbidden, if you make use of them, the code is considered unsafe by the verifier, and some surprises might happen, just like with Objective-C.
Whereas Unreal C++ makes use of specific macros to mark the GC aware objects, and possible bad behaviour is covered by the fact that those objects are mainly used from Blueprints, not raw C++ code.