Archived

This topic is now archived and is closed to further replies.

Does anyone use C?

This topic is 5485 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I have just recently learned C programming, and upon visiting this site, i have not been able to find anyone that is developing a game Using C! If anyone is out there and uses C please post here, it would be even better if you were interested in making a game, becase so was i! i have a fairly good drasp on the language and i think a project would help tone my skills!

Share on other sites
C is a good programming language, but if you want to do games and stuff it might be a good idea to learn C++. You''ll need the classes and the object oriented stuff in C++ to make it all a little easier. A lot of people (I think) use a combination of C and C++ so they can use classes and such.

Share on other sites
quote:
Original post by danger_boy_13

A lot of people (I think) use a combination of C and C++ so they can use classes and such.

If you use classes and other C++ features, then you really aren''t using C at all but the C-like backwards compatibility features of C++.

There is nothing wrong with using plain vanilla C to write a game - take a look at the Freespace 2 code which had been released. As far as I remember (taking in to account that my memory isn''t that great) that was written in pure C, as was Quake.

Jx

Share on other sites
I''m using C for a cel-shading renderer. Note: if you plan to use DirectX, you won''t get a choice.

C - God''s programming language. (Redbook)

Share on other sites
Yeah I think Jx is right. id seems to prefer C, probably because there''s a speed advantage. So there is at least one big developer out there who hasn''t hopped on the (not quite) O-O bandwagon, with good results.

Share on other sites
quote:
Original post by easlern
Yeah I think Jx is right. id seems to prefer C, probably because there''s a speed advantage. So there is at least one big developer out there who hasn''t hopped on the (not quite) O-O bandwagon, with good results.

id uses what Carmack calls "C+". A mix between C and C++. Even JC knows that you can''t ignore some of the benefits of using some of the C++ features.

You can also consider the fact that anyone that has gotten a look at any of id''s source code considers it hard to follow, and generally bad. It''s been labeled "carmack code" and the term isn''t used to praise someone.

As for Object Oriented, I''ve seen games written in Object Oriented C (not C++). And it''s quite dirty but it gets the job done. So you don''t need to use C++ to do OO programming but it does make things alot easier.

Share on other sites
Why do you say you can''t use C with DirectX? I don''t have much experience in DirectX, but I do in COM and you can use COM from C. From what I''ve seen the D3DX library in DX8 supports C++ by adding operators and stuff by subclassing C structs provided by DX - but all the supporting maths functions etc are plain C and you can use the original C structs. Am I missing something?

Share on other sites
Nope, it''s absolutely possible, not even hard, to code for D3D in pure C. I use C++ mostly though.

Share on other sites
Yeah, sorry, I was refering to "if you plan to use DirectX, you won''t get a choice"

Share on other sites
quote:
Original post by easlern
id seems to prefer C, probably because there''s a speed advantage.

There is no discernable speed advantage between C and C++. Anyone who says otherwise is either a zealot or ignorant (probably both).

-Mike

Share on other sites
Hi!

I use C++ myself, but it''s not because i think that C is a poor language or anything like that.
C is a great language to program games in, and it was in C that i started learning about game programming.

I simply prefer C++ because im a fan of OOP, and im more comfortable with it than C.

I do however, recommend that you also learn C++, and then see for yourself what works better for you.

That applies to alot of other stuff, that even if someone tells you that one thing is better then another, you should always try it out for yourself and make up your own mind if you are unsure.

Though, i dont mean that you should never listen to what other people say about things, just that if you are unsure about it, do some research and make up your own mind.

When it comes to perfromance differnces between C and C++, i dont think there is very much difference. I havent done any tests on this myself though, but ive heard from several people that C++ programs are the same as C when it comes to speed.

However, that always depends on how you compare them, cause i dont think that you can, for ex, take to 2 games, one written in C and one in C++, and if the C one is faster, make the conclusion that C is a faster language.
Becaues it completly depends on the code, and how the 2 game engines where designed.

Share on other sites
quote:

There is no discernable speed advantage between C and C++. Anyone who says otherwise is either a zealot or ignorant (probably both).

Actually, there is. Such a general statement ('there is no difference') is ignorant.

C++ offers a lot of new functionality. Some of this functionality comes with an additional overhead. Some does not. If you are after speed, then it's very important to exactly know what features will introduce overhead. Some of this overhead might be very small, other very large, it also depends on where your bottlenecks are.

