在C++中使用C是坏的吗？

很多人告诉我，C++中使用C是不好的，因为它不是安全的，它需要更多的内存管理。我一直告诉他们，只要你知道你在做什么，你删除你的"新"和释放你的"malloc"，那么c就没有问题。

我现在正在一个论坛上讨论关于std::string对char*的争论。有人说分配一个简单的char*内存块更有效，只要您解除分配它，就可以了。另一方面，有人说std::string更优越，因为它不涉及内存管理，但效率较低。

所以这里的主要问题是：

• 混合C/C++是坏的吗？当你编码C++时，你应该只使用100% C++吗？

任何答案都将不胜感激！

I keep telling them that as long as you know what your doing, and you delete your new's and free your malloc's then C isn't a problem.

这是真的；如果你非常小心并且确保手动清理东西，那么这不是问题。但你真的有时间这么做吗？每次调用new都可以抛出std::bad_alloc。是否总是捕获可以抛出的每个异常并手动清理任何资源？

我冒昧地猜测答案是"不"，因为这样编写代码非常繁琐，而且很难完全确定这样编写的代码是正确的，即使在极少的失败情况下也是如此。

如果答案是"是"，那你为什么要浪费这么多时间担心资源管理？C++习语，如范围绑定资源管理(SBRM；通常称为资源获取是初始化(RAII))，并且像标准模板库这样的库可以帮助您更容易地编写正确的代码。当你不需要的时候，为什么要这样做？

Should you ONLY use 100% C++ when your coding C++?

是的，但是如果有一个C库可以做您需要的事情，或者如果您有您想要使用的遗留C代码，那么您当然可以使用该代码；只是一定要小心。通常，与C代码互操作最干净的方法是在它周围写一个C++包装器。

我的坚定信念是，你的问题根本不与C或C++有关。你的问题是为了安全而交易不可靠的效率。是的，C可以更有效。但是有多少效率更高呢？你要付多少钱？这些是你应该回答的问题。在大多数情况下，字符串与常量char*的开销是不明显的。如果您正在开发一个效率非常关键的应用程序，那么为什么不首先用C编写它呢？

我真的对答案和评论的两极分化感到惊讶。

在我看来，答案很简单：

When writing a C++ project, use C++, avoid C ( and family) and stick to the Standard Library and STL. Ensure a homogenous C++ interface (it is a C++ project after all!)
When using an external project in C, which happens to be written in C, of course you can use it. (see examples below)

两个主要示例：

我知道这两个例子都很…浅…但我觉得他们表达了一个足够笼统的想法。

是的，混合C和C++是不好的，任何原因都与性能或安全无关。

这是可维护性的不良原因：* C++程序员希望所有代码都像C++一样运行。*C程序员希望所有代码的行为都像C。

因此，当你混合C++和C时，你就打破了程序员对事物应该如何工作的期望。

更好的问题是，为什么使用C？表演？首先，我认为对于具有相同功能的程序来说，没有可测量的性能差异。其次，你必须了解并证明，对于你的特定情况，C++速度较慢。第三，你放弃了大量的应用程序安全，使用C代替C++。

答案当然是：这要看情况而定。

一般来说，您希望避免混淆可能导致混淆的内容，从而进一步导致难以发现的错误。仅仅因为"你知道你在做什么"并不意味着下一个接触你代码的人会知道你在做什么。如果您正在开发只有您才会使用的代码，那么它可能是可以的，但情况很少如此。

如果你小心的话，使用C作为性能是可以的。但只有当你知道你需要表演的时候，你才应该这样做。过早的低级优化是魔鬼的工作。

这是一个非常罕见的情况，使用char *过STD：：字符串将给你带来任何明显的性能优势，并且它只在那些确实可以做到的内存管理混乱中值得。

重排STD：String vs char *的论点。

STD：：字符串不会慢到char *(堆堆*)；许多实现速度更快，因为它们使用私有内存池。无论如何，STD：：字符串的健壮性远远超过任何(不可能的)PrF命中。

