C vs C++ Question

[DEhqDjzh]

Hi, There are 65,700,000 results in google about C vs C++. But what I want to ask is this:
A c++ Programmer said:

All of the C benefits could also be achieved just as easily using restrained c++ code that refrains from/not using templates, Virtual Functions and inheritance on serialized objects

Then is there a reason left to use c++

[jlb]

Yes type safety is one reason. Another reason, templates, Virtual Functions and inheritance.

[DEhqDjzh]

@jlb I wanted to remind you

All of the C benefits could also be achieved just as easily using restrained c++ code that refrains from usingtemplates, Virtual Functions,and inheritance on serialized objects

[jlb]

So? You asked is there a reason left to use C++, my answer was yes. And just because you can use only the C aspects of the language that doesn't mean you should.

[Repeater]

This seems a very odd question. Have we misunderstood? It seems to be asking why bother with C++ when we could just use a different programming language, C.

[DEhqDjzh]

@Repeater What I really Want to ask is when we exclude templates, Virtual Functions, and inheritance from our c++ code, is there any difference left with C ?

[Repeater]

Classes is a pretty big one.

[mbozzi]

All of the C benefits could also be achieved just as easily using restrained c++ code that refrains from usingtemplates, Virtual Functions,and inheritance on serialized objects

No, that's wrong. And what's that nonsense about "inheritance on serialized objects"?

C's primary benefit is its portability.
- Writing C++ code that's C-compatible requires a little extra work, so occasionally C is a better choice in those situations.
- C compilers are much simpler to write - meaning, if you need to work on certain embedded systems, it's possible you'll have a C compiler, but not a C++ compiler.

when we exclude templates, Virtual Functions, and inheritance from our c++ code, is there any difference left with C ?

Function overloading (aka early binding). Compile-time assertions. Anonymous functions. Compile-time computation. Type-safe enumerations. Better explicit type conversions. Powerful generic programming facilities, although C++ generic code is mostly reliant on templates. Core language support for move semantics and perfect forwarding. References.

There are many more subtle differences, and certainly some major ones that I didn't list.

It seems like you're looking for an excuse to use C.
If you want to use it, go ahead. You only need to make objective decisions if you're responsible for something. Since this is a personal project (I think), you can do whatever you want. Curiosity is a good reason.

[DEhqDjzh]

@mbozzi you are right I want to make a game engine with C but I can't find any reason why (Game) industry uses C++?

[helios]

Is C++ having more features not a good enough reason?

Why do you think the game industry should use C instead of C++?

[DEhqDjzh]

@helios Because C is powerful and less complicated:
1. The Inheritance is a pain in the a*s. I have to fix bugs that didn't caused by me and don't need it
2. I don't need classes to create an (in this example) game engine I can use structs when I need Classes. And manual Destructor and Constructor
3. I don't need function overloading and Templates when coding a game engine
and many more...
So any reason left ?
Note: Correct me if I were wrong

[Repeater]

The Inheritance is a pain in the a*s. I have to fix bugs that didn't caused by me and don't need it

If you wrote the code, and there are bugs in it, you must have put them there.

And manual Destructor and Constructor

This is a common source of bugs in C. In C++, a well-written class cannot exist in a bad state. In C, a struct can exist in a bad state. You have to worry about it. You'll get it wrong. Seriously, "manual Destructor and Constructor"? What you actually just said is that you will reimplement C++ yourself, badly, manually.

If you want to write in C, go ahead, but don't fool yourself that somehow you're doing yourself a favour by not having available safe techniques that allow you to easily and clearly do things that can be horrifically complicated in C. Don't fool yourself.

If you can't get these things right in C++, where the language is working with you to make it easy and safe, then how are you going to get it right in C, where it's much much harder?

[mbozzi]

I can't find any reason why industry uses C++?

