Any garbage collection algorithms (of which reference counting algorithms is a subset) for C/C++ need to deal with the fact that it is not possible to do a fully generic gc for C/C++ without either a) being conservative (that is, you will miss out on some memory) or b) putting additional constraints on the developers that the language doesn't.
So yes, you can do ARC for C/C++, but it would need to be opt-in, and it would not be sufficient for all memory allocation in C/C++ because the moment you link in a third party library that doesn't play ball you need to do things differently.
The chosen approach in C++ has largely "smart pointers" - template classes that implement various reference counting semantics - coupled with RAII.
E.g. one part of the problem for a fully generic solution in C/C++ is that in C/C++ nothing stops you from taking an arbitrary bit-pattern and treating it as a pointer and vice versa. As an example, take BPTR's in AmigaOS - core parts of AmigaDOS were written on contract due to time constraints, and they were written in BCPL, and that's where they came from.
BPTR's were pointers that had been bit-shifted right two bits - basically BCPL was treating memory as an array of 32bit quantities. So a lot of pointers in AmigaOS are stored in memory as values that don't actually match any memory address. So one hand your compiler don't know when/where to apply a reference count, and on the other hand a generic non-ref-counting gc won't know whether or not any specific value is a pointer, and if so whether it meant to point at the actual memory address indicated by the value or if it needs to be bit-shifted.
In C this is perfectly legal. But to gc apps that do stuff like that, your gc must either be smart enough to figure out every possible pointer manipulation (meet the halting problem, it wants to have a word), or it needs explicit support from the developer.