如果你说的是技巧，我会小心地说，做上面的事情是可以的。

使用C风格的程序组织技术编写C++程序可能会导致大量的可维护性问题。一般来说，程序员忽略了面向对象语言提供的许多好处。简单地说，因为C语法的大部分是有效的C++，许多编码技术的转换并不意味着你应该用C++来完成。

也就是说，使用C函数和东西不是问题，只要你小心使用它们。在某些情况下，你必须这样做。

在string与const char *的具体情况下，对于所有保存字符串常量(且仅包含字符串常量)的变量，应使用裸const char *，仅当传递到需要string的API时，才转换为string。持续这样做可以消除大量的全局构造函数，不会造成内存分配的麻烦(因为字符串常量是永久不变的数据)，而imo实际上使代码更清晰—您可以看到const char *，您知道这将是一个字符串常量。

Is using C in C++ bad?

虽然是一个主观的问题：在我看来，采取很大的措施避免在C++程序中使用C。

Many people have told me that using C in C++ is bad because it's not as safe, and it requires more memory management. I keep telling them that as long as you know what your doing, and you delete your new's and free your malloc's then C isn't a problem.

你正在重新介绍C++设计的缺陷和危险，这不是C++程序中的方法。

我经常检查/拒绝/重写进入代码库的代码，这些代码是"带有C++特征的C"，或者是"带有C特征的C++"。我甚至更改malloc、free等以在根命名空间中断言(除其他之外)。

I'm currently on a forum where an argument over std::string vs. a char* is taking place. Some people are saying that allocating a simple char* memory block is more efficient, and as long as you deallocate it, it's fine. On the other hand we have people saying that std::string is superior because it has no memory management involved but is less efficient.

在C++中，有更多的选项来表示字符串，而不是STD：：

在我看来，创建一个表示字符串并为特定目的服务的新类，或者遵循附加契约(必要时)是完全有效的。这种字符串表示的部分契约(当然)是，当使用动态内存时，它们使用new[]/delete[]管理自己的资源。

如果效率很重要，EDCOX1，1，对于特定的任务来说不太理想，那么C++就足够强大，通过在C++中创建一个专门的接口来表达你对这些特定情况的意图。在很多情况下，这是可以接受的(IMO)，但并不总是值得时间投资。在任何情况下，管理C语言习语/样式/危险都比C++程序更容易。

So the main question here is: Is mixing C/C++ bad? Should your ONLY use 100% C++ when your coding C++?

最好为您的需要创建可重用的基于对象的解决方案。所提供的示例中的危险可以完全封装(如果这种优化确实值得时间投资)，并且可以编写使用C++习语，而无性能损失和更好的可维护性。

这里简单的答案是，概述；确定哪一个最适合您的情况，并明智地使用它！

嗯，我的处境很奇怪。我正在研究一个应该是C++的系统(使用C++编译器，使用术语C++)，但是所有的东西都是用C编写的。这是非常令人沮丧的，因为它要达到一个点，我必须证明C++比C更有用，即使我们在C++中编码。当我引入STD：：String时，一切都是地狱。我的看法是，现在所有的东西都开始杂乱(C和C++的混合)。很少有错误处理的实例。实际上，我认为我可以计算3个系统范围的Try-Catch语句。代码杂乱无章，内存泄漏很明显，发现错误是大海捞针。有数百行代码可以用C++函数代替。我想说，编写代码更高效、更干净、更容易理解。

根据我的经验，当然，你可以混合C和C++。你几乎可以做你想做的任何事情，但是维护、调试和真正弄清楚发生了什么就成了一个问题。很容易说你要清理你的内存分配，但也许其他人使用了你的代码而没有。也许你忘记了这样做，你浪费了很多时间来寻找愚蠢的错误，而不是用这些时间来做一些有成效的事情。我甚至不认为应该有争论。当你做C++时，做C++。当你做C时，做C。