Industrial practice has "inertia". The current practice is reliant on established practice, infrastructure, and experience, which can't just be thrown out. Industry changes so slowly that some of the original assumptions which prompted the use of C and C++ might no longer hold. They may remain a reasonable choice because there's already a system which works, people to operate it, and information about how to do it well.

Specifically, C++ has language features that excel in resource-constrained environments. Those with real-time constraints (i.e., the system must respond to event E in X milliseconds, or the requirements are not satisfied), long-running systems that require some degree of fault-tolerance, and systems which require careful and deterministic handling of resources.

Your average triple-A video game is a soft real-time constrained system with limited resources. Doesn't mean C is unsuitable, but that lots of important functionality has to be built by hand. In industry, this extra labor is likely to produce wrong code and generally waste money.

Unless you really just want to learn C, consider compiling C++ with exceptions disabled and limit yourself to the subset of the language you believe is acceptable. You will still benefit substantially from the additional checking a C++ compiler offers, even if you are writing C-like code.

Although I am inclined to agree with @Repeater. There is no objective reason (besides learning) to use C in this case. You will reinvent the wheel, badly.

[mbozzi]

By the way, you are not obliged to follow industry on this. If you tried C++ and didn't like it, go try Python or something.
https://www.pygame.org/wiki/about
Industry's concerns are different than yours. Industry is concerned with software which is a couple orders of magnitude larger than anything one person could reasonably produce.

[jonnin]

there is not one thing C can do that C++ can't. It might be microscopically faster in a few places; vectors for example do allocate and manage memory and track size which a pure pointer won't do, and that costs (the biggest cost being memory allocation and destruction which can wreck a program if careless, but has next to zero impact if you do it right).

You can argue your points all over the place if you have a bias, making one seem better.

Lets take point #1. Inheritance is over-used and its a pain, yes, but it is a powerful tool when used right. Examine your statement again. If you don't need it in C, you didn't need it in c++ either, so that's a wash. If it created bugs, you did it wrong. That is like saying C sucks because you bungled a pointer and those are too hard to learn. (I don't agree with that, but one can argue it). The problem is bungling the code, not the tool. A wonderful slogan, and words to live by... its better to have it and not need it than to need it and not have it. I can't see any rational argument saying its better to not have more tools.

or #2. Structs work just fine in C++. And you can give them a constructor to initialize them, or a copy function to assign them, etc which you have to do ugliness in C. Let me use one of my favorite things, a matrix, to illustrate why c++ might be nicer.

C:
matrixcopy(a, *(matrixmultiply(b,c,brows,bcols,crows,ccols)) , arows,acols);

or something awful like that just to say
c++ version:
a = b*c;

enough said. A big, multi year project I did with matrices, we picked c++ over the next 2 language choices just because of operator overloading support.

3) more of the same. you don't need templates? Don't use them. Get back to me when you write a data structure/container and have to make multiple versions of it or do screwy stuff with void pointers and enums with ever growing switch statements...

and #4 is really the kicker.
you can take almost any C program and change its extension to c++ and it will compile in a c++ compiler and work fine. There are a small # of tiny changes you may need to make, but they are simple (things like defaulted integer types, etc). Its not good c++, but its still legal. If you wanted to write it in c like c++ from the get-go, you can DO that. That gives you more tools and options if you need them, and if you don't, you can ignore them. I freely admit that I prefer printf and sprintf to C++ tools. Most everything else, not so much. It still bugs me to see cout << notavariablebutaformatter<<variable<<otherformattermess<<variable<< and you can't tell the variables from the formatting at a glance. At my age, it probably always will :P

[helios]

The Inheritance is a pain in the a*s. I have to fix bugs that didn't caused by me and don't need it

C++ is a multiparadigm language. There's usually more than one paradigm to solve a problem. Why are you using inheritance if you don't need it.

I don't need classes to create an (in this example) game engine I can use structs when I need Classes. And manual Destructor and Constructor

Right. You "don't need" classes. You just need something that behaves basically the same as a class, to the point that you're willing to write manually the code that a C++ compiler could have generated for you.

