I'm developing a NES emulator as a hobby, in my free time. I use C++ because is the language I use mostly, know mostly and like mostly.

But now that I made some advance into the project I realize I'm not using almost any specific features of C++, and could have done it in plain C and getting the same result. I don't use templates, operator overloading, polymorphism, inheritance. So what would you say? should I stay in C++ or rewrite it in C?

I won't do this to gain in performance, it could come as a side effect, but the idea is why should I use C++ if I don't need it?

The only features of C++ I'm using is classes to encapsulate data and methods, but that can be done as well with structs and functions, I'm using new and delete, but could as well use malloc and free, and I'm using inheritance just for callbacks, which could be achieved with pointers to functions.

Remember, it's a hobby project, I have no deadlines, so the overhead time and work that would require a re-write are not a problem, might be fun as well. So, the question is C or C++?

  • 3
    It seems to me that you have already answered yourself: why use C++ if you only need C? There are many situations in which C is perfectly OK.
    – Giorgio
    Commented Dec 3, 2011 at 21:25
  • 3
    @Giorgio: And they all evaporate after the first sixty seconds and you need to maintain your code.
    – DeadMG
    Commented Dec 3, 2011 at 21:28
  • 7
    I use C++ because is the language I use mostly, know mostly and like mostly. And that's the answer to your question. You should only switch languages mid project when there's a problem your current language can't solve. I don't use templates, operator overloading, polymorphism, inheritance. It would be a lot more valuable to learn and use the concepts, than switching to C. Since this is a hobby project, why not use a few things you haven't used before? You could always start another project in C and learn the language, but for your current project it doesn't make sense to switch.
    – yannis
    Commented Dec 3, 2011 at 21:52
  • 4
    I don't use 100% of a language in every project I write either. You know C++ the best, you might find good reasons to use features you haven't found a use for before. You can start treating C++ as a much safer C, once you start using the standard library stuff and boost constructs like std::shared_ptr, std::unique_ptr, boost::scoped_ptr, std::vector, std::deque, std::map, etc. For callback functions, look into the use of functors, and in C++11, you can also start using things like lambda functions.
    – wkl
    Commented Dec 3, 2011 at 22:07
  • 3
    @Giorgio: Yep. Rolling the infiniteth linked list is bound to produce unnecessary errors.
    – DeadMG
    Commented Dec 4, 2011 at 0:36

8 Answers 8


You aren't using it now, but the next time you leak memory or get a double delete, you'll be begging to come back to std::vector<T>, std::unique_ptr<T, Del> and std::shared_ptr<T>, which can solve those problems easily- almost trivially. That's what happens to everyone who uses C over C++, eventually, and the smarter ones just don't wait for the bugs to pop up before moving over.

Code that uses new and delete directly doesn't really belong in C++, it belongs in that kind of half house that we refer to as "C with Classes". That's where the language was circa 1985. It's not particularly similar to C++, circa 2011. In all likelihood, wherever you learned C++ simply didn't teach it very well- something that is unfortunately rather common- and with a better education, you would find use of these features.

Specifically, as I listed above, C++'s generic data structures and the resource-managing classes simply are fundamentally massively superior to anything C has to offer. If you want a dynamically allocated array, then use std::vector<T>. That's a pretty common use case. If you aren't using them, then your code is at huge risk of error unnecessarily- especially resource management related. C++ can guarantee safety and re-use code in a way that C can never touch.

However, I think that you also might be expecting too much. Writing templates and operator overloads is not common for library consumers. If your code uses std::vector<T>, you don't need to write a template to make that happen. If your code uses std::string, nobody is forcing you to overload your operators. You only have to do those things to write std::vector<T> and std::string- but you can still take full advantage of them.

Polymorphism/inheritance also only has a specific use case. If your code happens to not require you to write any templates or use virtual functions, then it doesn't, and there are programs or segments of programs where you don't need to write your own templates.

Also, there's no gain in performance in C over C++.

  • 1
    @Giorgio: make_shared exists, and you can write a trivial make_unique template that does the same job. It's safer.
    – DeadMG
    Commented Dec 3, 2011 at 21:52
  • 4
    Great answer. Nail on the head. C++ is most valuable for these little libraries that we should always be using. Commented Dec 3, 2011 at 23:13
  • 2
    @Giorgio: It's unsafe because when calling multiple arguments like that, you can get a memory leak in the case of exception, and make_shared is more efficient. Only factory functions can offer guaranteed exception safety.
    – DeadMG
    Commented Dec 4, 2011 at 0:35
  • 6
    @tp1: WTF? In English, please.
    – DeadMG
    Commented Dec 4, 2011 at 20:58
  • 2
    @Lohoris You don't need a citation for common sense. In which way should C be more performant than C++? Commented May 11, 2012 at 9:12

Even if you don't use C++ specific features, a C++ compiler will catch more problems than a C one due to the stricter type system of C++.


I would look at it from the other direction. Will you gain anything by rewriting the code in C? Even on a purely hobbyist project, there's a cost associated with a rewrite like that. If nothing else there's what I suppose would be called opportunity cost -- i.e., the other things you could have done in that time if you weren't wasting your time rewriting it in C.

