Mixing C and C++

curlious · 09-09-2005, 08:47 AM

In your opinion is it bad practice to mix C and C++? I am intersted in hearing your reasons for your opinion as well.

If this is an old topic forgive me for rehashing.

Narf · 09-09-2005, 08:59 AM

I'm a little biased because I often write tools that need to be used in both C and C++. Usually the effort in porting the tools to "proper" C++ is impractical either in time or cost. So no it's not bad style to mix C and C++ in a lot of the work I do. But it really depends on what you do and how you do it. So there's not really a clean answer to your question.

curlious · 09-09-2005, 10:02 AM

It is good to know what a professional opinion holds, I was hoping for a few more replies before I stated my own opinion.

I prefer not to mix c and c++ but part of this is ignorance. I prefer using c++ and I have rarely felt a need to resort to c to do any of the code I need.

I feel that eventualy it is necessary to use non standard libraries and in a purist sence this is no worse than mixing c and c++.

The main problem I feel is that certain compatiblity problem can occur when you mix the code and this can produce unforsee side affects.

**CornedBee** · 09-09-2005, 10:30 AM

In my opinion it's fine to mix libraries in C and C++ freely, but mixing C and C++ code in a single library is just inviting confusion, what with all the extern "C"s and so on.

Basically, you want to call into C from C++, but avoid calling into C++ from C, because that means you must provide a C-style interface.

**Salem** · 09-09-2005, 10:43 AM

http://www.parashift.com/c++-faq-lit...c-and-cpp.html
So long as you stick to compiling your C with a C compiler, and your C++ with a C++ compiler (and don't attempt to cast your C into C++ by various hacks), you should be OK.

Ancient Dragon · 09-09-2005, 02:01 PM

except for fstream library functions I tend to use pure c++ functions -- I hate fstreams, FILE and associated functions are a lot simpler to use. I love c++ container classes such as <vector>, <list> and <string> because they are a great time saver.

Often you can not avoid using C functions in C++. atol() can be substituted by istringstream, but why??

**CornedBee** · 09-09-2005, 02:48 PM

I found that in every place where I find the C++ standard library unsuitable, the Boost libraries have provided the solution I was looking for. Just as an example, I much prefer lexical_cast over atol and any of its siblings. I find it far clearer. The functionality of the iostream library that made it so brilliant, namely the device-independence, was near impossible to use due to its complexity, but the new Boost IO library has remedied that. Suddenly you have gzip, zlib and bzip2 compression as well as base64 encoding out of the box.

Ancient Dragon · 09-10-2005, 10:04 AM

> I much prefer lexical_cast over atol and any of its siblings. I find it far clearer.

In what way? atol() is simple enough -- only one argument.

I downloaded boost libraries a week or so ago, but have never used it. A quick review looks like the programmer needs Ph.D. to understand it. How many decades does it take to get familar with it?

**CornedBee** · 09-10-2005, 10:30 AM

Quote:

Originally Posted by Ancient Dragon

> I much prefer lexical_cast over atol and any of its siblings. I find it far clearer.

In what way? atol() is simple enough -- only one argument.

It's consistent. No matter what I cast to - int, long, short, std::complex, boost::datetime, ... - the syntax is always the same. With atol and friends I have a very small set of standard functions (with rather cryptic names, IMHO), and if I want more, I have to extend that set. If I want to keep the naming convention, I'll soon run into conflicts. How do atod (double) and atod (date) differ?

Quote:

I downloaded boost libraries a week or so ago, but have never used it. A quick review looks like the programmer needs Ph.D. to understand it. How many decades does it take to get familar with it?

Well, it's a lot of libraries. Some, like lexical_cast, take two minutes. Others, like the graph library, probably take a year to really learn. Just take what you need.

09-09-2005, 08:47 AM	#1
curlious Registered User Join Date: Jul 2003 Posts: 450	Mixing C and C++ In your opinion is it bad practice to mix C and C++? I am intersted in hearing your reasons for your opinion as well. If this is an old topic forgive me for rehashing.
curlious is offline

09-09-2005, 08:59 AM	#2
Narf Nonconformist Join Date: Aug 2005 Posts: 174	I'm a little biased because I often write tools that need to be used in both C and C++. Usually the effort in porting the tools to "proper" C++ is impractical either in time or cost. So no it's not bad style to mix C and C++ in a lot of the work I do. But it really depends on what you do and how you do it. So there's not really a clean answer to your question. __________________ Just because I don't care doesn't mean I don't understand.
Narf is offline

09-09-2005, 10:02 AM	#3
curlious Registered User Join Date: Jul 2003 Posts: 450	It is good to know what a professional opinion holds, I was hoping for a few more replies before I stated my own opinion. I prefer not to mix c and c++ but part of this is ignorance. I prefer using c++ and I have rarely felt a need to resort to c to do any of the code I need. I feel that eventualy it is necessary to use non standard libraries and in a purist sence this is no worse than mixing c and c++. The main problem I feel is that certain compatiblity problem can occur when you mix the code and this can produce unforsee side affects.
curlious is offline

09-09-2005, 10:30 AM	#4
CornedBee Cat without Hat Join Date: Apr 2003 Posts: 8,492	In my opinion it's fine to mix libraries in C and C++ freely, but mixing C and C++ code in a single library is just inviting confusion, what with all the extern "C"s and so on. Basically, you want to call into C from C++, but avoid calling into C++ from C, because that means you must provide a C-style interface. __________________ All the buzzt! CornedBee "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code." - Flon's Law
CornedBee is offline

09-09-2005, 10:43 AM	#5
Salem and the hat of Jobseeking Join Date: Aug 2001 Location: The edge of the known universe Posts: 21,674	http://www.parashift.com/c++-faq-lit...c-and-cpp.html So long as you stick to compiling your C with a C compiler, and your C++ with a C++ compiler (and don't attempt to cast your C into C++ by various hacks), you should be OK. __________________ If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
Salem is offline

09-09-2005, 02:01 PM	#6
Ancient Dragon Registered User Join Date: Aug 2005 Posts: 1,265	except for fstream library functions I tend to use pure c++ functions -- I hate fstreams, FILE and associated functions are a lot simpler to use. I love c++ container classes such as <vector>, <list> and <string> because they are a great time saver. Often you can not avoid using C functions in C++. atol() can be substituted by istringstream, but why??
Ancient Dragon is offline

09-09-2005, 02:48 PM	#7
CornedBee Cat without Hat Join Date: Apr 2003 Posts: 8,492	I found that in every place where I find the C++ standard library unsuitable, the Boost libraries have provided the solution I was looking for. Just as an example, I much prefer lexical_cast over atol and any of its siblings. I find it far clearer. The functionality of the iostream library that made it so brilliant, namely the device-independence, was near impossible to use due to its complexity, but the new Boost IO library has remedied that. Suddenly you have gzip, zlib and bzip2 compression as well as base64 encoding out of the box. __________________ All the buzzt! CornedBee "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code." - Flon's Law
CornedBee is offline

09-10-2005, 10:04 AM	#8
Ancient Dragon Registered User Join Date: Aug 2005 Posts: 1,265	> I much prefer lexical_cast over atol and any of its siblings. I find it far clearer. In what way? atol() is simple enough -- only one argument. I downloaded boost libraries a week or so ago, but have never used it. A quick review looks like the programmer needs Ph.D. to understand it. How many decades does it take to get familar with it?
Ancient Dragon is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode