mixing C and C++?

[lochnessmonster]

Is mixing C++ with C a bad thing? is it despised upon?

[Narue]

No, it's not bad. Only C++ purists will rag on you about it, but they're in a world of their own anyway.

[mike_2000_17]

There are many ways to mix C and C++.

1) It is very typical for external libraries to have C interfaces (API). There are many reasons why a C interface is chosen (or necessary). In that case, mixing C and C++ is required in order to use that external library, and it certainly is not considered bad style or whatever. This is normal and very typical.

2) You can literally have source files in C++ (.cpp files) and others in C (.c files) and have a build system that uses a C++ and C compiler to compile both and link everything. Generally, this happens when there are parts of the code that are very low-level (like hardware drivers) and thus, they tend to be more easily implemented in C because of less strict type-casting rules and stuff (also for legacy reasons). But, if the use of C source files is not justified, then it is usually considered somewhat bad to do this. Mainly, the hassle of compilation, linking, and cross-language headers (the infamous "extern "C" {") is annoying and since C is basically compilable on a C++ compiler it's usually not a big deal to just make the few fixes required for the C sources to be compilable as C++ source files and that saves a lot of hassle.

3) I suspect that what you are actually referring to by your question (and what Narue has answered to) is the use of C-style programming in C++ source code. This is most typical of programmers who came from C and switched to C++. There are various degrees to this, two of which would be the coined terms: "C-with-objects" and "C++.. not ++C".

The first is people who basically use C++ for the object-oriented features of it (grouping data and code, encapsulation, dynamic polymorphism, etc.) but basically stick to C when it comes to the implementation. This includes using (almost) only C constructs (like null-terminated strings and arrays) and mostly C functions (like atoi(), strcmp(), printf(), scanf(), fopen(), etc., etc.). I understand why people do this, basically, once you are familiar with a set of functions and your are effective at using them, mind as well do so instead of re-learning the basics. I used to do this. But, I would say, that most people grow out of this because as you get exposed to other peoples code that relies on C++ standard constructs and functions, you have to get to know them anyways, and when you do, you will most likely prefer them to their C-style counterparts (if they even exist, because the C++ standard library is far superior to the C libraries).

The second, "C++.. not ++C", is more subtle. The PWN is, of course, about the fact that evaluating "C++" in C/C++ would yield the original value, i.e. "C", while evaluating "++C" yields the incremented value. This refers to people who "don't get" C++. Essentially, since you could do basic OOP in C, that is, group data structures and their related functionality (and with a little effort, you can also reproduce encapsulation, abstraction, and polymorphism). So, if your usage of C++ features is restricted to basic object-oriented programming, then you are basically not getting much more "bang for your buck" with C++ than you would with C. Some people would refer to this style as a mix of C and C++ for that reason. When you embrace more powerful programming paradigms of C++ (like generic programming and template meta-programming), or simply make wise use of certain characteristic idioms and design patterns (like RAII or smart pointers), and thus, realize that C++ is not just about some OOP syntactic shortcuts added to C, then you get much more out of it and become much more effective at coding than you could possibly be in C.

All in all, it's not bad to mix C and C++. Except for the first two cases where it is justified, using C-style coding in C++ code is not bad either. It just doesn't give you as much as you would get from "pure" C++. I think that most programmers (especially those coming from C) take some time to migrate to "pure" and effective C++ coding, but very very few will keep using C-style coding in C++ code for very long. So, when "C++ purists" say "berk, C code in C++!", they really mean that they see you as a novice who hasn't fully embraced C++ yet (i.e. you're not in the "club"), but that's alright. I see C-style code all the time and have no problem with it. But don't have delusions like thinking that somehow since C-style programming is "harder", it means you're a "better" programmer because you can do your programming only with those limited tools (that's ridiculous, the best programmers are those who know which are the best tools from the job at hand and are not afraid to learn and use them, not those who can achieve the toughest programming feats and contortions).

[mrnutty]

No, it's not bad. Only C++ purists will rag on you about it, but they're in a world of their own anyway.

