Need other coders opinions on this C or C++?

[Mars_999]

I have been coding for awhile now and have been using C++ to code in. I have just started getting into OOP a little bit. Not sure what to think of it, I see how it can be awesome for games, but C is just as good. I only plan on coding games for maybe some apps for Mac. I have both "The complete reference C" and "The complete reference C++" books. I like how new and delete are used in C++ but don't like how I can use type casts the same way in C++ for pointers. I also like in loops being able to delcare a variable in the for() statement. I don't like not being able to declare variales close to their use either. I also remember reading somewhere that malloc() is prone to memory leaks? I don't want to spend time learning both languages do to it wasting my time. I dont' like how files are to be handled in C++. I like the C approach due to it uses functions to work with files. So I guess I am asking people what they like to use better and if they think it will take less time to master C than C++? Also the OOP thing if needed I can always down the road learn ObjC. Thanks all for the help.

[GoodDoug]

I'll just tell you my standard boilerplate for this issue:
Programming languages are simply tools. The more tools you have in your toolbox, the more efficient and effective you will be. To use a bad metaphor... yes, you can drive a screw with a hammer, but a screw driver will be much more effective. So, don't "choose" one language.

However, taht being said, C++ is a superset of C... learn as much C++ as you can and then learn the differences. But don't limit yourself. In my job, in any given day I can be coding in C, C++, Object-C, Perl, AppleScript, shell-script, Java, and now Python. I also know Haskell, lua, Ada and even a little Forth. Apply the right tool to the right job, and it will make your life much simpler.

[Jeff Binder]

I agree with all that GoodDoug said. Don't limit yourself to one language, and once you know a few languages well, you'll be able to choose the right tool for the job.

That being said, I'll try to address a few of your specific points.

If the "The Complete Reference C" book you have is the one by Herman Schildt, you should be wary of the examples. From what I've heard and seen the book contains many misleading errors. I would recommend, as always, K&R (http://www.amazon.com/exec/obidos/ASIN/0131103628/qid=1027646804/sr=2-1/ref=sr_2_1/104-9457929-0199927).

If you want to keep variables near where they're used in C or Obj-C, you can put it inside its own scope, like this:


void foo() {
do something...

...

{
int bar;

do something with 'bar'...
}
}


malloc() is no more prone to memory leaks than new. What you were probably reading is that if you don't free() something you malloc(), you get a memory leak. It's the same thing that happens if you don't delete something you new.


Personally I might use plain C for a small program where speed is important, because it's simpler and slightly faster than C++. OOP doesn't really become useful until you get into medium-sized programs.

I usually prefer Obj-C for applications and C++ for games. C++ is faster than Obj-C, and has some features that are especially useful in games. Obj-C, on the other hand, has dynamic binding and dynamic typing, which is always a pleasure to work with, although they seem to help the most in GUI-intensive apps. These features also make it hard every time I switch from Obj-C to C++ ;) .

Remember this is just my opinion.

And of course, there are many other languages that are all useful in other circumstances, but we don't need to get into that here.

[Mars_999]

I have decided to stay with learning C++. I have been learning it for quite sometime. I just like to many things about C++ to go back to C. I just like using classes. God they work great for game programming. I understand learn as many languages as possible but if all I want to do is make games or write some apps here and their C++ is perfect. The right tool for the job. I know understand why C is somewhat not liked for large projects due to the code becoming complex very fast. Game development has many, many lines of code. So off I go to learn OOP and be done with it. Thanks all for the advice.

[wadesworld]

Well, for a single-programmer project, I'd say there's really nothing in the way of complexity that requires OOP.

C can get unwieldy if you're not careful, but so can C++. IMHO, where C++'s advantages become really compelling is on larger projects (2 or more people).

One thing to be aware of is whether you're using OOP, or you're using an OOP language for procedural programming. It's certainly possible to create objects that are nothing more than containers for functions and still used in a procedural way. In fact, this is a mistake many C programmers make when transitioning to C++. OOP requires a whole new way of program design.

As a final note, when I program in C, I still use .cpp files so I'll have the additional benefits of the C++ compiler, even though I'm not using any OOP features.

Wade

[OneSadCookie]

... and when I program in C, I make sure to name all my files .c so that I can't use any evil C++ features, but I still program in an object-oriented way.

Incidentally, the C99 standard allows // comments and variable declarations anywhere, including inside the for loop header, so that's the two most important features of C++.

[Codemattic]

Well, for a single-programmer project, I'd say there's really nothing in the way of complexity that requires OOP.

