Advertisement

C or C++

Started by October 10, 2000 02:40 PM
15 comments, last by John1 24 years, 3 months ago
I agree that everyone claiming to be a computer scientist or software engineer you should definetly know what you can and cannot do in C as opposed to C++.

Better? =)

What is it that C programmers don''t like about C++?
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Sorry but you CANNOT do OOP in C.
C does not support many of the things that make a program OO, (inheritance, polymorphism, encapsulation).
If C is OO then show me how to hide implementation in C. all structs are public by default and if you''re doing OO the first thing that will be drilled into your skull is
"PUBLIC VARIABLES ARE EVIL!! THEY ARE NOT OO!"

That said maybe you don''t want to program in OO. OO will always introduce a small overhead. if speed is REALLY critical go for C, or better yet inline asm.

"That's not a bug, it's a feature!"
--me
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight
Advertisement
It''s the name. They simply can''t stand the idea of C++ being an "improved" version of C.

Whatever...

I would advise learning C++ first, as most people learning procedural programming tend to choke on C++ code. It''s the little differences between C and C++, plus a lack of understanding of C++ (overconfidence) that causes almost all C++ gripes. I''m not knocking the C programmers, but we should be realistic here:

C experience != C++ experience

Don''t expect it to translate directly. I would not bother learning C first if you really intend to learn C++, since there really isn''t a good reason to learn C first.

C++ is better suited for OOP coding - it has more compiler support for features suited to OOP.

That said, before you try to make commercial games or other software, you should _definitely_ learn your language of choice. If you know the language, you can learn anything else. Don''t try to learn DirectDraw before you can read code. The language is the basic tool, while DirectX/OpenGL/whatever are just collections of code that you can use with your language. Make small games or just really simple programs until you get a good grasp of your language. Practice using what you learn, in small increments so that you don''t get frustrated. Learning how to programming can be frustrating at times, but it''s very rewarding.

Learning C or C++ or whatever programming language you want is kind of like learning English. First, you learn to speak it and pronounce some of the simpler words, and maybe even a few short sentences. You also begin to study the grammar, so that you know what combinations of words to put together to express yourself. While that is happening, you read some small books (like small programs). This cycle repeats over and over until you have actually learned the English language, and then you are ready to actually start writing reports and essays and all of that fun stuff.

In that analogy, C++ is like the English language, grammar, and phonics. DirectDraw, Allegro, and OpenGL are like the books that other people have written. You gradually practice with both the language and the books until you know enough to write your own books. At that point, you can write software.

Good Luck!


FordPrefect and others with the same idea:

As for the learning-procedural-allows-you-to-have-an-unbiased-opinion idea - well, I''ve never seen that happen. Would you tell someone to program in DOS and then try to move to DirectDraw? It''s ridiculous. That''s why we''ve got people creating their own buffers in system memory when they could be using hardware-accelerated surfaces in video memory with much less work...they simply never knew the capability existed, because they''re used to *everybody chimes in* DOS. If you want to learn C, then learn C! If you want to learn C++, then learn C++! If you want to learn DirectDraw, then learn DirectDraw! Telling people they need an intermediate step to test the water is silly...


- null_pointer
Sabre Multimedia
Are you thinking what I''m thinking, null_pointer?
I''m sure you are...

*thinks very loudly* .oO( Oh no, not THIS argument again... )


People might not remember what you said, or what you did, but they will always remember how you made them feel.
~ (V)^|) |<é!t|-| ~
It's only funny 'till someone gets hurt.And then it's just hilarious.Unless it's you.
According to ChaosEngine...
quote: Sorry but you CANNOT do OOP in C. (snip...)

Sorry, but this is incorrect. I've already posted in several threads previously about this misconception. OOP does *not*, I repeat, *NOT* absolutely depend on the use of an OOP language. It *prefers* it, but it does not require it.

The reason is quite simple, and that is, in the end even C++ ends up compiling down to machine code, just like C does. Hence, pretty much anything that can be done in C++ can be simulated in C. It will not necessarily be as pretty (and it may be downright ugly... implementing virtual function tables manually, for example, is not exactly gorgeous), *but* it can be done. And since OOP is a logical concept just as much as a physical one (it stands for Object-ORIENTED Programming after all), there are no specific requirements from the language. C is not an object-oriented LANGUAGE, but you can do OOP without an OOL.

And note that things like virtual function table simulation etc. is not necessarily even required, at all, when doing OOP in C. This is because object-orientation can be done in a Black Box manner, just as much as a White Box manner. While White Box depends on inheritence, Black Box does not. Programming C in an object-oriented manner, using Black Box reuse, is actually quite a common practice.

