程序复制文件与使用ShellExecute和cp之间的权衡取舍是什么?

时间:2009-11-21 19:03:03

标签: c++ c file-io

在C / C ++中至少有两种复制文件的方法:程序性地使用ShellExecute。如果需要,我可以发布每个的解释,但我会假设这些方法是已知的。使用一种方法比另一种方法有优势吗?

5 个答案:

答案 0 :(得分:3)

手动方法可让您完全控制检测和响应错误的方式。您可以对访问控制,空间不足,来自外星人的恶意文件等编写不同的响应。如果您调用ShellExec(或其他平台上的道德等价物),则会在stderr上留下错误消息。使用Window-ed UI的应用程序不是那么热。

答案 1 :(得分:3)

程序上会为您提供更好的错误检查/报告,并且可以跨平台工作 - ShellExecute仅适用于Windows API。

您还可以使用第三方文件系统库来减轻烦恼 - boost :: filesystem是一个不错的选择。

答案 2 :(得分:1)

为什么不在system()/ ShellExecute等构建的程序中使用:

  1. 您的程序不会独立于平台
  2. 对此类函数的每次调用都会创建一个单独的执行单元
  3. 优点:

    1. 代码经过充分测试,因此更可靠
    2. 在这种情况下,经过充分测试的库是更理想的。

答案 3 :(得分:1)

应该避免调用外部应用程序,因为通常(特别是在Windows下)它们不会返回容易理解的错误代码并以不合需要的方式报告错误(stdout,错误窗口,......)。此外,您无法完全控制副本,并且仅仅为了执行文件复制而启动新应用程序通常是过度的,尤其是在Windows等平台上,其中进程是非常重量级的对象。

一个很好的折衷方案可能是使用操作系统为您提供的API(例如Windows上的CopyFile),它可以为您提供可靠的工作代码和明确定义的错误代码。

然而,如果你想成为跨平台,最简单的事情就是编写你自己的复制代码:毕竟它不是火箭科学,这是一个简单的任务,可以在几行标准C ++中完成代码。

答案 4 :(得分:1)

对于shell,您可以获得操作系统供应商实现的最佳可用功能实现的便利,但代价是增加了跨进程集成的复杂性。考虑处理错误,文件操作的异步性质,返回错误级别的意外丢失,对完成进度的有限或不存在的控制,无法响应“中止”/“重试”/“继续”交互请求等。