Thread: Mixing C with C++ code

I think the conclusion is:
1. It's not TECHNICALLY wrong to mix C and C++ if the resulting code performs the task required.

2. In a C++ educational situation, it is probably right to require that code that can within reason be solved in C++ _is_ solved in C++. There are situations where 5 lines of C becomes 15 lines of C++, then perhaps the C solution is actually more appropriate - sscanf() can be such a case, particularly if the input format is not designed for reading via C++ [e.g. it's got various formatting within the input itself, that scanf can accept and validate, but C++ cin doesn't without a fair bit of effort].

Where I work, we mix third party drivers written in C with our OS's C++ code - because we are not going to spend 6 man-years rewriting a graphics driver providing OpenGL to the client software - by the time that is finished and working correctly with good performance, the graphics processor is probably "old". But that is of course large chunks of C code mixed with other large chunks of C++ code - mixing it with a few lines of one, then a few lines of the other is not quite the same thing.

But both C and C++ are tools - they come in the C++ toolchest - so it's "ok" to use any of the tools. Part of learning to program is of course learning how to use which tool - just like a carpenter needs to learn when to use a broad chisel, a narrow chisel, a knife, a drill or a saw - they all do useful things, and you can SOMETIMES use one in place of the other, but one is most often better than another.

--
Mats

Originally Posted by JVene

If one defines an object as the collection of data and functions that act on that data relative to a particular subject (a loose one, it seems), then non-member functions can be part of an object.

Stroustrup points out that it's an error to place some functions inside a class simply because they are conceptually part of that class. If a function is applicable more generically, such that it would serve it's purpose for other objects or other contexts, placing it inside a class may limit it's usefulness (or re-usefulness).

The idea of genericity aside, appropriate provision of non-member non-friend functions can improve encapsulation.

Originally Posted by JVene

As I read the message is several of these texts I mentioned, the message is that "object oriented" isn't a function of the language constructs, but of the method of thought in design. This is partly what brings forward a school of thought that OOP and OOD can be implemented in C (and sometimes rather heated arguments result).

Yes, that is the school of thought that I subscribe to.

Originally Posted by R.Stiltskin

On the other hand, maybe matsp, brewbuck and grumpy have already said all that needs to be said about the original question...

Yes, I feel that your question has been sufficiently, though perhaps not satisfactorily, answered