Examples:

* virtual functions: introduce a slight overhead, for a virtual table lookup.

* RTTI: depending on how you use it, and the complexity of your class hierarchy, it can introduce pretty large overheads: from simple table lookups, to hierarchical tree walks. Use it wisely.

* Exceptions: Depends on the compiler. Generally, there is a very large overhead, when an exception is thrown. On normal operation, there is typically a small overhead when entering and exiting functions (as additional information needs to be pushed/poped from the stack) and there might be some overhead, when constructing objects (the system needs to keep track, to ensure proper calling of local destructors while unwinding).

* overloaded operators can introduce overheads, if they are not well designed. They will often create and use temporaries, that would not be present in comparable legacy C code. The optimizer can catch a lot, but not everything. It depends on the experience of the programmer.

* copy constructor + assignment operator: not inherently slower, but very easy to abuse. Bad cctor design is a major performance sink in larger applications.

Some other features also show minor overhead. The STL, while being very convenient to use, is very dangerous in terms of performance. You should know exactly what you do, before using it in performance critical situations.

C++ features that do not influence performance are, among others, templates, namespaces, non-virtual class functions, plain data classes, member access protection, etc.

A C++ programm can be just as fast as a comparable C program, if you know what you are doing. Let's state it this way: C++ is not inherently slower, but it's easier for an inexperienced programmer to write slow programs in C++ than in C.

[edited by - Yann L on February 7, 2003 11:45:40 AM]

Share on other sites
Oh yea, one more thing...

You dont have to use OO techniques and philosofies( <-spell ?? ) when you program in C++, if you dont feel comfortable with them.
C++ isnt a "true" OO language, its a procedural language with OO extentions.

Alot of people find OOP hard to grasp. But dont be afraid to learn it, it isnt a monster .
Some people might tell you that OOP is beast of satan, and will create code of unbelivable horror
Well, part of that can be true at times, because a poorly designed OO program can be very difficult to understand and maintained.
However, that usually results from poor understanding of OO techniques and principles.

[edited by - JackRabbit on February 7, 2003 11:51:59 AM]

Share on other sites
The virtual function argument isn''t that straightforward. Although I agree that you have an extra de-reference for a virtual function, I''d argue that virtual functions are used to run different code for different types of the same class of object - to do this in C you''d have SWITCH statements or IFs - both of which have an associated overhead - comparison and jump.

Exceptions - are really just another parameter put on the stack aren''t they? Much like a return value - if you pass small objects or references then surely there isn''t that much overhead?

Share on other sites
quote:
Original post by Yann L
Such a general statement (''there is no difference'') is ignorant.

I never said there was no difference. I said that there is no discernable performance difference. Although I should say that my statement was rather simplistic in relation to the complexities of the C vs. C++ argument.

quote:
Original post by Yann L
C++ offers a lot of new functionality. Some of this functionality comes with an additional overhead. Some does not. If you are after speed, then it''s very important to exactly know what features will introduce overhead. Some of this overhead might be very small, other very large, it also depends on where your bottlenecks are.

I agree.

quote:

* virtual functions: introduce a slight overhead, for a virtual table lookup.

This is true, technically. However, whenever you use virtual functions in a C++ program, think about what code you would have written for a comparable C program. That virtual function call would have to be replaced with a switch, an if...else, or a while statement. This is one reason why people should be careful when comparing speeds between different languages (especially C and C++).

quote:
Original post by Yann L
A C++ program can be just as fast as a comparable C program, if you know what you are doing. Let''s state it this way: C++ is not inherently slower, but it''s easier for an inexperienced programmer to write slow programs in C++ than in C.

I totally agree.

-Mike

Share on other sites
quote:

The virtual function argument isn''t that straightforward. Although I agree that you have an extra de-reference for a virtual function, I''d argue that virtual functions are used to run different code for different types of the same class of object - to do this in C you''d have SWITCH statements or IFs - both of which have an associated overhead - comparison and jump.

That''s why there is no straight comparison between a C++ and a C program. Both can have equivalent functionality, but they are designed using a different programming model. But some people seem to think that those OO features (esp. polymorphism) comes for free. That is not the case, although the overhead is not that large. But you have to know about it, if you want to develop high performance applications.

quote:

Exceptions - are really just another parameter put on the stack aren''t they? Much like a return value - if you pass small objects or references then surely there isn''t that much overhead?