Bottom line: unless you think the code is really likely to be used in some environment where access to C++ is really limited (or nonexistent), it would be a pointless waste of time at very best. At least in my experience, it usually goes well beyond that very quickly -- thinking back over code I've written in C++ that had to be converted to C, I can pretty clearly remember that even in quite a few cases where it seemed like it should be trivial, I was using a lot more features specific to C++ than I initially realized. To have much hope of being useful at all, you'd pretty much have to target C89/90, in which case you quickly get reminded of things like having to define all variables at the beginning of a block instead of where they're actually used.

In short, unless you're pretty sure rewriting in C will provide a real benefit, there are almost inevitably a lot better things to do.

  • +1 Some time ago I had to write a library to be used in another C project and I thought it was a good idea to also implement it in C, man what a stupid idiot I was back then. Commented May 11, 2012 at 9:19

As a more general answer:

Do not switch to C++ just because you are using some of it's more unique features. One day you may need those features, and will just pound your head because you are using C.


For hobbyist development, I would consider switching back to plain C. C and C-like languages are more likely to be supported on tiny hobby development modules.

Many of the answers here might be from professional software types. As a hobbyist, you won't be coding continuously or full time. So consider which language you are more likely to remember or forget the quirks within, if you table your project for a year and then come back and try to read your code after you have gotten rusty in coding. C++, having a richer feature set, may take more or less time to re-acquire, depending on your coding style.


It's not easy to answer your questions, since we don't know if you are working on the project to improve your language specific skills (C vs C++) or to improve other programming skills (design, problem-solving, etc.).

"The only features of C++ I'm using is classes to encapsulate data and methods, but that can be done as well with structs and functions,". This is not true. structs in C do not support encapsulation and cannot contain functions (methods) - at least not without using techniques like pointers to functions. Also, functions in C are weaker because they cannot be overloaded.

"I'm using new and delete, but could as well use malloc and free, and I'm using inheritance just for callbacks, which could be achieved with pointers to functions.". As deadmg mentioned, using directly new and delete in C++ is not encouraged. Also, IMHO (and the GoF) inheritance in OOP should be preferred over composition only when polymorphism is required. And I don't think that it is trivial to achieve polymorphism (late binding) in C using pointers to functions.

Other than that, I'll not try to convince you that C++ is "better" than C because it's a matter of preference and it always depends on the problem that you are trying to solve (using OOP features for developing your NES emulator might be a good idea).

  • 1
    structs in C can, in fact, be used to encapsulate methods. You simply create a struct of function pointers, and initialize them to point to whichever functions you want. Have a look at lxr.linux.no/linux+v3.3/include/linux/fs.h#L1598 for an example. Commented Apr 1, 2012 at 4:05
  • That's right. Thanks for the comment, I extended the answer.
    – sakisk
    Commented Apr 1, 2012 at 9:22
  • Nice. One more nit: functions in C can be overloaded (think printf), but in doing so you lose any type checking. There is no way to have a finite set of acceptable declarations: it's either 1 (and you get type checking) or "many" (and lose all type checking, at great personal risk). As with most things in C, it's possible but often uncomfortable. Commented Apr 1, 2012 at 18:24
  • Pointers to functions are an advanced C technique? Really? Commented Apr 1, 2012 at 20:39
  • @DonalFellows You are right, I exaggerated. Removed advanced... :)
    – sakisk
    Commented Apr 2, 2012 at 19:51

I am a very beginner, so here comes my 2 bits.

I am learning C and C++ at Wibit.net with some nice basic videotutorials, maybe they can help you a lot to take a overview of the "situation" (not an ad!)

I advice you to change to C, just to learn, as you are a hobbyist, this will be a pleasure, not a problem.

I advice more. Do it in both languages. Compare the way and solutions you will find and use. I am sure it will be not "so easy" as you are expecting... but sure you will learn a lot!

  • 1
    Thank you very much, but I'm not learning, I already know C and C++, I'm asking which one to use for this specific project.
    – Petruza
    Commented Apr 3, 2012 at 2:34
  • oops, my time to learn! =P
    – H_7
    Commented Apr 3, 2012 at 2:38
  • 1
    Also, I would advice that instead of video tutorials, you get Kernigan's and Stroustrup's books, a nice IDE (Visual Studio, Eclipse, Xcode) and learn by coding the examples, trial and error and resorting to stackoverflow.
    – Petruza
    Commented Apr 3, 2012 at 18:07

Here's pros and cons of C++ vs. C:

  1. Moving to C would make it easier to stay within the chosen C++ subset, because compiler would then give error when you go outside of it. If the main problem is with staying within decided subset, this alternative should be chosen. (why don't we have compiler support for this?)
  2. Once you can stay within chosen c++ feature subset, then next thing is to try to change the subset to get rid of bad conventions which break the code. This requires use of whole c++.
  3. Once you have both "staying inside subset" and "it's a good subset", then move outside of c++ features, and start thinking about requirements.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.