Why char and other C function should not be used in C++?

Question

Can someone please enlighten me regarding answers in this question Assigning a value to char* in a struct?

In the answers, they told the asker not to mix C and C++, i.e. use string and cin if it's C++ or char if it's C. It makes me confuse since what I know is that we can use like char, printf and so on in C++ by including appropriate libraries. What if we should work with char in C++ project because of several reasons?

One of the answer also tells that typedef struct{...}x; is not necessary in C++, while so far I know now it is used to prevent re-typing struct x, e.g x Name1; x Name2; instead of struct x Name1; struct x Name2;. It is confusing enough for a beginner like me.

Answer 1

This is an opinion-based question (which I suppose is why it's been downvoted), so I'm going to wade in here with a dissenting opinion:

Why char and other C function should not be used in C++?

Well, it's partly because some people have rigid opinions on what programming should be, and they like to try to force these opinions on you. :-)

It's true that C has many unsafe aspects, particularly by modern standards. It's true that C++ has "better" or at least different ways of dealing with several things, including strings, I/O, and memory allocation.

But at the end of the day, programming languages are tools, and using them appropriately is always a balance between using them as designed, and getting your job done.

C++ was designed to be a superset of C. (These days it's not, of course, but the intent is still clearly there.) So there's nothing inherently wrong with using C features or idioms in a C++ program -- the whole point of Bjarne Stroustrup's exercise was always to allow you to.

If you choose to use a C feature in a C++ program, it might be an ignorant or a bad or a dangerous thing to do, or it might be expedient and decently appropriate thing to do. At the end of the day, it depends on whether it gets the job done, whether it's maintainable, and whether it's acceptable to any other people you may be sharing code or collaborating with.

For example, I code in both C and C++. And while I understand how cout and << are a "better" way of doing output than C's printf, I confess that I still use printf in C++ programs a lot of the time, because it's so much more convenient. Despite its notorious and insurmountable warts and problems, printf has always been one of my favorite parts of C, and I am loath to give it up.

I'm not saying you should use printf in C++, or that you should ignore all the various benefits of std::string, and new/delete, and the STL. "When in Rome, do as the Romans do" is a fine philosophy, and most of the time, you should use C++ idioms in C++. But if you have a good reason to fall back on a C idiom once in a while, I don't believe there's any shame in that, and I don't believe you should let anyone guilt-trip you into abandoning it just because they think it's "not proper".

[It will be interesting to see how violently this answer gets downvoted for its heretical advice. :-) ]

Answer 2

The C++ compiler doesn't care if you mix C style code with C++ style code, it will produce some result.

Other humans care if you mix C style code with C++ style code, because it's really easy for it to do something subtly different from what you think it should.

C++ is not a safe language, where you simply can't do wrong things, nor is it a safer language, which will loudly tell you when you do wrong things. It is an unsafe language, where if you do things wrong, you might not notice right up until the worst possible moment.

Answer 3

What if we should work with char in C++ project because of several reasons?

There is nothing stopping you :D

That said, the design of std::cin and std::string is the way it is, because working with char* and scanf is error prone and inefficient (and they were added to the C++ standard library to provide better ways).

There are reasons to work directly with char* in C++, but most of them are really bad reasons (a good reason would be to learn - for example).

Answer 4

C and C++ are different languages, no matter how similar they look and what common subset they have. Being different languages, they have methods that work only within that language. Mixing them is fine when you know what you are doing. As the other answer states, char arrays are more difficult to use than std::string, although they have their advantages. For a beginner, if you want to learn C++, learning std::string will save you quite a lot of debugging strange things happening in your code compared to using char*

---

The reason why you don't need typedef struct {} X is a prime specimen of C and C++ being different languages. You will not need to repeat struct X every time you use in C++, with or without typedef. I'd even say it's harmful, because void foo(struct X*) does something more than just void foo(X*). Moreover, struct in C++ is equivalent to class, the only difference is the default access specifier (struct has public as default, class has private).

Answer 5

zero terminated char * strings have been the source of an enormous number of bugs, crashes and security flaws over the years, usually because someone forgets to zero terminate them, or because they forget a 4 character string needs to be 5 characters long, or a number of other scenarios.

They CAN be used safely, but experience tells us we will make mistakes, and waste time and effort testing and checking and testing again, when we could just use a string class, that contains all the checks in one place, is tested in one place, and never needs to be worried about again. So why on earth wouldn't we?