在C++中使用C语言是否不好？
很多人告诉我，在C++中使用C语言是不好的，因为它不太安全，而且需要更多的内存管理。但我一直告诉他们，只要你知道自己在做什么，并且删除你的 "new "和释放你的 "malloc"，那么C语言就不会成为问题。
目前我在一个论坛上看到了关于std::string与char* 之间的辩论。有些人说分配一个简单的 char* 内存块更有效率，只要你在使用完后释放。另一方面，我们也有人认为std::string 更优越，因为它没有涉及到内存管理，尽管不如前者高效。
所以这里的主要问题是：
欢迎任何回答！
longjmp之类的疯狂用法）。手动管理C中的资源需要一些工作；在C++中几乎不可能。 - James McNellis我坚信你的问题与C或C++无关。你的问题是关于为了安全而牺牲效率的权衡。是的，C可能更加高效。但是它有多么高效？ 以及你为此付出了什么代价？ 这些都是你应该回答的问题。 在大多数情况下，string vs. const char* 的开销是不明显的。如果你正在开发一个极度关注效率的应用程序，那么为什么不一开始就用C编码呢？
我对回答和相关评论中的极化感到非常惊讶。
在我看来，答案很简单：
编写C++项目时，请使用C++，避免使用C（及其衍生版本），并坚持使用标准库和STL。确保具有同质的C++接口（毕竟这是一个C++项目！） 当在C++项目中使用外部以C编写的项目时，当然可以使用它。（见下面的示例）
两个主要的例子：
编写进行科学计算的C++程序/库。我肯定会使用GSL（GNU Scientific Library），因为它是用C编写的。只需要注意一些细节（例如专门为特定结构体和GSL内部函数提供的初始化和释放函数），可以用std::unique_ptr typedef进行吸收。还有错误处理问题：如果必要/想要的话，可以将检查错误代码抽象成异常机制，或者可以将错误代码包含在计算函数中。GSL确实有一种设置错误处理程序的方式，我想其他一些C库也有类似的功能。
使用基于C的Win32 API编写C++程序，这是非常基于C的。我谈论的是轻量级API使用，比如读取目录中的文件，检查文件是否存在等等，并非GDI+或其他复杂的东西。我喜欢用漂亮的C++风格函数包装Win32 API公开的所有C函数，可能还需要必要的异常并返回一个std::string，而不是必须将char*缓冲区作为参数传递。
我知道这两个例子都相当...表面...但我觉得它们表达了一个足够一般的想法。
混合使用C和C++是不好的，原因与性能或安全性无关:
它会影响可维护性：
因此，当你混合使用C++和C时，你破坏了两个程序员对事物应该如何工作的期望。
std::string 和 char* 的争论：
std::string 不会比堆上的 char* 慢；许多实现更快，因为它们使用私有内存池。而且无论如何，std::string 的健壮性远远超过任何（不太可能的）性能损失。string类的实用性弥补了任何性能损失。除非您未能满足硬性性能要求并且已经执行了所有高级优化，否则不要为了性能而牺牲可维护性和可读性。 - John Bode这里更好的问题是，为什么使用C语言？因为性能？首先，我认为对于具有相同功能的程序来说，没有可衡量的性能差异。其次，你需要分析并证明在你特定的情况下，C++更慢。第三，使用C而不是C++会牺牲大量应用程序安全性。
在C++程序中使用C是不好的吗？
虽然这是一个主观问题：在我看来，尽量避免在C++程序中使用C。
很多人告诉我，在C++中使用C不好，因为它不如安全，并且需要更多的内存管理。我一直告诉他们，只要你知道自己在做什么，并删除你的new和释放你的malloc，那么C就不是一个问题。
你正在重新引入c++旨在克服的缺陷和危险，并且这不是c++程序的做法。
我会定期检查/拒绝/重写进入代码库的“具有C ++功能的C”或“具有C功能的C ++”代码。我甚至会将malloc、free等修改为assert在根名称空间中（以及其他事情）。
我目前在一个论坛上，讨论std::string与char *之间的争论。有些人说，分配一个简单的char*内存块更有效率，只要你释放它就可以了。另一方面，我们有人说std::string更优越，因为它没有涉及到内存管理，但效率较低。
在 c++ 中，表示字符串的选项比 std::string 更多。
依我之见，完全可以创建一个新类来表示字符串并服务于特定目的，或者遵循附加合同（必要时）。这种字符串表示的一部分合同是（当然）使用new[]/delete[]来管理它们自己的资源，当使用动态内存时。
如果效率非常重要，而对于特定任务来说 std::string 不够理想，那么 c++ 足以表达您在这些特定情况下的意图，通过创建 c++ 中的专用接口。有很多情况下这是可接受的（依我之见），但不总是值得投入时间。无论如何，与将 C 语言习惯 / 风格 / 危险整合到 c++ 程序中相比，这更容易管理。
因此，主要问题是：混合使用 C/C++ 是不好的吗？在编写 c++ 时，你应该仅使用 100% 的 c++ 吗？
最好为您的需求创建可重用的基于对象的解决方案。提供的示例中的危险可以完全封装起来（如果此优化确实值得投入时间），并编写以使用 c++ 习惯方式的代码，而不会损失性能并具有更好的可维护性。
string 与 const char * 的特定情况下，对于所有保存 字符串常量（仅限字符串常量）的变量，应使用裸的 const char *，仅在传递给需要 string 的 API 时才转换为 string。始终如一地执行此操作可以消除大量全局构造函数，不会引起内存分配问题（因为字符串常量是永久的、常量数据），并且实际上使代码更清晰 - 当你看到 const char * 时，你知道那将是一个字符串常量。
int main() { int class = 2; }（这是有效的C代码，但不是有效的C++代码）。C++不是C的超集；C和C++共享一个公共子集。 - James McNellis