I don't need function overloading and Templates when coding a game engine

Let's look at a few of the features C++ has that C doesn't:

* RAII.
* Automatic memory management.
* Lambdas and closures, plus functional programming.
* A standard library with lots of useful functions and types, including commonly-used containers.
* Classes, OOP, etc.
* Function overloading.
* Templates.

"Need" meaning that you can't do the thing without it, do you need any of these features to write an engine? No, you don't. They do make the task easier, and they do make writing correct code easier.

[Ganado]

there is not one thing C can do that C++ can't.

The lack of a standard ABI comes to mind...

Totally agree formatting output is a bit weird in C++ compared to the good-ol' formatting options of C. But luckily, in my experience, proper formatting like that is only done in particular places and can easily be wrapped into a function so that you only have to worry about it the first time.

matrixcopy(a, *(matrixmultiply(b,c,brows,bcols,crows,ccols)) , arows,acols);

To be fair, the rows and cols could be part of the object itself, and not passed in. But true, you'd have to type out the function names instead of *.

The weirdest thing I've learned about C++ is that std::terminate is called when an exception occurs while the stack is unwinding from a previous exception being thrown. It's unlike any parallel in C, C#, or Java. (Luckily, I've never had to account for this sort of thing, but if you were programming a system-critical infrastructure that put people's lives at risk, there would be a hell of a lot more scrutiny in figuring out exactly what could go wrong.)

@memguy it seems you've come to a conclusion first and will stick with your belief unless some absolutely new revelation occurs. I agree C++ can be more complicated at times, but it also makes a lot of things easier than in C. It's fine if you prefer C, that's your choice. If you prefer C, then go ahead and make your program in C. Other people (in this thread) might simply disagree with you or make rebuttals, mostly because you invited them to.

Honestly, the language isn't as important as some might want to believe... the actual features and core logic of your program is what matters. It just differs in how you want to communicate and maintain those features. After you implement those features, the language could mostly just be seen as boilerplate.

[TwilightSpectre]

For the std::terminate issue: that only happens when you throw exceptions from destructors, which should be something you never do.

I will also note it does have a parallel with C# and Java; throwing exceptions from finalizers (aka. budget destructors that may or may not be ever run, depending on the whims of the garbage collector) will also lead to badness, since they're run on their own thread – who's going to catch it? You get the same net result.

As for formatted output; I would argue that in the general case C++'s output streams are much nicer to use than C-style printf. The lack of conciseness is well balanced by type safety, not having to remember the meanings of abstruse 1-4 letter codes, and support for user-defined types. They're certainly not perfect, especially for when you need very precise formatting, but for everything that I do they're the better option.

@OP: there are certainly some benefits for using C over C++; a simpler language, standardised ABI, larger support for embedded systems, and so on. The thing to note, though, is that using C will probably take longer and be more bug prone than using C++, since there are fewer opportunities for removal of duplication. Also, I'm not sure if this has come up yet, but C is not necessarily faster than C++, if that is your primary reason for preferring C.

[Ganado]

Thank you TwilightSpectre, I didn't know the details for how finalizers worked. I'll have to look more into that.

Yep, not throwing exceptions from destructors is a must. Theoretically, for example, std::fstream's destructor could throw if fstream::close() throws ( http://www.cplusplus.com/reference/fstream/fstream/close/ ). But if you're in such an environment where that occurs, then you'd have to just know to call .close() manually, I suppose.

Agreed, the type safety definitely makes the C++ formatting worth it.

[helios]

I will also note it does have a parallel with C# and Java; throwing exceptions from finalizers (aka. budget destructors that may or may not be ever run, depending on the whims of the garbage collector)

Finalizers and Dispose() methods are supposed to be called explicitly from a finally block, or in the case of C# implicitly by a using statement.
A piece of code that relies on the GC finalizing/disposing an object is incorrect, precisely because GCs have non-deterministic destruction.