Gotta totally disagree with you here. C vs C++ doesnt have to do with how many people work on a project - but what kind of problem you are trying to solve. There are lots of single person projects I can think of that I wouldnt want to do in C. A lot of game design works better in oop.

I usually prefer Obj-C for applications and C++ for games.

agreed. I write my engine/game code in C/C++, but then write the game editors/tools etc.. with Objective-C/Cocoa for the gui which can call the C/C++ code. Objective-C/Cocoa is fun fun fun.

cheers all,
Codemattic

[Jake McArthur]

Mars, you seem to think that the format for something in C++ is different from that of C. While you can do so many more things in C++ than in C, everything that you can do in C you can also do in C++. That is, if you run a file with only C source code in a C++ compiler, it will compile exactly the same way as if you had used a C compiler.

Now, as far as my decision as far as programming languages go, I love the simplicity of Objective-C, but it lacks things that make C++ work so great for games. If you intend to program for Cocoa, you will have to learn Objective-C anyway, but you can combine C++ code with it. I like C for short simple programs, usually when I am just testing out some code that I will later put into a bigger project coded in C++ and/or Objective-C. Actually, now that I have gotten more into Objective-C, I have been using straight C less and less because it is so easy to make a GUI with Cocoa/Objective-C, and I have never been a big fan of making command-line apps.

[JeroMiya]

You need to be somewhat careful when it comes to performance claims as to C++ being faster than Objective C or slower than C. First of all, the language you use is one of the last things that affect performance. The first being your algorithm design. That being said, you wouldn't want to write a math library in Objective C.

One thing about C++ that makes it great for games is the inlining mechanism (whether auto-inlined or explicit inlining). It is absolutely possible in C++ to design many objects that operate exactly as fast as the same objects implemented in C (using procedural or other C design techniques) and yet they still operate like any other object. STL is like this (most implementations anyway).

Also, when it comes to game engine design, there are relatively few performance critical sections you need to worry about. Math libraries and objects which are instantiated in the thousands or hundreds of thousands are good candidates for inlining and optimization. Other parts, even things like the event driver, are not (as) performance critical. For example, I think GLUT on OSX is driven by an Objective C event driving mechanism (using the Core Foundation rather than Cocoa). These sections would not benefit much, if at all, from using one language over another.

So... I think the moral of the story is that C++ can be used even for performance critical game code, while Objective C is still a viable platform for most non-critical sections of game code.


Jeremy Bell
WolverineSoft Project Coordinator
www.umich.edu/~wsoft

[davecom]

I agree with everything you said, but Core Foundation is not written in Objective-C .

[OneSadCookie]

As far as I know, CoreFoundation on OSX is indeed written in Objective C. The OS 9 version isn't. GLUT just plain uses Cocoa, though. The source to GLUT is available from Apple's website.

[davecom]

From Apple's developer site under 'Overview of Core Foundation':
"Core Foundation is a library with a set of programming interfaces conceptually derived from the Foundation framework of the Cocoa object layer but implemented in the C language."

[OneSadCookie]

The API is C, and there is a C implementation (used on OS9 and possibly plain Darwin), but there's either all sorts of hack magic going on in there, or the OS X version is implemented in Cocoa.

CFString* myCFString = CFSTR("Hi");
NSLog("%@\n", [(id)myCFString class]);

prints "NSCFString" or similar. Likewise, most other CoreFoundation objects can be treated as if they were the Objective C objects with similar names. I believe (though I don't actually think I've tried it), that Objective C objects can be passed back to functions expecting CoreFoundation objects -- ie, you could pass an NSDictionary* to a function expecting a CFDictionaryRef.

[davecom]

This is all part of a wonderful bridge that Apple built, but I think that you should just admit that you were wrong. Core Foundation is most definitely plain old C in both 9 and X.

[OneSadCookie]

There's no point in arguing. The answer is somewhat irrelevant, anyway, since CoreFoundation can be used "natively" from both Objective C and C. A Foundation object is a first-class CoreFoundation object, and a CoreFoundation object is a first-class foundation object. Who cares whether the names of the actual implementation files sitting somewhere in Cupertino used to produce CoreFoundation.framework end in .h or .m?

[OneSadCookie]

After examining the two frameworks' object files, it seems that CoreFoundation is indeed implemented in C even on OSX, and that by and large Foundation is implemented in terms of CoreFoundation.

Why Apple would go to the trouble of building a fancy bridge when they could have solved the object-compatibility problem by implementing CoreFoundation in terms of Foundation, though, is beyond me. Perhaps for reasons of avoiding code duplication between X and 9, but I would have thought that there was little that could be shared anyway...

Anyway, I admit, it looks like I was indeed wrong.

[Mars_999]

