Mixing C and C++

This is a discussion on Mixing C and C++ within the A Brief History of Cprogramming.com forums, part of the Community Boards category; In your opinion is it bad practice to mix C and C++? I am intersted in hearing your reasons for ...

  1. #1
    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.

  2. #2
    Nonconformist Narf's Avatar
    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.

  3. #3
    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.

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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

  5. #5
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,831
    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.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  6. #6
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    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??

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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

  8. #8
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    > 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?

  9. #9
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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?

    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.
    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

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21