为什么要人为地限制你的code到C？ [英] Why artificially limit your code to C?

问题描述

这是由一个答案我给一个当前问题提示它要求有关泛型库对于C - 提问明确规定，他们不希望使用C ++。我对他和其他人的问题谁坚持使用C是为什么他们这样做时：

• C ++提供他们所要求的具体功能


• 他们的C编译器几乎可以肯定是一个真正的C ++编译器，所以没有软件成本的影响


• C ++是一样C作为便携


• C ++ code可以像C作为有效（或更多的话，或多或少左右）

请注意：这是不是要争论 - 我在动机语言的选择真正感兴趣。

编辑：有人建议，这是一个重复的，但我不认为它是。为了澄清，我感兴趣的是，为什么人们把自己限制的C子集。例如，在我提到的帖子提问者也许会把所有的旧的C code和只用C ++泛型容器为更好阵列 - 我感兴趣的是，为什么人们会这样抵抗？我不感兴趣，为什么你应该或不应该学习C或C ++。

彼得Kirkham的的职位对我来说是最翔实，特别是我没有考虑到的问题C99，所以我接受了。感谢所有其他人谁参加了会议。

解决方案

  

这是由一个答案我给当前的问题，询问有关泛型库对于C提示 - 提问明确规定，他们不希望使用C ++

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

这是合法的C：

  foo_t *富=的malloc（sizeof的（foo_t））;
 

要使它编译为C ++你必须写：

  foo_t *富=的static_cast＆LT; foo_t *＆GT;（的malloc（sizeof的（foo_t）））;
 

这是不合法的C了。 （你可以使用C风格的转换，它会编译这种情况下，在C，但大多数C ++编码标准避而远之）。

他们是不一样的语言，如果你用C有一个现有的项目，你不想重写它在不同的语言只是为了使用图书馆。你会preFER要使用的可以向接口中的语言，你在工作库中。

今年首C文件中的一个项目我工作，这是如果你只是换 GCC性病= C99 为 G ++会发生什么：

 圣迭戈：$ g ++的-g -O1 -pedantic -mfpmath = SSE -DUSE_SSE2 -DUSE_XMM3 -I SRC /核心-L / usr / lib目录-DARCH = ELF64 -D_BSD_SOURCE -DPOSIX  - D_ISOC99_SOURCE -D_POSIX_C_SOURCE = 200112L -Wall -Wextra -Wwrite弦-Wredundant-decls -Werror -Isrc SRC /核心/ kin_object.c -c -o OBJ / kin_object.o |厕所-l
22：在文件中从SRC /核心/ kin_object.c包括：
SRC /核心/ kin_object.h：791：28：错误：匿名复杂的宏是在C99介绍
26：在文件中从SRC /核心/ kin_object.c包括：
SRC /核心/ kin_log.h：42：42：错误：匿名复杂的宏是在C99介绍
SRC /核心/ kin_log.h：94：29：错误：匿名复杂的宏是在C99介绍
...
cc1plus：警告被视为错误
SRC /核心/ kin_object.c：101：错误：ISO C ++不支持'Z'printf的长度修改
..
SRC /核心/ kin_object.c：160：错误：从'无效*'到'kin_object_t *'无效的转换
..
SRC /核心/ kin_object.c：227：错误：未使用的参数'限制'
..
SRC /核心/ kin_object.c：271：错误：ISO C ++不支持'Z'printf的长度修改
SRC /核心/ kin_object.c：271：错误：ISO C ++不支持'Z'printf的长度修改
 

在总69行错误，其中4个是无效的转换，但主要是为存在于C99的功能，但不是在C ++。

这不是像我使用这些功能为它的乐趣。这将需要显著的工作移植到不同的语言。

所以这是完全错误的暗示。

  

[A] C编译器几乎可以肯定是一个真正的C ++编译器，所以没有软件成本的影响

有在移植现有的C code到C ++的程序集往往显著成本的影响。

所以提示的使用C ++的std ::队列类的作为问题答案寻找一个库实现在C队列比暗示的用客观C'dafter 和'调用使用JNI在Java java.util.Queue中的类或'叫CPython的库的 - 目标C实际上是C的超集（包括C99），以及Java和CPython的库都是直接调用从C，无需端口无关code到C ++语言。

当然，你可以提供一个C外观到C ++库，但一旦你这样做C ++是Java或Python没有什么不同。

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++. My question to him and others who insist on using C is why do they do so when:

• 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)

Please note: This is not intended to be argumentative - I am genuinely interested in the motivations for the choice of language.

Edit: It has been suggested that this is a duplicate, but I don't think it is. To clarify, I'm interested in why people limit themselves to the C subset. For example, the questioner in the post I referred to could have kept all his old C code and just used C++ generic containers as "better arrays" - I am interested in why are people so resistant to this? I am not interested in why you should or should not learn C or C++.

Peter Kirkham's post was for me the most informative, particularly with regard to C99 issues which I hadn't considered, so I've accepted it. Thanks to all others who took part.

解决方案

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 is a complete programming language. C is not an arbitrary subset of C++. C is not a subset of C++ at all.

This is valid C:

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

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

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

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

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.

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

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.

So it is plain wrong to suggest that

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

There are often significant cost implications in porting existing C code to the procedural subset of 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.

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.

这篇关于为什么要人为地限制你的code到C？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！