Yes.

There are lots of refactorings that cannot be done by simple search and replace, even for C, because they require semantic knowledge of the language.

Very true, especially when you considering how many namespaces C has. In C++, its even harder.

you know that the c/c++ plugin for intellij is broken? so what are you using that is smart enough to parse and refactor c? (serious question as i've had to switch to eclipse).

I seldom use C or C++ nowadays and when I do it is only C++.

I rarely do IDE refactorings when in C/C++ because of what you state.

QtCreator and CDT do offer some nice things, although still far from what is possible in another languages.

If JetBrains produced a proper C/C++ IDE I would probably buy it for C++ work.

confused by this response i re-read the thread and it turns out i mis-read your comment (thought you said "can" instead of "cannot"). sorry!

There is a problem that each and every tool for semantic-aware C/C++ refactoring I have tried does not work 100% of the time (i.e. it sucks more than 0%). This happens particularly because C/C++ have header files that expand to huge source files and preprocessor macros driving the parsers nuts because the parsers of the refactoring tools are simplified for speed, and also in a typical C/C++ program there is a number of combinations of macros that can be active or non-active depending on compiler options. So in case of C it always comes out faster, easier and more reliable for me to use basic tools such as search/replace because C has very simple semantics without namespaces. I often do that even in C++ because of the mentioned reasons.

If you are using macros in C++, you are doing it wrong. They are a relic of a bygone age.

Thanks for letting me know, I try to use the macros as little as possible, but there are such things as platform-specific code, compiler differences, third-party libraries, standard libraries such as WinAPI and legacy code.

Platform-specific code is a very good use that precluded me at 1 o'clock this morning.

I tend to wrap legacy code in a C++ wrapper if I can; allowing me to code to a C++ idiomed API, rather than the choice of that particular developer. More often than not, it adds no overhead through the use of inlined functions...