Ok, I appreciate everyones input. I have this to add. If I don't use any OOP at all for game programming wouldn't I be better off learning C then? Since C has less to learn than C++ would if you were to learn all of C++ e.g. OOP aspects? I am wondering does anyone know if Doom3 or Unreal 2 are written in C or C++? I would like to get a good idea of how many games today are coded in C still or C++. If I see more games done in C++ that would suggest that C++ is better? My problem is, I am going to college still and have CSC 3 to finish. That class uses the OOP aspect of C++. If I drop C++ now and go to C I still have to learn OOP to finish that class. But I might be able to drop that class and pickup Java instead? So if I can pickup Java instead I would most likely learn C and quit persuing C++. Argh I just want to finish learning a language, so I don't need help with it anymore and can move on to coding in OpenGL or someother API without trying to figure out some stupid syntax errors or how to do something with the language to accomplish something. Thanks all.

[OneSadCookie]

If you don't use any OOP, you might well be better off with C than C++ -- but if you don't use any OOP, you're making life hard on yourself ;)

Unreal uses C++, so I assume Unreal 2 does as well. Quake III uses C, but I believe Doom III uses C++. Not 100% sure on that, though.

[henryj]

Couple of things...

You will never finish learning a language (unless your a freaking genius like OneSadCiookie), especially object oriented languages.
Java is totally oop. Java deliberately makes it hard to write proceedural code and if your doing a class on Java they will teach oop.

Sounds like what you need is a quick reference guide to C. The best one is K.J. Bricknell's Essence of C. The guy who wrote the Carbon book. It's available in a format of your choice from...

http://www.themost.org/courses/langs/eoc/

After 5 years of c++ programming I still look at this occasionally.

[OneSadCookie]

Bah.

There are still plenty of things I don't know about C, and that's a language it should be possible to understand completely.

Much of C++ is still a complete mystery to me, and I suspect it always will be. I don't believe anybody (not even Bjarne Stroustrup) completely understands C++.

[Mars_999]

Haha that make me feel better about using C++ then. =) Knowing that no one is a master of it all. Except for onesadcookie. ;) I am mostly talking about the features of C++ I dont' see no reason to learn for games. e.g. namespaces stuff, templates, RTTI, STL. I love classes and they are the only reason I haven't gone to C totally. But aren't classes a huge part of OOP? OOP is just style of coding.

[OneSadCookie]

Learning the basics of templates and the STL will greatly improve your C++ productivity.

RTTI is so easy as to be a non-issue, though I've never used it for real in a program.

Namespaces are also pretty much as easy as putting std:: (or MyNamespace:: or whatever) in front of a few names.

The real black spots of C++ are multiple inheritance, templates beyond simple type-parameterization, constructors & destructors, type conversion, &c.

[Mars_999]

Hey cookie I thought you didnt' like C++ as much as C? =) One thing is I don't think I like C++ file I/O as much as C. I am confused how one could make C somewhat OOP style? You need to have your functions included with your classes like C++? Or you suggest putting all your ()'s in a file with the data? and calling variables extern like? I guess I am confused how one would make C OOP like? BTW did you order your new PowerMac? Later

[OneSadCookie]

I don't like C++ as much as C. I find it ugly, and often confusing.

That doesn't mean I don't know when to bite the bullet and use it.

http://203.79.121.211/~keith/intro_to_c.html outlines my philosophies on how to make C more object-oriented. I wrote it for a university course I did where we had to program in C (rather than C++) in response to the panic from the other students.

[Mars_999]

Actually C99 does have support for bool types. You have to include the stdbool header not sure the exact name of the header is though. I find C++ after classes confusing. I haven't gotten into virtual ()'s or multiple inheritance. Friend ()'s and all that jazz. If I remember right this is how I need to define a struct and declare one in C?


struct FOO
{
int a;
float b;
};

int main(int argc, char *argv[])
{
struct FOO foo;
return 0;
}


I might be wrong on this! I have another question on classes and structs though. I see that all struct and classes are defined in global scope? But the defined classes and struct are not actually allocating memory until they are declared? Is this right?

[OneSadCookie]

Actually C99 does have support for bool types. You have to include the stdbool header not sure the exact name of the header is though.

<stdbool.h>, yes.

The compiler we were using was GCC 2.95.2 or something, so didn't support C99. I also didn't know how standard <stdbool.h> was.

[Mars_999]

I guess it was made to help be compatiable with C++ bool types. I just tried it and it works fine except the IDE don't change "true or false" or "bool" to a keyword as it does it C++ but thats due to it being defined in the header. ;) Anyway I am doing some messing around with C/C++ to decide which I like better.