Top Mud Sites Forum - View Single Post

Kastagaar · 06-06-2003, 04:52 AM

(Reasons to use C over C++)

I can't say I've found a C++ compiler that, after having successfully compiled and linked, did not produce the expected output. What I have found is that some C++ compilers do not implement portions of the langauge. MSVC++ 6 does not support template-templates, for example. There is a set of C++, however, that is implemented by all C++ compilers, though, and it is possible to stick to this.

I link to C++ libraries quite often, actually. But in general, in either language, you only link against a library compiled by your own compiler. In some cases, there are tools to help (Borland C++ has a tool to convert libraries between Borland and MS formats, for example).

Some of the more powerful C++ libraries are also header-based, which means that there's no separate library to link against, meaning that it "just works".

What, that you "can't debug operator=() because the only way to track an error is to throw an exception"? Have you ever even looked up the rules of exception safety? Come back when you can tell me what the "strong exception safety guarantee" is, and why it would apply to this operator.

Sure, MSVC++ is a pretty good compiler, despite its language support. I suspect MSVC++.NET is pretty good too. GNU C++ will, when compiling C-like code, will produce the same output as GNU C (tested as of version 3.2). Except with better type checking, the ability to use *_cast<>, etc. This is why you can use it as a "better C"...

The language is a better C. But compiler support (sigh) is still lacking in some departments. Such as compilers for proprietary platforms. C, the compiler, is relatively easy to write. C++ has many more features, and is a far more expressive and powerful language, and this is how it pays.

But, for what it's worth, many companies also use C++ in their embedded software. It might be worth googling on "embedded C++" - a subset of the language considered by experts to be "safe" for embedded use.

That said, embedded software has its own set of rules, and is not a perfect counterexample.

So, in summary, I stand by my statement that there is no reason to use C over C++ except for the lack of a good compiler.

06-06-2003, 04:52 AM	#69
Kastagaar Member Join Date: Apr 2002 Location: Hampshire, UK Posts: 117	(Reasons to use C over C++) I can't say I've found a C++ compiler that, after having successfully compiled and linked, did not produce the expected output. What I have found is that some C++ compilers do not implement portions of the langauge. MSVC++ 6 does not support template-templates, for example. There is a set of C++, however, that is implemented by all C++ compilers, though, and it is possible to stick to this. I link to C++ libraries quite often, actually. But in general, in either language, you only link against a library compiled by your own compiler. In some cases, there are tools to help (Borland C++ has a tool to convert libraries between Borland and MS formats, for example). Some of the more powerful C++ libraries are also header-based, which means that there's no separate library to link against, meaning that it "just works". What, that you "can't debug operator=() because the only way to track an error is to throw an exception"? Have you ever even looked up the rules of exception safety? Come back when you can tell me what the "strong exception safety guarantee" is, and why it would apply to this operator. Sure, MSVC++ is a pretty good compiler, despite its language support. I suspect MSVC++.NET is pretty good too. GNU C++ will, when compiling C-like code, will produce the same output as GNU C (tested as of version 3.2). Except with better type checking, the ability to use *_cast<>, etc. This is why you can use it as a "better C"... The language is a better C. But compiler support (sigh) is still lacking in some departments. Such as compilers for proprietary platforms. C, the compiler, is relatively easy to write. C++ has many more features, and is a far more expressive and powerful language, and this is how it pays. But, for what it's worth, many companies also use C++ in their embedded software. It might be worth googling on "embedded C++" - a subset of the language considered by experts to be "safe" for embedded use. That said, embedded software has its own set of rules, and is not a perfect counterexample. So, in summary, I stand by my statement that there is no reason to use C over C++ except for the lack of a good compiler.