C vs C++

[Jeimuzu]

Well I am new to programming (and making hacks, bots.)

I am wanting to know if C or C++ does the job better.
It's confusing to know which one for memory editing, I am thinking of C however I want your guys opinions.

[Sychotix]

C runs runs alot faster and can do anything C++ can, whether its in 1000 lines of C code vs 10 lines of code in C++ or not. C++ Runs on windows and is easier to program in.

[Jeimuzu]

C runs runs alot faster and can do anything C++ can, whether its in 1000 lines of C code vs 10 lines of code in C++ or not. C++ Runs on windows and is easier to program in.

How is C faster? Sorry, new to C and C++ languages.

[LordJZ]

Not really *THAT* faster to make it count when not programming nuclear bomb control units, really.

[Cypher]

C runs runs alot faster and can do anything C++ can, whether its in 1000 lines of C code vs 10 lines of code in C++ or not. C++ Runs on windows and is easier to program in.

C is not necessarily faster. In some cases C++ will outperform C (e.g. Boost.Spirit vs atoi, std::sort vs qsort, etc), largely thanks to templates and inlining.


It all depends on what you're doing... Since he's specified he's writing game hacks, and most games nowadays are written in C++, I'd recommend learning C++. Using C++ will make both interfacing with C++ targets easier, and also help with reversing new games as you'll understand the code a bit better (e.g. when you see the usage of things like templates, exceptions, etc in the code you're reversing).


P.S. Technically C++ can do things that C can't. You can still solve all the same problems in C, but you can't solve some of them using the language alone like you can in C++, you will need to add a build step or something like that. That being said, such scenarios are quite advanced, and you're unlikely to come up against them unless you're doing advanced library dev.

How is C faster? Sorry, new to C and C++ languages.

The higher the level of abstraction you're working at, the higher (theoretically) the abstraction penalty. That being said, for the majority of features the penalty is extremely low, and most programs aren't CPU bound anyway.

[_Mike]

C runs runs alot faster and can do anything C++ can, whether its in 1000 lines of C code vs 10 lines of code in C++ or not.

<Any language> runs alot faster and can do anything <some other language> can.
Implementation limitations have nothing to do with the languages themselves. The "fastest" language is the one you know the best and are most comfortable using.

C++ Runs on windows and is easier to program in.

Easier is a subjective term. As for running on windows; Again, implementation details.

[Sychotix]

How is C faster? Sorry, new to C and C++ languages.

C++ has to do alot of stuff behind the scenes, such as constructors and destructors. C does not.

EDIT: seems like Cypher came in an answered the question already =P

[flo8464]

C++ has to do alot of stuff behind the scenes, such as constructors and destructors. C does not.

You know that constructors/destructors just save you from writing initialization/cleanup code yourself, right?

The main problem is that C++ forces you to copy often.
References and especially move semantics make your life much easier, but you have to watch out.
C does no deep copies "automatically", you basically pass everything per reference. (This is a disadvantage)

The higher the level of abstraction you're working at, the higher (theoretically) the abstraction penalty. That being said, for the majority of features the penalty is extremely low, and most programs aren't CPU bound anyway.

Don't forget that Bjarne Stroustrup is a performance freak and "you don't pay for what you don't use" is one of the keypoints in C++ philosophy.

[Cypher]

You know that constructors/destructors just save you from writing initialization/cleanup code yourself, right?

The main problem is that C++ forces you to copy often.
References and especially move semantics make your life much easier, but you have to watch out.
C does no deep copies "automatically", you basically pass everything per reference. (This is a disadvantage)

I was going to make the same point about constructors/destructors. I fail to see how code which you'd have to write anyway counts as 'overhead'. But I digress...

I wouldn't say that C++ 'forces' you to copy often, however it certainly makes deep copies a lot easier to do 'accidentally'. Avoiding copies is the primary reason 'reference-to-const' is usually the recommended way to take parameters you don't intend to modify (unless they're integral or other very cheap to copy types).*

That being said, with RVO/NRVO, and the new move semantics in C++0x, excessive copying is likely to become a thing of the past.

Don't forget that Bjarne Stroustrup is a performance freak and "you don't pay for what you don't use" is one of the keypoints in C++ philosophy.

Of course. My point was that abstractions usually have penalties. If you choose not to use that particular abstraction though, then there's no penalty.

The only exception to this really is exceptions. You would pretty much have to avoid the STL entirely in order to not 'pay' for exceptions, but on newer platforms (e.g. x64) the penalty for exceptions when no exceptions are thrown is actually zero (ignoring the extra memory taken up by the EH and unwind table in the file headers).

In fact, when no exceptions are thrown, on x64 and similar platforms, code which uses exceptions rather than return codes will execute FASTER. This is because no return checking needs to be done, and you only pay for error handling when an error actually occurs and the OS has to look up and call the handler(s) for your function.

Even on x86 though, which still uses stack-based EH, the penalty is extremely low, especially if you're not using it in your application.