C++Builder 13 中 StrPCopy 调用为何出现二义性？

结论

这条报错表示，编译器在当前翻译单元中找到了多个可匹配的 StrPCopy 声明。仅凭问题中的代码，无法确定具体是哪些声明造成二义性，也无法判断问题是否由某个编译选项引起。

命名空间限定符也要注意大小写。C++ 区分大小写，System::SysUtils 和 System::Sysutils 是不同名称。请以当前安装版本生成的头文件中的声明为准。如果头文件使用的是 System::Sysutils，限定调用时也要保持这个拼写。

先查看编译器列出的候选函数

在 StrPCopy(str, edit1->Text) 中，str 是 char 缓冲区，edit1->Text 是控件文本属性。遇到二义性报错时，先查看完整诊断信息，特别是候选函数声明及其所在的头文件。候选列表可以确认当前项目实际看到了哪些重载。

如果候选声明都来自预期的 SysUtils 单元，可以尝试用头文件中声明的完整命名空间限定函数名。例如，只有生成的声明确实位于 System::Sysutils 时，才写成：

System::Sysutils::StrPCopy(str, edit1->Text);

如果限定后仍有二义性，说明命名空间限定没有解决参数重载之间的歧义。此时应根据候选声明，明确传入与目标缓冲区类型相符的源参数类型。先确认所用重载接受哪种参数类型，再选择转换方式。

对比能编译和不能编译的项目

既然其他 C++Builder 13 项目中的相同调用可以编译，可以比较两个项目实际参与编译的内容：

1. 查看报错项目和正常项目包含了哪些 SysUtils 相关头文件，确认是否有重复声明或不同版本的声明。
2. 检查 using 声明、同名函数声明、宏和预编译头文件，确认它们是否改变了 StrPCopy 的可见范围。
3. 比较编译器列出的候选函数，而不只是源代码中的调用行。
4. 查看当前版本生成的头文件，确认函数名、命名空间拼写和参数类型。

差异可能来自项目的包含文件或声明环境。现有信息不足以确定具体原因。

缓冲区容量

无论最终使用哪个重载，都要确认源文本能放入 str。该数组容量为 1024 字节，且必须为字符串终止符留出空间。如果所选函数没有接收缓冲区容量的参数，仅靠函数调用无法保证不会越界。迁移旧代码时，建议检查实际文本长度，以及字符编码转换后的字节数。

备注：内容仅供参考。