At normal operation (ie. calling a function with exception handling enabled, but not throwing any), the overhead is minimal. But it is large, when an exception is thrown: the stack unwinding, along with the processing of local destructor tables (when the stack unwinds through a function, then all the objects locally created need to be destroyed) will take some time. This is no problem, if you adhere to the ''an exception is an error'' concept. In case of an error, an overhead is secondary. But some people use exceptions in normal code flow control, and that is very dangerous.

Share on other sites
Yeah - but as you say if you''ve caught an exception then something is wrong and you should close down anyway - so the performance hit isn''t really an issue - I wouldn''t use exceptions for anything that wasn''t going to put an end to the process eventually.

I think we all agree that C++ used knowledgably can hold it''s own in terms of performance, but used naively it wont.

Share on other sites
quote:
Original post by Anonymous Poster
I think we all agree that C++ used knowledgably can hold it''s own in terms of performance, but used naively it wont.

I concur.

Share on other sites
neverwinternights was developed in c, so it is not entirely useless. c++ is a superset of c, so if you try to learn c++, it should be easy.

Share on other sites
I use both. I don''t why some people call it "dumb" to combine these two. They are both equally powerful, they both have advantages and disadvantages. And since I came from C to C++, I see both languages wonderful. OOP features is something that you can''t miss. C procedural system is also something that I can''t miss.

500x(too many to count)

return 0;

Share on other sites
(. . .It''s absolutely possible, not even hard, to code for D3D in pure C. . .)
That''s cool- I wasn''t aware of that. I haven''t used COM before.

(I think we all agree that C++ used knowledgably can hold it''s own in terms of performance, but used naively it wont.)
I''ll agree.

Share on other sites
"Some people might tell you that OOP is beast of satan, and will create code of unbelivable horror"
Well, part of that can be true at times, because a poorly designed OO program can be very difficult to understand and maintained.
However, that usually results from poor understanding of OO techniques and principles."

"I think we all agree that C++ used knowledgably can hold it''s own in terms of performance, but used naively it wont. "

So why do you want to make more work for yourself in the name of OOP?!
Why open your project up to more possible bugs that can result from using more complicated/quirky/misunderstood C++ "features" ? I don''t know, I don''t see many advantages to using C++ over or with C yet, besides it''s classes and somewhat easier organization (but even that can be done just as well in pure C)
If you can write something working and very understandable in C, why would you want to use C++ features? I''m not bashing C++ but man it added a LOT to C and to me it seems a bit cluttered with many things I will never need to use.

Share on other sites
quote:
If you can write something working and very understandable in C, why would you want to use C++ features? I''m not bashing C++ but man it added a LOT to C and to me it seems a bit cluttered with many things I will never need to use.

Well wriiten C is easy to start out on, moderately easy to complete, and fairly hard to maintain in the long term. Badly written C++ (read: C++ written by a programmer who is not skilled in C++) is hard to start on, even harder to complete, and an absolute horror to maintain in the long term. Well-written C++ is hard to start out on, easy to complete, and very easy to maintain in the long term.

Don''t listen to me. I''ve had too much coffee.

Share on other sites
C is not currently a subset of C++. There are language constructs in C that are not legal C++, and vice versa. Some of the C specific language constructs offer performance enhancements that are not reproducable by a fully compliant compiler using only standard C++. For example: the restrict keyword (introduced in C99) when applied to two or more pointers signals that the pointers are free from aliasing conflicts, which can prohibit optimizations from data flow analysis or software pipelining. Another example: C variable length arrays (also introduced in C99) can be allocated on the stack which offers better spacial locality than heap based allocations without the same fragmentation issues (or locking issues, or best fit/worst fit issues, etc.)

Share on other sites
There are plenty of people who use C. I use C. I personally find C more interesting than C++. OOP doesn't do much for me. It's nothing to worry about, don't trouble yourself with the question "Which on is better?" because it can't be answered. Just use the language you like better (or both, there's nothing wrong with giving it a little whirl ).

EDIT: If you are curious about writing programs that use both C and C++(or even just C), I recommend getting H&S. It shows you how to correctly write C++ compatible C programs. Great book.

------------------
There are 3 kinds of people in this world: Those who can count, and those who can't count.

[edited by - Fucho on February 8, 2003 2:57:04 AM]