Its not bad but its harmful isn't it? If one had an option, why would he think about mixing C style with C++? Usually, its more safe to use C++ than C, IMO. Or maybe I'm interpreting his questions wrong. When he says mixing C with C++, I think of stuff like using char pointers and std::string. Plus its not consistent with one's program to mix up styles. It might confuse readers, or at least frustrate them.

[Narue]

Its not bad but its harmful isn't it?

What constitutes C vs. C++ and how much C style is too much will be highly subjective. But there's really no point I would call it harmful.

Usually, its more safe to use C++ than C, IMO.

"IMO" being the key point here.

When he says mixing C with C++, I think of stuff like using char pointers and std::string.

Let's not forget that std::string is carefully written to play nicely with C-style strings.

Plus its not consistent with one's program to mix up styles.

You're thinking about this too hard. Let's use an example of "C is teh 3vil!" that I've personally been called on before:

std::srand((unsigned)std::time(0));

That ugly cast is ugly and should be removed because it's ugly. I was told that "proper" C++ uses static_cast:

std::srand(static_cast<unsigned>(std::time(0));

This is a matter of mixing C and C++ to those people. There's an alternative in C++ that many will delude themselves into believing is better. But it's not necessarily better, it just is. In this case I'll pick one or the other based on little more than my mood.

[Frederick2]

The first is people who basically use C++ for the object-oriented features of it (grouping data and code, encapsulation, dynamic polymorphism, etc.) but basically stick to C when it comes to the implementation. This includes using (almost) only C constructs (like null-terminated strings and arrays) and mostly C functions (like atoi(), strcmp(), printf(), scanf(), fopen(), etc., etc.). I understand why people do this, basically, once you are familiar with a set of functions and your are effective at using them, mind as well do so instead of re-learning the basics. I used to do this. But, I would say, that most people grow out of this because as you get exposed to other peoples code that relies on C++ standard constructs and functions, you have to get to know them anyways, and when you do, you will most likely prefer them to their C-style counterparts (if they even exist, because the C++ standard library is far superior to the C libraries).

You've got me nailed Mike_2000_17!

I started to learn C++ over ten years ago; liked it at first because of neat stuff like classes, references, etc; then got badly turned off by virtually all the C++ libraries, which I simply have no taste for. I eventually gave up C++; used C and other languages.

About 4-5 years ago I did some rethinking on the matter, and decided that I had more or less 'thrown the baby out with the bath water'. C++ had features which were just too neat to ignore. What I do is exactly what you describe; I use all the native features of the language but none of the C++ Std. Libraries. I'm somewhat reconsidering the string class, but my verdict is still out on that. I have my own that compiles about half the size of the Std Lib String Class, and that's even with a lot of added features in it that are useful to me. Also, I used classes to make neat wrappers for my ODBC routines. But something I'll never buy is iostream. Just can't seem to remember which way the '<<' - '>>' should point!

[mrnutty]

What constitutes C vs. C++ and how much C style is too much will be highly subjective. But there's really no point I would call it harmful.

"IMO" being the key point here.

Well on average, the code you see, do you see C++ code constructing the program more safely or do you see C code constructing the program more safely. Now I'm not talking about the real 20yrs experienced coder, but just averaged coders. C is a lot more easier to f-up than C++, although its easy in C++ as well.

Let's not forget that std::string is carefully written to play nicely with C-style strings.

Well yes, but I was saying when possible not always.

You're thinking about this too hard. Let's use an example of "C is teh 3vil!" that I've personally been called on before:

std::srand((unsigned)std::time(0));

That ugly cast is ugly and should be removed because it's ugly. I was told that "proper" C++ uses static_cast:

std::srand(static_cast<unsigned>(std::time(0));

This is a matter of mixing C and C++ to those people. There's an alternative in C++ that many will delude themselves into believing is better. But it's not necessarily better, it just is. In this case I'll pick one or the other based on little more than my mood.

Ok thats the minor details. Again "mixing C++ with C", I took it as :

- using raw pointers versus std containers
- using pointers versus references
- using pointers versus smart pointers
- using char* versus std::string
- using structs for invariants versus class
...of that nature.

Stuff like C++ versus C comment style, casting and other small stuff, I'm not concerned with. Its the other bigger stuff, I'm complaining about. But in the end, if one is competent in writing C/C++ code then it doesn't matter, as long as the company follows similar structure in writing code.

[mike_2000_17]

@Frederick2: From what I see, you are progressing. I might suggest you take a look at "C++ Coding Standards" by Alexandrescu and Sutter. You will understand why C++ standard libraries are programmed the way they are. You might also look around the Boost libraries for examples of awesome coding style. I am convinced it will speed up your transition to a more "purist" C++ style.

@firstPerson: The list you gave seem to me like pretty minor details too (just like Narue's cast example). Maybe these things can cause a few headaches (like segfaults) to a novice in C, and they surely would cause less grief when using the C++ counterparts. But to a mildly good programmer it won't make much of a difference except for maybe a bit of extra care with the C-style stuff (arrays, raw pointers and C-strings).

What I think is a much more pertinent problem with C is the lack of certain paramount features of C++:
- Resource Allocation Is Initialization (RAII)
- Enforcing interface usage through strong type constraints and access rights
- Generic algorithms with compile-time enforceable policies
- Avoiding name clashes via namespaces, nameless functors and lambdas.
- Modularity in general
... things of that nature (and I only wanted to mention those that are essentially impossible to reproduce in C, i.e. they need templates).

You can surely mix the benefits of the above features of C++ with some underlying C implementations (what do you think is under the hood of the C++ standard libraries? If you think there isn't a malloc call behind a new operator, or a C-style array in an STL container, you are deluded). But soon enough, the love for these techniques will naturally lead you towards pure C++ (and these are the kind of C++ features on which the C++ standard libraries rely heavily on).

@Narue: I agree, the casting in C++ is one annoying little bit of syntactic acid (as opposed to syntactic sugar). I still use the C++ casts, just to get rid of the compiler warnings (and its not like typecasting is very frequent in C++ anyways.. it's a strongly typed language after all). You might also notice the irony of trying to use C++ style in a line of code that has two C function calls.

[Narue]

Resource Allocation Is Initialization (RAII)

Likely my favorite feature of C++.

You might also notice the irony of trying to use C++ style in a line of code that has two C function calls.

The claim of mixing C and C++ only applies if there's a C++ analogue of the C feature. In the case of random numbers (pre-C++0x), srand and rand are the only standard option.

[mrnutty]

>>What I think is a much more pertinent problem with C is the lack of certain paramount features of C++:
- Resource Allocation Is Initialization (RAII)
- Enforcing interface usage through strong type constraints and access rights
- Generic algorithms with compile-time enforceable policies
- Avoiding name clashes via namespaces, nameless functors and lambdas.
- Modularity in general
... things of that nature (and I only wanted to mention those that are essentially impossible to reproduce in C, i.e. they need templates).

Well the discussion was about mixing C with C++, not specifically the difference between C and C++. If C had a counterpart to those listed above then it would be a valid point, but since C doesn't have those features, you can't argue with this point.

[mike_2000_17]

>>Well the discussion was about mixing C with C++
Yeah, read my initial post.

>>but since C doesn't have those features, you can't argue with this point.
My point was that the more C that you use in C++, the less you are taking advantage of those features. If you restrict the conversation to things that can be done (almost) equivalently in either languages, then there isn't much to talk about, and it isn't so bad to mix C with C++ (see my initial post). And, btw, if you look at your list (raw pointer vs smart pointer, array vs containers, etc.), the reason why the C++ counterparts would be preferable is because they take advantage of the features that I mentioned, I was just generalizing your point from small (trivial) differences to more global software design difficulties that too much C in C++ would cause. From re-reading your posts, it seems that this was the point you were trying to make in the first place by calling C++ alternatives "safer" and promoting "consistency" in the coding style. I think that as long as the use of C-style code is trivial (like the extreme case of static casts) and that it is well encapsulated into good C++-style interfaces (not passing raw pointers and the like in public member functions), then it's fine to use some C code for the (hidden) implementations, but if it spills out of the interfaces it will pollute the C++ code and make it less safe, less consistent and less flexible.

[pritpal.singh88]

well I suggest not to mix c with c++
as c is a procedural language and c++ is oop language which deals in the real world objects theory
though you can use c functions in c++
but the approach for constructing a code should b kept different.
it is my view other may be correct
If you got The answer don't forget to mark as SOLVED