Inheritence and polymorphism are requirements of Object-Oriented Languages. They are *NOT* requirements of Object-Oriented Programming. Know the difference. And encapsulation is a logical concept only, not a physical concept. The corresponding physical concept is "insulation", and C++ is actually quite bad at it. You can take advantage of encapsulation (and insulation) just as well in C as you can in C++.

In summary, C is not an object-oriented language. C++, however, is (at least to a good extent). But OOP does not require the use of an OOL, it only requires that you program in an object-oriented manner. This can be done in C++, or in C, or even in Fortran for that matter.

P.S. Do not take this post to mean that I am an advocate of using C instead of C++; the reality is quite the opposite. I will never going back to using straight C. That being said, I'm tired of seeing posts from people who don't know the difference between object-oriented programming and object-oriented language. If you don't understand that difference, then you only cripple your comprehension of how to take advantage of any language you may encounter... OOL or not.



Edited by - Chris Hargrove on October 11, 2000 8:56:23 PM
Oh, and also from ChaosEngine...

quote: If C is OO then show me how to hide implementation in C.


Handle parameters. The "static" keyword. Plenty of other mechanisms along those lines. Look into em.

There are examples all around you. Take Win32 for example. The Win32 API is C, not C++. Yet when you work with a window, what do you pass around pretty much all the time? An HWND, which is a handle to a window. The window *is* an object (hence why many parts of the Win32 API can be considered "object-oriented", since you're working with objects such as windows), however the implementation details of the window structure are completely hidden. The private data used by a window object is not exposed to you. You access the window via a handle to it, and you are only able to access the publicly-accessible properties and operations of it, via C functions. The window is both encapsulated and insulated.

And all in good ol' fashioned C.


Edited by - Chris Hargrove on October 11, 2000 9:09:19 PM
Advertisement
Well, here''s my two cents...

1) Is C++ better than C?

No. They both work just as well, BUT I believe it is important that when you go to code you should choose either one or the other. Mixing C and C++ is a bad idea. C was designed for a structured programming, and C++ was designed for object-oriented programming.

2) Are C and C++ the same language?

No, for many important reasons. C++ is based on C, therefore, it inherits (sorry, I couldn''t help myself) the basic grammer and vocabulary of C, but it has also changed many aspects of C. C++ has added many restrictions on the way code is written that did not exist in C, but on the other hand it has made other aspects of coding easier. For this reason, code written in C may not compile on a C++ compiler, and going through someone elses C code to make it C++ compliant is a royal pain in the ass. Using C libraries in a C++ compiler is possible, but because C++ compilers use a completely different name decoration scheme during compilation, all C function prototypes have to be qualified with _extern "C"_.

3) You can do the same thing in C that you can in C++ (i.e. object-oriented programming in C).

This is absolutely true. Even though, as I stated before, C was designed for structured programming, and C++ was designed for object-oriented programming; You can indeed use C to write a program that conforms to the object-oriented paradigm. Hell, the idea of object-oriented design exsisted long before C++. OBJECT-ORIENTED PROGRAMMING IS NOT THE PRODUCT OF C++, C++ IS THE PRODUCT OF OBJECT-ORIENTED PROGRAMMING. C++ is not the be all end all of object-oriented programming. You can use the visibility of modules, and what''s inside, with respect to the program as a whole to "hide" (i.e encapsulate) data from the rest of the program. Through the use of void pointers, function pointers, and explicit type casting, you can code many of the aspects of inheritence and polymorphism, though, the use of too many pointers can lead to a major headache if your not very careful.

4) Should you C or C++?

Well, both actually. Since C++ is derived from C it makes a great foundation if choose to learn C++. IMO it''s best place to start. They both have there strengths and weaknesses, but between the two it''s pretty much a level playing field. As a group I think they both outclass any other language out there. Well except for maybe assembly, but who in their right mind is going to write an entire app is assembly. Once you''ve mastered C and/or C++, assembly is a good place to go from there.

In conclusion (God, it feels like I''m in highschool all over again)...

In the end, it comes down to Structured Programming vs. Object-Oriented Programming. You need to take a long hard look at both paradigms. You need to figure out which one best suites your needs and your mind-set. Personally, Object-Oriented Programming best fits my way of thinking about things. This is not true for everyone. Don''t give in to the hype about C++ being an improved C. Do the research, and do what''s best for you.
<span class="smallfont">That is not dead which can eternal lieAnd with strange aeons even death may die.   -- "The Nameless City" - H. P. Lovecraft</span>

This topic is closed to new replies.

Advertisement