这篇 MSDN 文章 声明 getcwd() 已被弃用,应该使用 ISO C++ 兼容的 _getcwd 来代替,这就提出了一个问题:是什么导致 getcwd() 不符合 ISO 标准?

有帮助吗?

解决方案

在标准未指定功能都应该由一个下划线为表明他们是供应商特定的扩展或附着于非ISO标准前缀。因此,“遵守”这里是微软为下划线添加到该特定函数的名称,因为它不是ISO标准的一部分。

其他提示

有是href="https://groups.google.com/group/comp.os.ms-windows.programmer.misc/msg/e668fa9f36e57c67" rel="noreferrer">很好的讨论有关。 P.J. Plauger 回答这个

  

我是谁在1983年坚持背那个空间的家伙   提供给一个C程序名称被划分为:

     

<强> A)那些由实施为程序员的利益定义(例如printf),点击    的 b)中那些保留给程序员(比如foo),点击    的 c)中那些保留给实现(如_unlink)结果

     

我们知道,即使在当时说:“实施”太单片 -   往往不止一个源提供的执行位 -   但是,这是我们可以在当时做的最好的。标准C ++   先后引进命名空间提供帮助,但他们只取得了   他们的既定目标的一小部分。 (这是发生在你什么   标准化纸老虎。)

     

在该特定情况下,Posix的供给的类别(a)中名称的列表   (如取消链接),你应该得到时定义,只有当你   包括某些头。由于C标准窃取了它的头从   Unix的,这是相同的源作为Posix的,其中的一些报头的   历史上重叠。然而,编译器警告应该有   考虑到是否支持环境中的一些方法   是 “纯” 的标准C ++(柏拉图理想)或混合的C / C ++ / Posix的   环境。微软目前试图帮助我们这些可怜的   程序员没有考虑到这一点。它坚持治疗   解除连结作为(b)类名,这是近视。

那么,GCC将不会严格C模式声明POSIX名称,至少(虽然,它仍然没有在C ++模式):

#include <stdio.h>

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没有这种可能性。

正如其他人已经指出的那样, getcwd 不包含在 ISO C++ 中,而是 POSIX/IEEE 标准 1003.1。

Microsoft 已决定在其 C 标准库中包含一些最常用的 POSIX 函数(但在这些函数前添加下划线以从根本上阻止其使用)。

据我所知GETCWD()从未ISO标准C ++的一部分。 _getcwd()绝对不是作为标准名称不会以下划线开头。

事实上,MSDN文章链接到一个手册页,指出它在声明的 direct.h ,这是不是一个标准的C ++头文件。这篇文章似乎假我。

有关的记录,getcwd()不是由ISO弃用。它是由微软“过时”。在脑海里时常带着一点更好的安全性(比如字符串函数也采取max_length参数) - 微软重写了许多C函数。然后,他们有他们的编译器吐出这些警告,我认为假的,因为没有标准组弃用任何声明的函数弃用。

在MSDN文章是在什么一个正常的人会从仅仅是一种快速阅读的结论(如果他们不以非常谨慎的律师眼睛里看到了)有点混乱。

什么MSDN文章说是:GETCWD()是不符合ISO C ++标准。为了遵守与ISO C ++标准的函数命名(这是什么GETCWD违反),微软正式提出了_在函数的前面,所以同样的功能变得_getcwd()。这是ISO C ++符合命名功能的方式,因为GETCWD()和_getcwd()不是一个ISO C ++标准的功能,但是Microsoft(供应商)特异性的,或实现特定的功能。

在文章并不表示什么C ++ ISO标准调用来获取工作目录将是...虽然多数民众赞成人们往往会快速浏览阅读。

scroll top