中查找子菜单及其牛

使用新语法的原因之一就是为了生成可使用 /clr:safe 进行编译的程序，这是在代码安全性方面的最终目标。这有点类似于将您的程序锁在一个很清洁的房间中 - 您知道，这是一种经过消毒处理的环境，到处都是铬设备，您必须戴上面罩、穿上无菌鞋并通过负压气锁才能进入到其中。启动 /clr:safe 开关后，编译器便施加了所有严格的限制。您不能使用本机类型。您不能使用全局。您不能调用非托管函数。简言之，您不能做任何有趣的事。您为何要作茧自缚呢?只是为了确保您的代码是安全的。用技术术语来说，/clr:safe 将生成“可验证的”代码，这就意味着，公共语言运行时 (CLR) 能够验证您的代码不违反安全设置，例如，当用户的安全设置不允许访问文件时却对文件进行访问。/clr:safe 禁忌列表中的众多项之一就是本机指针 - 即指针。(“本机”是多余的，因为您不可能有一个指向托管类型的指针。)由于 /clr:safe 不允许使用指针，因此，旧的 argv 声明便不再使用。所以，Redmondtonians 对声明进行了更改，取而代之为使用 String^ 数组。由于数组知道其自身的长度，所以就没有必要再使用 argc 了。运行时库提供了相应的启动代码，用于在调用您的主函数之前创建和初始化 arg 数组。如果您不打算使用 /clr:safe，那么，您总是可以编写一个使用旧式 argc/argv 签名的主函数。　　这正解释了使用托管数组的原因，但 args[0] 呢?为什么它是第一个命令参数而不是文件名呢?我并不知道 Redmondtonians 的想法如何，但也许他们考虑到省略文件名会更合理，也许他们认为您不需要它。不论是哪种情况都无关紧要，因为获取文件名是很容易的事情。我确信可通过多种方法来获取文件名，但我所能想到的最显而易见的、以 CLR 为中心(与 /clr:safe 兼容)的方法是使用 System::Environment 类。它公开下列方法：

以下是引用片段：

staticarray^GetCommandLineArgs()

与提供给主方法的 args 参数不同，从 Environment::GetCommandLineArgs 返回的数组实际上确实是以可执行文件名开始的。

最后，您为什么一定要知道您自己的 EXE 文件的名称呢?毕竟您在编写程序，您或许知道它的名称。原因之一就是要生成包含程序名的帮助消息而不对其进行硬编码。帮助消息可能如下所示：

FooFile -- Turns every word in your file to \"foo\"

usage:

FooFile [/n:] filespec

filespec = the files you want to change

= change only the first occurrences

此处的 FooFile 为程序名。我可以只是在我的帮助文本中将其写为“FooFile”，但很久以前我就知道，我经常会重命名程序或将代码从一个程序复制到另一个程序中。通过从程序自身获取程序名(通过 argv 或 Environment::GetCommandLineArgs)，我的帮助消息始终会显示正确的名称，即使我重命名文件或将我的代码复制到另一个程序中也将如此。

祝您编程顺心如意!

如在外野炊野餐 请将您要提交给 Paul 的问题和意见发送至 cppqa@。

Paul DiLascia 是兼职软件顾问和资深的 Web/UI 设计师。他是《Windows++: Writing Reusable Windows Code in C++》(Windows++：在 C++ 中编写可重用 Windows 代码)一书 (Addison-Wesley, 1992) 的作者。Paul 在其业余时间里开发出了 PixieLib，可通过他的站 来获取该 MFC 类库。

查看本文来源