为什么getcwd()不符合ISO C++？

这篇MSDN文章指出getcwd()已被弃用,而且应该使用ISO C++兼容的_getcwd,这就提出了一个问题:是什么让getcwd()不符合ISO标准？

1> Johannes Sch..：

---

对此进行了很好的讨论.PJ Plauger回答了这个问题

我是那个在1983年坚持认为可以将C程序可用的名称空间划分为:

a)为程序员的利益而定义的那些(例如printf)
b)为程序员保留的那些(例如foo)
c)为实现保留的那些(例如_unlink)

我们甚至知道"实现"过于单一 - 通常不止一个源提供实现的部分 - 但这是我们当时可以做的最好的.标准C++已经引入了命名空间来帮助,但它们只实现了其既定目标的一小部分.(这就是当你标准化纸老虎时会发生的事情.)

在这种特殊情况下,Posix提供了一个类别(a)名称列表(例如取消链接),当您包含某些标题时,您应该定义这些名称.由于C标准从Unix中窃取了它的标题,这与Posix的源头相同,因此其中一些标题在历史上重叠.然而,编译器警告应该有某种方式考虑支持的环境是"纯粹的"标准C++(柏拉图式理想)还是混合C/C++/Posix环境.微软目前帮助我们糟糕的程序员的尝试未能将其考虑在内.它坚持将unlink视为一个类别(b)名称,这是近视.

好吧,GCC不会在严格的C模式下声明POSIX名称,至少(尽管它仍然在C++模式下):

#include 

int main() {
    &fdopen;
    return 0;
}

输出使用 -std=c99

test.c: In function 'main':
test.c:4: error: 'fdopen' undeclared (first use in this function)

您必须明确告诉它您使用功能测试宏在混合C/Posix中操作或不传递任何特定标准.然后默认为gnu89假定混合环境(man feature_test_macros).显然,MSVC没有这种可能性.

---

GCC不声明POSIX甚至标准C名称.这是glibc的工作.

2> Dan Olson..：

---

标准中未指定的功能应该以下划线为前缀,表示它们是特定于供应商的扩展或符合非ISO标准.因此,此处的"合规性"是Microsoft为此特定功能的名称添加下划线,因为它不是ISO标准的一部分.

---

@Stuart - 这并不令人困惑......打破POSIX似乎是他们的作案手法.微软鼓励开发人员使用Win32 API是有益的.

---

Windows API不是C或C++运行时库的一部分.

---

我认为没有人声称Win32 API符合任何规定.如果在VC++中禁用语言扩展,则windows.h甚至无法编译.:)