View Full Version : C vs C++ ?!

04-22-2002, 12:00 AM
this is little of topic.. but I still want to know which language you are using ?

every .tar file loader and 3ds file loader and .ase file loader I have found use C code.. fprintf, fread and so on.. thats C code right ?! why isn't there anyone with C++ source ? using ifstream/ofstrem?

when you write a file loding code wich one do you use ? C or C++ (fread or fstream) or anything else..

and then what is the difference.. is anyone faster to read or something like that ? or is it just what the person who write the code wants to use?

I use fstream to everything.. it is easier to understand and to use.. but it is hard to convert the code I found who use fprint stuff..

04-22-2002, 02:25 AM

04-22-2002, 02:46 AM
I've started using streams lately, cos you can do cool things transparently, when you derive your own file stream operators for classes.

They are significantly slower than C libs for most implementations tho..


04-22-2002, 02:53 AM
i think that this will start an old topic, C or C++. Personaly, i like C 'cos its much easier to read it (i think here on algorithms), and it's much faster than C++ (many,acculay, as i know all rendering algos and methods (let say raytracing) using C).

But, as you probably know, C++ is better for larger projects, that dont require speed, and require maintaining.

some C stuff are more powerful than C++ (also much unsafety), for example printf and cout http://www.opengl.org/discussion_boards/ubb/smile.gif

04-22-2002, 03:57 AM
Saying C is much faster than C++ is completely wrong. Certain things are slower, but provided you know how to write C++ code properly, they both run pretty much identically in speed.

Provided you have a decent compiler of course.


04-22-2002, 05:13 AM
The question shouldn't be: what shall i use 'C' or 'C++' or whatever language..
But -> Why should i use C,C++ for?


or read this for a complete briefing! ;)) http://www.orkysquad.org/main.php?xtra=Programming_rules

04-22-2002, 05:41 AM
Is there any difference in C and C++ code layout? or is it the functions that are different ?

and ofcourse you can mix them and use both.. but I wounder why do that if they do the same.. if it is a big speed difference then I understand but if the speed is the same then it has to do with the programmers choice of language I guess.

but I think the C++ is easier to use with the class stream things... mostly I use it to read and write files becouse it is easy.. I don't get the fread thing to work the way I want to.. but the fstream thing works perfectly.

04-22-2002, 06:58 AM
The only real thing that makes C++ slower than C is the extra overhead that C++ code often produces. What I mean is that depending on the code C++ may have to make decisions about the type of object during run-time. Things such as templates tend to enlarge code. Generally the code inside of a C++ function is basically C code. Its just that in many situations there is extra overhead in getting into and out of the function. Largely in cases where constructors and deconstructors get called upon entering and leaving a function.

Please make not that this is a generalization. The speed of C++ versus the equivalent in C is largely related to exactly how the C++ code is written.

I personally use C. C++ in my opinion has way too many compatibility problems across platforms and compiliers. Generally if you avoid using features that cause incompatibilities I find you are right back to almost pure C code. So whats the point ?


04-22-2002, 10:32 AM
"Saying C is much faster than C++ is completely wrong.",
hm... like Devulon sais, and i must agree, C++ "features" take little bit more memory than pure C. Also, like you said, it depend on compiler, and how it implement C++ routines.
But, generaly, algos are written in C or in assm http://www.opengl.org/discussion_boards/ubb/wink.gif.

04-22-2002, 10:40 AM
c++ is not slower for the same thing.. but different implementations of stuff are slower.. like the streams cout,cin,fistream,fostream (thats how they are named, not?)

and i always use fwrite fread for binary files and fprintf for textfiles (only logfiles, so no reading needed.. guess for reading the fstreams could be cooler..)

and, if you don't knkow the difference, how about learning it? books are out there everyhwere explaining c and c++

04-22-2002, 10:41 AM
bah.. you're all living in the past. The last system I worked on that had crappy C++ support was the dreamcast. PS2, and GC, and Xbox, and PC all have great C++ support.

C++ may have to make decisions about the type of object during run-time

Thats correct if you use RTTI, but I dont, and I dont think many ppl do either, as you can still work around it, and you only ever need it if you use multiple inheritance, which IMHO if you're using, you need to redesign your class hierachy.

I dont use templates much either, they do increase code size, but thats all.

C++ is the future, its fast, efficient, and easier to use on big projects. Get used to it.


04-22-2002, 10:52 AM
I prefer, for file IO, fread/fwrite for binary. They are much easier to use than the iostreams for binary files (and I tend to build up binary images in memory and blast them out to disk). For text, I like printf when I'm not using std::string, but I use the iostreams for file IO on text files.

04-22-2002, 11:03 AM
Well I dont use stream for text, cos that is slow..

But building binary images on disk is not portable, as you can't be sure of the alignment on another development system. Reading in low level ints, shorts, bytes, floats, and storing them yourself is portable.


04-22-2002, 11:24 AM
You all discuss about using different functions and features of C/C++, but you miss the really important point: C++ is object oriented, while C is procedural. It is a completely different way of designing software.

It doesn't really matter what functions you use for IO, you will get (nearly) the same performace. But when you design a product object oriented you have to write it in C++ (or Java, ...), otherwise you can use C.


04-22-2002, 11:36 AM
Just to be an awkward bas, I'm going to disagree, and say you can write object oriented code in C.

You can even put your function prototypes in struct's, to hide the functions from being global. You dont have constructors obviously, but I rarely use them anyway.


04-22-2002, 11:46 AM
I don't how know popular it is, there are commerical applications which are written in C but their designs are OO.
You may miss some of the features in C++, but there is nothing to prevent you from implementing your owned virtual function tables, C structs with function pointers as elements etc.

04-22-2002, 11:59 AM
structs with functionpointers are not members.. you'll have to pass over to them the this-pointer anyways..

why using c for it if c++ does the same but with less coding work? ok, because you love c.. but anyways..

04-22-2002, 12:09 PM
I dont mean to flame you all, but I just need to defend my

favorite language and its really great features http://www.opengl.org/discussion_boards/ubb/smile.gif

Thats correct if you use RTTI, but I dont, and I dont think

many ppl do either, as you can still work around it,

In fact RTTI is one of the most cool things in the OO

programing - the performance difference between writing virtual

function which returns something like class id and using

dynamic_cast is negledible and dynamic_cast is _really_ far more


and you only ever need it if you use multiple inheritance,

which IMHO if you're using, you need to redesign your class


Multiple inheritance is more than great - using it with RTTI

gives you ways to split up large classes in more elegant

parts, to reuse code better, to make and check interfaces and to reduce compile times in large projects. However virtual multiple inheritance is in fact dangerous and should be used carefully.

I dont use templates much either, they do increase code size,

but thats all.

In fact they do it, but that it is not all http://www.opengl.org/discussion_boards/ubb/smile.gif
Using templates is superior to writing macros - it much more safe, easy to debug, and in the case of a good compiler, you have perfomance even better compared to C! Look at SGI STL. STGL and most ot the contemporary math libraries are writen with templates.

C++ is the future, its fast, efficient, and easier to use on big

projects. Get used to it.

I completely agree with this http://www.opengl.org/discussion_boards/ubb/smile.gif

Where are the problems:
Bad implementations with many compilers - especialy on templates. exceptions are cool, but too slow. Changes in interfaces, basic classes imply long compile times(Java is very cool here). streams are very slow really implemented - use printf, fprintf and etc..

This is really very _brief_ defence of C++ and its features - I can talk one night about this, if I had the time http://www.opengl.org/discussion_boards/ubb/smile.gif


04-22-2002, 12:24 PM
Fair enuff.

Where I work, we prefer not to have the overhead of RTTI. And our hierachies are usually simple enuff not to need it.

I'm not sure how a template can work out faster than a macro tho. If you can provide details of this, that would be cool. A little program with some timings in or something?

04-22-2002, 12:47 PM
Originally posted by Nutty:
I'm not sure how a template can work out faster than a macro tho. If you can provide details of this, that would be cool. A little program with some timings in or something?

It can reduce call overhead by inlining (non)template functions where needed (compiler decides or inline/__forceinline)- something which is not supported by C... In fact if you write everything with macros, then you are the faster, but then the code grows even more - not practical.
Also I read somewhere that inlining and macros should be used careful, since too large code actually may hurt the performance, so it is better if the compiler decides(which is only the non-macros case).
And templates offer much more than the macros - you know this http://www.opengl.org/discussion_boards/ubb/smile.gif


04-22-2002, 01:18 PM
I'm not sure how a template can work out faster than a macro tho. If you can provide details of this, that would be cool. A little program with some timings in or something?

Um, macros expand their arguments each time they're used. This can lead to HORRIBLY slow code. Here's a trivial example where a template will be much faster:

#define square(a) (a*a)

template <class T> square(const T a )
return a * a;

float someReallyComplicatedFunction( )

int main( )

Now, how many times will someReallyComplicatedFunction() get called? Twice in the macro, and once in the templated function.

The templated function is also type-safe, as an added bonus.

Macro's are evil for a whole variety of reasons, so don't even get me started http://www.opengl.org/discussion_boards/ubb/wink.gif

-- Zeno

04-22-2002, 04:00 PM
Ok - so you decide to write your smallish project in C and it grows and grows and grows - I think C++ is better. Knowledgeable use of C++ (ie. know your compiler!) allows you to generate tight code anyhow - and you have the opporunity to try out different coding patterns - OOP really can be quite useful. (virtual functions are the most useful, ok a little slow but equivalent functionality in C is tough - without writing your own compiler http://www.opengl.org/discussion_boards/ubb/wink.gif

04-22-2002, 10:14 PM
but if there isn't any difference in speed or C is faster then C++ why did they make C++? is it only for classes and OOP stuff ? or is there anything they changed ?

04-22-2002, 11:18 PM
McZ: i use C++ (and in it C), dont know why some guys think that both languages are different enought to say that one is faster, or produces smaller code, the difference is produced by the programmers! If you know that C++ is build on C you know that these languages are nearly identical, some stuff is added to C++ but you can write everything in C (ive never used RTTI so i dont know how to do it in C, but i can think of a struct with an union and a typeflag, or even faster if you use an array for each type and controll everything when it will be allocated) !!!

Some examples:

Templates in C (as a header file 'c_template.h'):

#ifndef TYPE
#error "Type not defined"
void TYPE myTemplateFunction(TYPE *var){
return *var;
#end if

#define TYPE long
#include "c_template.h"

and it will produce the same ammount of code like c++ templates will do (if both are inlined/not inlined)!!!

next example overloading operators like '+' isnt more than writing a macro:

#define +calc(x) calc_plus(x)
long calc(long x);
long calc_plus(long x);

virtual functions:

struct X{
void (*my_virtual_func) (X *this, long);
} abc, def;

void test(X *this, long);
abc.my_virtual_func= &amp;test;
void test2(X *this, long);
def.my_virtual_func= &amp;test2;

dont tried to compile the code, has maybe some bugs, but thats the way it works !!!

and finaly the this pointer as example in C:

struct XYZ{long a;};
void GetSomething(XYZ *this, long abc){
return abc* *(this).a;//maybe a syntax error produced by me, but '->' is c++ i think ?!

so the difference is only in code size (if you write itentical code!) and not in speed or size of the executable!

my code examples are maybe more c++ than i think, but its only to show that you can write it in c...

finaly you can do your c++ compiler easier than you thing, only convert it to c code and then use a c compiler !

Compiler: C++ -> C -> ASM -> something the Linker understand

http://www.opengl.org/discussion_boards/ubb/biggrin.gif never used streams...

04-23-2002, 02:52 AM
C++ can produce larger code, agreed... But I have yet to see a C++ code slower than a C code.

I have converted all my current project to Standard C++ with VS.NET, none of them are slower.
They're actually faster, smaller (in code, but sometimes gives a larger exe) and most importantly: less buggier. http://www.opengl.org/discussion_boards/ubb/smile.gif

C++ isn't an easy language, it's been two years I've been actively programming in C++ and I'm still learning new stuff everyday.

From a theorical point of view, C is faster than C++, and ASM is faster than C...
But in reality, C++ offers a larger and easier control while still offering backward compatibility with C and ASM. So if it's really slower, then you surely did something wrong.

To give a small and simple exemple of C++ being faster than C, while keeping things simple is sorting an array:
the STL sort() will never be slower than C's qsort(), because it's eliminating the overhead of the C function (yes, C's overhead, not C++).

[This message has been edited by GPSnoopy (edited 04-23-2002).]

Michael Steinberg
04-23-2002, 02:58 AM
You can't write object oriented code in c. C misses virtual functions.

04-23-2002, 03:06 AM
As for speed, it's up to the compiler. Some optimize better than others. As for one version of C being faster than another is not quite true because of this. The language is the language and nothing else.

As I recall, sorting has a running time of n log n so comparing programming languages based on a problem with a proven running time is not quite right either.

I do recall there may be more little more overhead with C++ and thus consuming some extra cpu cycles. In the end, it all boils down how the program performs (alogorithmically speaking, it's running time).

Personally, I'm going to move to C++ so I can encapsulate thread safe functionality and build a framework in which all my future apps will use. I want to concentrate on working with the data I'm trying to represent.

If I wanted to jump right in and get familiar with OpenGL, I would go with what I know best, then learn the preferred language later. One thing at a time.

my two cents.


[This message has been edited by lobstah (edited 04-23-2002).]

[This message has been edited by lobstah (edited 04-23-2002).]

04-23-2002, 03:29 AM
Cmon people, this has been discussed 1000000 times, and every time the same story: one says: c ist faster, the other says: no, this is a stupid rumour. And this will never end, its just the same as linux/windows holy war.


04-23-2002, 03:36 AM
You're in for trouble if you try and use plain C to construct a large project.
Believe me, I've worked for a company who's product is a sales/warehouse management database program suite - it's entirely written in Pro C (ie. C with embedded sql). It was laughable (but on occasion, it made me cry http://www.opengl.org/discussion_boards/ubb/smile.gif ).
Use c to produce little demos, if you will, but C++ is the way to go for anything bigger.

04-23-2002, 04:35 AM
Originally posted by davepermen:

why using c for it if c++ does the same but with less coding work? ok, because you love c.. but anyways..

It is because not all embedded systems has C++ complier.

04-23-2002, 04:42 AM
I used to think much the same way as some others on this board did about C/C++. The truth is, C++ has much more than is initially obvious.

For example the obvious uses of templates include: writing typesafe macros without byzantine side effects, or making parameterized datatypes (like std::vector). However, it turns out you can use templates to force your compiler to do all sorts of copmile-time decisions that let you write rich, efficient library code. This is extremely useful when you work with other people in programming (even as few as 3 or so).

Template code is only instantiated when it's used or explicitly instantiated. Also, it is easily possible to make templated classes to share code between different parameterized implementation using inheritence.

The nonobvious uses for templates is for generic programming and metaprogramming. Things like expression templates, STL, Boost, Loki, MTL, etc. etc. are simply magical to behold.

Problem with C++? Pretty big, actually. You need to be fairly committed, knowledgeable and just smart to avoid hanging yourself with the rope that they give you. For example, things like operator overloading can be used to greatly improve code readability, but it can be abused to achieve the opposite result.

Bottom line? You should educate yourself in C++. For almost every modern software engineering effort (including games, which are just getting huge) C++ is a better option than C. In the long run, you can do more with less.


PS To utterly blow your mind, read Modern C++ Design by Andrei Alexandrescu

04-23-2002, 04:59 AM
I'm with Won.

I've prgrammed my first OpenGL app using straight C code and during development, it occurred to me I should be using C++ to help manage the complexity.


I'm up to three cents now! http://www.opengl.org/discussion_boards/ubb/smile.gif

04-23-2002, 07:50 AM
I just love the C vs. C++ debate. I will have to post this again just for fun !!

I actually do use C++ once in a while. From the application level it is great for organization at a high level. The internal details and low level programming (fileio and math routines) will always be faster in C and asm. But i constantly mix C, C++ and asm. They all have there uses. Mix as much as you like. IF you are careful with your coding they play together quite nicely.


04-23-2002, 02:52 PM
Michael Steinberg

"You can't write object oriented code in c. C misses virtual functions."

OOP has nothing to do with virtual functions. That's just the way C++ implements polymorphism. And there is more to oop than polymorphism. In fact the original definition of oop didn't mention polymorphism.
There are plenty of projects that use C for oop.

04-23-2002, 10:29 PM
I guess you knows alot more then I do about C and C++ difference http://www.opengl.org/discussion_boards/ubb/smile.gif

I use both C and C++ so far becouse it is easy to use for me.. and I just love the class stuff and overloaded functions.. it is easy to use and understand when you know how they work..

Michael Steinberg
04-23-2002, 10:50 PM
This is a debate about what you define OOP. Many faq's and I believe even the inventor of C++ say that polymorphism is what OOP makes "practical" (?). Just having structs or simulating OO stuff with C is not object oriented programmin in my eyes.

04-24-2002, 01:56 AM
Originally posted by Devulon:
But i constantly mix C, C++ and asm. They all have there uses. Mix as much as you like.

nothing to add http://www.opengl.org/discussion_boards/ubb/biggrin.gif

[This message has been edited by ScottManDeath (edited 04-24-2002).]

04-24-2002, 04:27 AM
Originally posted by Michael Steinberg:
This is a debate about what you define OOP. Many faq's and I believe even the inventor of C++ say that polymorphism is what OOP makes "practical" (?). Just having structs or simulating OO stuff with C is not object oriented programmin in my eyes.
In case if it has anything to do with what I said earlier, I did not mean C is an OOP. I meant you can have your software design OO-based, disregard of what programming lang you use for implementation. It is not only true academically, not also true practically.

Rob The Bloke
04-24-2002, 11:25 PM
Originally posted by Michael Steinberg:
...Just having structs or simulating OO stuff with C is not object oriented programmin in my eyes.

You may code in C++, but that doesn't mean that your code is object orientated. OOP comes about whenever the programmer chooses to use the technique, not due to what language you are using.

Michael Steinberg
04-25-2002, 03:54 AM
I was speaking in a matter of ability to write OOP programs. C misses so many features that one can't reasonably write OOP programs, even if they have objects and stuff that isn't yet OOP. C++ gives the ability, nothing more, to write reasonable programs in an OOP style. It doesnt force you to. If I find that link to the article of a pro again I'll post it here.
Trying to simulate OOP with C is a pain in the ass and doesn't have the same potential.
Inharitance, polymorphism and protected members are some key-features to execute the OOP paradigm in my eyes.

04-25-2002, 03:58 AM
When I coded in C, I used to write `class-like' modules, where I would have a constructor `ie. Object_CREATE ( Object *pObject ) and all methods associated with that object type would accept a pointer,ie:

Object_DO_THIS_WITH ( Object *pObject );

Now - this works in that code and data are fairly closely bound (up to the programmer of course) - however, of course polymorphism, inheritance etc are impossible to implement in this way without kind-of writing your own compiler - which would be a total waste of time when you can use C++.

04-25-2002, 05:17 AM
My vote, of course, is C++... http://www.nigels.com/glt/

Given that C nearly always compiles clean
with a C++ compiler, and C++ has lots of
good features, in the graphics context I
don't see the point of using C.

Things like type safety and function
overloading are _good_ things. IMHO
Proper OO and generic programming (templates) are the icing on the cake...

That's just my 0.02, which is worth only USD$0.01!

[This message has been edited by nigels (edited 04-25-2002).]

04-26-2002, 04:07 AM
I use C mostly, but with it I use classes.

04-26-2002, 07:57 AM
I just couldn't resist:

Originally posted by Michael Steinberg:
This is a debate about what you define OOP. Many faq's and I believe even the inventor of C++ say that polymorphism is what OOP makes "practical" (?). Just having structs or simulating OO stuff with C is not object oriented programmin in my eyes.

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."
- Alan Kay

Michael Steinberg
04-26-2002, 08:11 AM
http://www.opengl.org/discussion_boards/ubb/smile.gif Okay.

Let's come to the conclusion that c++ is a OO language whereas c is not. What you do with it depends on the programmer.

04-26-2002, 09:54 AM
typedef struct {
void (*drive)(void);
} car;

void vwdrive()
car *createVW()
car *ret = malloc blah blah
ret->drive = vwdrive;
return ret;

void dodgeneondrive()
printf("Drive all bad arsed\n");

car *createNEON()
car * ret = malloc blah blah
ret->drive = dodgeneondrive;
return ret;

I just created not only a virtual function table in C, but also polymorphism with exactly then same syntax as C++ (no switch statements).

Car = createVW()

Car = createNEON();
"Drive all bad arsed"

Which is not to say it is not easier in C++, but you can do OO and polymorphism in as horrifying a language as F77 if you want.

[This message has been edited by nickels (edited 04-26-2002).]

Michael Steinberg
04-26-2002, 12:04 PM
Hmmm, how would you implement the this pointer then. Without the this pointer this stuff basically is senseless. I actually have no idea how to implement the this pointer, since c itself won't give the function the pointer to the struct. You would end up having to pass the pointers to the functions.

As I said, C is a non-OO language, you can do oo with it however. As c++ is an OO language but you can certainly do non-OO stuff with it.

04-27-2002, 12:38 AM
I recommend c++ for large projects > 10,000 lines of code. Really, global functions(you don't want them static and hidden) are impossible to look up in a sea of function names. You would have to prepend monikers to differentiate and order your functions. I already do that in c++ with z_Foo() in vc++6, I can't imagine you doing straight c and scrolling down the list everytime you want to look up a function. Try Genesis3D source code and you'll see exactly what I mean.

Plus, c++ operator overloading is nice for vector, plane, etc. math classes. You don't have to go with inheritance, you can subclass other objects. There are too many advantages to going with c++. If you're going to use it as c then at least you'll gain encapsulation which is helpful in large projects like I've mentioned previously.

Michael Steinberg
04-27-2002, 01:17 AM
IMHO operator overloading is a nice gimmick, but it's not really usable because of the copies involved. Template Expressions help, but on 4-component vectors they're slower than using inline functions. They're much faster than operator overloading though.

04-28-2002, 10:53 PM
Mike, what do you mean by copies? Don't you use references? I'm baffled.

Michael Steinberg
04-29-2002, 04:26 AM
I mean temporary copies of the objects during evaluation.
That is, because you can't return a reference to an existing vector when you have the + operation on them, because it results in a new vector. I didn't look too much into compiler optimizations, but on the one i did, it really made these temporary copies.

04-29-2002, 04:47 AM

IIRC (haven't coded for several months now), the general convention for operator overloading on a class would be like this:

class vector4 {
explicit vector4(const vector4&amp; v) : /* implementation dependent */ {}

inline vector4&amp; operator+=(const vector4&amp; rhs)
// add rhs to *this


const vector4&amp; operator+(const vector4&amp; a, const vector4&amp; b)
vector4 temp(a);
return temp += b;

Of course I may be showing my ignorance here because as I say, it's been a while since I fired up my compiler.

OK, I just opened up Stroustrup 3rd Ed and he has a similar operator+= example and mentions that it should be inlined very easily depending on how you do your implementation of vector4. You can't get away without a temp variable in the operator+ but if you define an efficient copy constructor, it should still be fairly cheap. I like using this method for readability anyway.


BTW, you need a temporary copy anyway for the operator+ example. If you do:

a = b + c;
// then a is a new vector isn't it? Otherwise, if you are doing:
a = a + b;
// then you should just be using:
a += b;
// and you get the inlined version anyway.
// I guess the other case is if you are doing:
vector4 a;
a = b + c;
// and a already exists, in which case you
// could create a new function like this:
void add(vector4 *a, const vector4&amp; b, const vector4&amp; c);
// and return the value in a. That's how I
// would do these operations (although I
// probably wouldn't do the last one).
// How would you do the equivalent operations
// (I'm just curious http://www.opengl.org/discussion_boards/ubb/smile.gif)?

[This message has been edited by ffish (edited 04-29-2002).]