Thread: Not so much of a technical question...

Let me start out by saying this: I love C

Now, with that out of the way.. I want to create a simple game, and that really cries OOP so C++ would be a much wiser choice. The problem is that I hate <iostream>, <string>, etc. I like char *buffer much better. Now the big question is... is it ok to take the parts of C that I like (read(), write(), etc...) and use them in C++? I know it will work and produce the desired results but is it good coding practice? Or maybe I should just suck it up and learn the C++ way of doing things?

Thanks,

Sam

It depends on what you mean by good coding practice. If you are trying to learn to use C++ to its fullest potential, then using all the C ways of doing things is not good practice. If you are merely trying to augment your C code with some of the features available in C++, then IMO that's fine.

The benefits of sucking it up and learning the C++ way include learning new programming paradigms that aren't available or are clumsy in C. In addition to OOP, generic programming is a useful tool and practice with that tool would make good experience. Of course, if your goal is to make the best game you can make as opposed to learning about programming, then that benefit isn't as important. However, if you do want to continue programming in C++ in the future, it will get you into some bad habits if you start out with a C frame of mind.

One suggestion if you do decide to stick to C code in C++ - be aware of functions like malloc or memcpy that don't pay attention to constructors or objects. For example, if you use malloc to allocate space for an array of class objects, the constructors for those objects won't get called. You have to use new. When mixing C code with C++ classes you have to look out for those problems.

>> Why is it bad programming practice? Is new any better than malloc()?

Originally Posted by Daved

One suggestion if you do decide to stick to C code in C++ - be aware of functions like malloc or memcpy that don't pay attention to constructors or objects. For example, if you use malloc to allocate space for an array of class objects, the constructors for those objects won't get called. You have to use new. When mixing C code with C++ classes you have to look out for those problems.

Thanks for the replies.

It gets very confusing for me when I am looking through tutorials written in C++ that have classes but use #include <stdio.h> and then use fread, fwrite... etc. Even OpenGL Game Programming by Hawkins and Astle seems guilty of this.

To tell you the truth I have a hard time telling where C ends and C++ begins. A lof of the times I am unsure which one I am using. I know that <stdio.h> is the C Standard IO include file.

I will try my best to stick with "straight" C++

Originally Posted by http://www.codeguru.com/forum/showthread.php?t=344569

Q: What about the traditional ANSI C standard header files?

A: The traditional ANSI C standard header files are prefixed with the letter 'c'. Thus 'stdio.h' has become 'cstdio', 'stdlib.h' is called 'cstdlib', 'math.h' is called 'cmath', 'time.h' is called 'ctime' and so on.

However, I guess when using C++ you should stick strictly to the iostream, and not use stdio type things.

So what happens when I include stdio.h? hrmmm....

So at the risk of beating a dead horse,

There should never be a reason to include something like stdio.h in a C++ project because cstdio (if for some reason you need to use C style IO) which is made specificaly C++. If you use stdio.h, it works because C++ is compatible with C.

Hmmm this could be a clearer.

Then there are things like <unistd.h> in that case <cunistd> doesnt exist, so you have to use the C version.

Do I have this about right?