在C++代码中使用/混合C?

Bra*_*rad 22 c c++ memory-management mixing

在C++中使用C是不是很糟糕?

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

我目前正在一个论坛上发表关于std::string与a 的争论char*.有些人说分配一个简单的char*内存块效率更高,只要你解除分配它就没问题了.另一方面,我们有人说这std::string是优越的,因为它没有涉及内存管理,但效率较低.

所以这里的主要问题是:

  • 混合C/C++不好吗?在编写C++时,你是否只能使用100%C++?

任何答案将不胜感激!

Jam*_*lis 17

我一直告诉他们,只要你知道你在做什么,然后你删除你的新东西并释放你的malloc,那么C不是问题.

这是真的; 如果你非常小心并确保你手动清理,那么这不是问题.但你真的有时间这样做吗?每次打电话都new可以扔掉std::bad_alloc.您是否始终捕获可以抛出的每个异常并手动清理任何资源?

我不敢猜测答案就是"不",因为写这样的代码是非常繁琐的,而且很难确定这样编写的代码是正确的,即使在罕见的失败的情况下也是如此.

如果答案是"是",那你为什么要浪费这么多时间来担心资源管理呢?C++习语如范围绑定资源管理(SBRM;通常称为资源获取是初始化(RAII))和标准模板库之类的库可以帮助您更轻松地编写正确的代码.当你不需要时,为什么事情很难?

你编译C++时只能使用100%C++吗?

是的,但是如果有一个C库可以做你需要的东西,或者如果你有你想要使用的遗留C代码,你肯定可以使用那些代码; 一定要小心.通常,与C代码互操作的最简洁方法是围绕它编写C++包装器.

  • 我在你的答案中没有看到任何特定于"C++项目中的C"的内容.你的论点似乎只是反对C,因此属于"挑选毒药"的土地. (2认同)
  • 啊对.异常是不从C调用C++的一个重要原因,但是从C++调用C是可以的(并且更常见) (2认同)

Arm*_*yan 12

我坚信你的问题与C或C++完全没有关系.你的问题是交易可疑的安全效率.是的,C可以更有效率.但效率更高?你为此付出了什么?这些是你应该回答的问题.在大多数情况下,字符串与const char*开销是不明显的.如果您正在开发一个效率极其关键的应用程序,那么为什么不首先在C中编写它?


rub*_*nvb 7

我对答案和评论中的两极分化感到非常惊讶.

在我看来,答案很简单:

编写C++项目时,使用C++,避免使用C(和系列)并坚持使用标准库和STL.确保一个同质的C++接口(毕竟它是一个C++项目!)当在C中使用外部项目时,恰好用C语言编写,当然你可以使用它.(见下面的例子)

两个主要的例子:

  1. 编写一个进行科学计算的C++程序/库.我肯定会使用GSL(GNU科学库),它用C语言编写.只有一些注意事项(如GSL中特定结构和函数的专用初始化和自由函数),可以在std::unique_ptrtypedef中被吸收.还存在错误处理的问题:如果需要/想要,可以在异常机制中抽象检查错误代码,或者可以保留计算函数中包含的错误代码.GSL确实有一种设置错误处理程序的方法,我想其他一些C库都有这样的功能.

  2. 使用Win32 API编写C++程序,这是一个非常基于C的程序.我在谈论轻量级API的使用,比如读取目录中的文件,检查文件是否存在等等,不是重GDI +或其他东西.我喜欢将Win32 API公开的所有C​​函数包装在漂亮的C++样式函数中,可能包含必要的异常并返回std::string而不必将char*缓冲区作为参数传递.

我理解这两个例子都很......很浅......但我觉得它们表达了一个足够普遍的想法.


Uni*_*dow 5

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

可维护性不好的原因是:
* C++ 程序员希望所有代码的行为都像 C++。
* C 程序员希望所有代码的行为都像 C。

所以当你混合 C++ 和 C 时,你打破了两个程序员对事情应该如何工作的期望。