It is basically the way standard C++ is intended and encouraged (by the committee and the community) to be used:
- use C++ language idioms (mostly based on RAII, like smart pointers)
- don't use C language idioms until you can't avoid it (which still happen regularly, when interfacing with C interfaces)
This is what we have been calling "modern C++" for almost 10 years now. But most C++ developers start only now to realize it makes code looks like there is not much need for raw pointers, writing new/delete, and other error-prone constructs.
Now these constructs (C or not) are still there both for retrocompatibilty and for allowing you to write libraries to, again, free the other developers from having to play with them.
Also, C should be used to interface with C libraries, for low level constructs that require C-style code. Any other case, you can avoid using C idioms when you have C++ available.
For clarification: using C style doesn't improve performance (assuming you understand C++ constructs and RAII). In fact, a lot of algorithms written in C++ are faster than the same in C, just because C++ give more info to the compiler to make him optimize in calling context (I'm thinking about template algorithms/types for example).
So performance is not necessarily a valid reason to use C idioms when you write C++.
Let's start at the beginning: mixed C and C++ code is fairly common. So you're in a big club to start with. We have huge C codebases in the wild. But for obvious reasons many programmers refuse to write at least new stuff in C, having access to C++ in the same compiler, new modules start to be written that way -- at first just leaving the existing parts alone.
Then eventually some existing files get recompiled as C++, and some bridges can be deleted... But it may take really long time.
You are ahead somewhat, your full system is now C++, just most of it is written "C-style". And you see mix of styles a problem, what you should not: C++ is a multi-paradigm language supporting many styles, and allow them to co-exist for good. Actually that is the main strength, that you are not forced to a single style. One that would be suboptimal here and there, with some luck not everywhere.
Re-working the codebase is a good idea, IF it is broken. Or if it is in the way of development. But if it works (in the original sense of word), please follow the most basic engineering principle: if it ain't broke, don't fix it. Leave the cold parts alone, put your effort where it counts. On the parts that are bad, dangerous -- or in new features, and just refactor parts to make them a bed.
If you seek general things to address, here's what worth evicting from a C codebase:
- all the str* functions and char[] -- replace them with a string class
- if you use sprintf, create a version that returns a string with the result, or puts it in the string, and replace usage. (If you never bothered with streams do yourself a favor and just skip them, unless you like them; gcc provides perfect type safety out of the box for checking formats, just add the proper attribute.
- most malloc and free -- NOT to with new and delete, but vector, list, map and other collectons.
- the rest of memory management (after the previous two points it must be pretty rare, cover with smart pointers or implement your special collections
- replace all other resource usage (FILE*, mutex, lock, etc) to use RAII wrappers or classes
When you're done with that you approach the point where the codebase can be reasonably exception-safe, so you can drop return-code football using exceptions and rare try/catch in high-level functions only.
Beyond that just write new code in some healthy C++, and if some classes are born that are good replacement in existing code, pick them up.
I didn't mentions syntax-related stuff, obviously use refs instead of pointers in all new code, but replacing old C parts just for that change is no good value. Casts you must address, eliminate all you can, and use C++ variants in wrapper functions for the remainder. And very importantly, add const wherever applicable. These interleave with the earlier bullets. And consolidate your macros, and replace what you can make into enum, inline function or template.
I suggest reading Sutter/Alexandrescu's C++ Coding Standards if not yet done and follow them closely.
Best Answer
Reusable for a function like the one you describe means several things:
In your case: