Is it just me or has this deteriorated from a simple discussion on why one should use classes instead of functions for things designed to be used once into an argument between C and C++.

Personally, I always use classes, it may seem extreme, and it does to me sometimes, but I like to keep everything the same.

That said, I do not need to use C++ to acocmplish this...classes are easily mirrored in C using structs and function pointers so the argument really should have nothing to do with C vs. C++. I implement a singleton design pattern when implementing soimething like my engine, to ensure that it can only be instantiated once. The advantage then is that I can compile it all into a library and at some time or other, just derive from my original engine and add some new functionality, which I believe has already been mentioned.

Classes in themselves are nothing to be argued over, since everything, with a bit of work, can be mirrored in structs (I mean C-style structs, not C++ structs).

quote:Original post by Anonymous Poster
Is it just me or has this deteriorated from a simple discussion on why one should use classes instead of functions for things designed to be used once into an argument between C and C++.

There are people skilled in turning any post into a c vs. c++ argument.

I read a lot of the posts, and I noticed that "class" and "struct" were the terms being juxtaposed. By "struct", posters are implying structs under the C language.

In a C++ compiler, structs are near identical to classes; they can both have member data and functions, and be involved in polymorphism etc...

The only difference between the two, is that a "struct" has a default protection of "public:", whereas classes are by default "private:"

Just clarifying that point. I don''t think it was mentioned above.

Hi, Sorry if this was mentioned before, But Can you do things like "Virtual", and polymorphism in Structs?

--Josh

"language" != "programming language" either if you totally ignore the context where the word is used. I don''t think you should post at all since it''s impossible for anyone to communicate without generalizations. Bleh.

Very good post by the way, but I think you jump to the wrong conclusion here.

quote:Original post by donmc
The point ... is that C++ was designed to facilitate larger programs to be written. Thus, it''s a different tool than C and has it''s own pro and cons as well. Thus, it has its "right" time for use. Of course, OOP itself brings it''s own problems to the table. Namely larger source code, larger .exes and slower executing code than an equivalently coded C program.

I know half of you are going to complain about that last sentence, but think of it in these terms. Pretend for a moment you have two identically performing programs, on written in C and the other in C++. You write the C version using procedural methods (globals, inlined, the works), and your C++ is total OOP. Total data hiding, accessor methods, C-tors, D-tors, et cetra.

The C++ will still run fast, but with all the construction, destruction, function calls it *will* without a doubt have substantially more overhead than the comparable C code.

This is one of the main fallacies in all C vs C++ debates. ctors do not need to be written. dtors do not need to be written. If you have this equivalent code in C:
struct MyStruct { }
void InitMyStruct (MyStruct *pObj);
void TearDownMyStruct (MyStruct *pObj);
..then obviously you should have a ctor and a dtor. Furthermore, that code will compile exactly the same in C and C++ (however, in C++ you are guaranteed that clients implicitly call the ctor, whereas in C it''s anyone''s guess if they properly call InitMyStruct).

However, if your design doesn''t have these functions, there is no way you need ctors or dtors for your objects, and they will have exactly the same performance characteristics as their C counterparts.

The same fallacy applies to the "performance cost" of inheritance. Cost when compared to what? Calling free functions? That''s hardly fair, since free functions cannot achieve polymorphism. In order to achieve polymorphism in C, you need to either have a "type" struct member and have a top-layer function switch on the type to take different behaviors, or you have an array of function pointers for each of your polymorphic functions that get filled-in by some intialization routine. You could even just have a single pointer to a static table of the function pointers. Either way, you have almost the same run-time profile, with the last solution being exactly how the vtable works in C++, e.g. exact same run-time cost and memory overhead.

Your main point was correct at one time, that C was better than C++ at creating small, tight code. However, advances are quickly removing that gap, and in some very specialized cases C++ is beating-out C. The last bastion of procedural programming, that of embedded systems (my current field) is slowly turning to C++ for many of its processors. C++ has always had a richer feature set as C, but it''s finally starting to be just as tight as C as well. It still takes more skill to write tight code in C++ than it does in C, but with that skill comes great rewards.

I have a feeling we''ll have to agree to disagree on these points, but I appreciate your well-put post.