与C语言相比，C ++的局限性是什么？ [英] What would be C++ limitations compared C language?

问题描述

以下是C ++的优点

• C ++提供了他们所要求的特定功能


• 他们的C编译器几乎可以肯定是C ++编译器，因此不涉及软件成本


• C ++与C


• C ++代码一样可移植可以和C一样高效（或更高或更低）

• C++ provides the specific features they are asking about
• Their C compiler is almost certainly really a C++ compiler, so there are no software cost implications
• C++ is just as portable as C
• C++ code can be just as efficient as C (or more so, or less so)

是否存在任何具体原因和特定情况，其中必须在C ++上使用C？

Are there any concrete reasons and specific scenarios, where one has to use C over C++?

参考此问题： C语言中的泛型库

不是重复的，因为这个问题是在询问语言限制，而不是应该/不应该。不能学习一种语言。

Not a duplicate, because this question is asking about language limitations and not about should/shouldn't learn one language over another.

Peter Kirkham的帖子对我来说是最有用的信息，尤其是关于我没有考虑过的C99问题，因此我接受了。感谢所有其他参与的人。

推荐答案

我回答了一个当前的问题，该问题询问有关C的泛型库-发问者特别声明他们不想使用C ++。

This is prompted by a an answer I gave to a current question which asks about a generics library for C - the questioner specifically states that they do not want to use C++.

C是一种完整的编程语言。 C不是C ++的任意子集。 C根本不是C ++的子集。

C is a complete programming language. C is not an arbitrary subset of C++. C is not a subset of C++ at all.

这是有效的C：

foo_t* foo = malloc ( sizeof(foo_t) );

要使其作为C ++进行编译，您必须编写：

To make it compile as C++ you have to write:

foo_t* foo = static_cast<foo_t*>( malloc ( sizeof(foo_t) ) );

这不再是有效的C语言。 （您可以使用C样式的强制转换，在这种情况下它将在C中编译，但大多数C ++编码标准以及许多C程序员都避免使用它；在Stack Overflow上见证不要强制转换malloc注释）

which isn't valid C any more. (you could use the C-style cast, it which case it would compile in C, but be shunned by most C++ coding standards, and also by many C programmers; witness the "don't cast malloc" comments all over Stack Overflow).

它们不是同一语言，如果您在C中有一个现有项目，则不想重写只是为了使用库而使用了另一种语言。您可能希望使用可以使用您所使用的语言进行接口的库。（在某些情况下，可以使用一些 extern C 包装函数，具体取决于（关于如何使用模板/内联C ++库。）

They are not the same language, and if you have an existing project in C you don't want to rewrite it in a different language just to use a library. You would prefer to use libraries which you can interface to in the language you are working in. (In some cases this is possible with a few extern "C" wrapper functions, depending on how template/inline a C++ library is.)

在我正在研究的项目中获取第一个C文件，这就是如果您只交换 gcc std = c99 for g ++ ：

Taking the first C file in a project I'm working on, this is what happens if you just swap gcc std=c99 for g++:

sandiego:$ g++ -g  -O1 -pedantic -mfpmath=sse -DUSE_SSE2 -DUSE_XMM3  -I src/core -L /usr/lib -DARCH=elf64 -D_BSD_SOURCE -DPOSIX -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112L -Wall -Wextra -Wwrite-strings -Wredundant-decls -Werror -Isrc  src/core/kin_object.c -c -o obj/kin_object.o | wc -l
In file included from src/core/kin_object.c:22:
src/core/kin_object.h:791:28: error: anonymous variadic macros were introduced in C99
In file included from src/core/kin_object.c:26:
src/core/kin_log.h:42:42: error: anonymous variadic macros were introduced in C99
src/core/kin_log.h:94:29: error: anonymous variadic macros were introduced in C99
...
cc1plus: warnings being treated as errors
src/core/kin_object.c:101: error: ISO C++ does not support the ‘z’ printf length modifier
..
src/core/kin_object.c:160: error: invalid conversion from ‘void*’ to ‘kin_object_t*’
..
src/core/kin_object.c:227: error: unused parameter ‘restrict’
..
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier

总共69行错误，其中有四行是无效转化，但是主要是针对C99中存在的功能，而不是C ++中存在的功能。

In total 69 lines of errors, four of which are invalid conversions, but mostly for features that exist in C99 but not in C++.

这并不是说我正在使用这些功能来获得乐趣。

It's not like I'm using those features for the fun of it. It would take significant work to port it to a different language.

因此，建议

[a]几乎可以肯定C编译器确实是C ++编译器，因此没有软件成本问题

[a] C compiler is almost certainly really a C++ compiler, so there are no software cost implications

将现有的C代码移植到C ++的过程子集时通常会产生重大的成本影响。

There are often significant cost implications in porting existing C code to the procedural subset of C++.

因此建议'使用C ++ std :: queue类'作为在C中查找队列的库实现的问题的答案比建议'使用目标C'和'使用JNI调用Java java.util.Queue类要晚。 '或'调用CPython库'-目标C实际上是C（包括C99）的适当超集，并且Java和CPython库都可以直接从C调用，而不必移植不相关的代码转换为C ++语言。

So suggesting 'use the C++ std::queue class' as an answer to question looking for an library implementation of a queue in C is dafter than suggesting 'use objective C' and 'call the Java java.util.Queue class using JNI' or 'call the CPython library' - Objective C actually is a proper superset of C (including C99), and Java and CPython libraries both are callable directly from C without having to port unrelated code to the C++ language.

当然，您可以向C ++库提供C外观，但是一旦这样做，C ++就和Java或Python一样。

Of course you could supply a C façade to the C++ library, but once you're doing that C++ is no different to Java or Python.

这篇关于与C语言相比，C ++的局限性是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！