2009-03-15 5 views

Respuesta

19

Las funciones no especificadas en el estándar deben ir precedidas de un guion bajo como indicación de que son extensiones específicas del fabricante o que se adhieren a un estándar que no es ISO. Por lo tanto, el "cumplimiento" fue que Microsoft añadiera un guión bajo al nombre de esta función específica, ya que no forma parte del estándar ISO.

+1

Tienen su trabajo recortado convertir la API de Windows :-) –

+4

No creo que nadie haya afirmado que la API de Win32 era compatible con nada. windows.h ni siquiera compila si deshabilita las extensiones de lenguaje en VC++. :) – jalf

+1

Lo confuso es que lo hicieron para posponer funciones que no estaban en los encabezados C estándar también. –

3

Por lo que sé, getcwd() nunca ha formado parte de la norma ISO C++. _getcwd() definitivamente no lo es, ya que los nombres estándar no comenzarán con un guión bajo.

De hecho, el artículo de MSDN vincula a una página man que dice que está declarada en direct.h, que no es un archivo de encabezado Standard C++. El artículo me parece falso.

3

Para añadir al mensaje de Dan Olson: Ver ANSI C Compliance página en MSDN

Los nombres de funciones y variables globales específicas de Microsoft comienzan con un solo subrayado. Estos nombres pueden ser reemplazados solo localmente, dentro del alcance de su código. Por ejemplo, cuando incluye archivos de encabezado de tiempo de ejecución de Microsoft, aún puede anular localmente la función específica de Microsoft denominada _open declarando una variable local del mismo nombre. Sin embargo, no puede usar este nombre para su propia función global o variable global.

4

Como otros ya han señalado, getcwd no está incluido en ISO C++, pero es parte de POSIX/IEEE Std 1003.1.

Microsoft ha decidido incluir algunas de las funciones POSIX más utilizadas en su biblioteca estándar C (pero prefija estas funciones con un guión bajo para desalentar esencialmente su uso).

23

Hay un good discussion sobre eso. P.J. Plauger respuestas a esta

Soy el tipo que insiste en 1983 que el espacio de nombres disponibles para un programa en C puede dividir en:

a) las definidas por la aplicación de la beneficio del programador (como printf)
b) las reservadas para el programador (como foo)
c) las reservadas a la aplicación (tal como _unlink)

Nos sabía ya entonces que "la ejecución" era demasiado monolítica - menudo más de una fuente de materiales de bits de la aplicación - pero eso era lo mejor que podíamos hacer en ese momento. El estándar C++ ha introducido espacios de nombres para ayudar, pero solo han logrado una fracción de sus objetivos declarados. (Eso es lo que sucede cuando se estandarizar un tigre de papel.)

En este caso particular, Posix suministra una lista de la categoría (a) Nombres (como unlink) que debe obtener define cuando y sólo cuando incluyes ciertos encabezados.Dado que C Standard robó sus encabezados de Unix, que es la misma fuente que para Posix, algunos de esos encabezados se superponen históricamente. Sin embargo, las advertencias del compilador deben tener alguna forma de tener en cuenta si el entorno compatible es "puro" Estándar C++ (un ideal platónico) o un entorno mixto C/C++/Posix . El intento actual de Microsoft de ayudarnos a los programadores pobres no lo tiene en cuenta. Insiste en tratar el desvinculación como un nombre de categoría (b), que es miope.

Bueno, GCC no declarará nombres POSIX en el modo C estricta, por lo menos (sin embargo, todavía lo hace en el modo C++):

#include <stdio.h> 

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

salida usando -std=c99

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

Usted tendrá que decirle explícitamente que está operando en un C/Posix mixto al usar macros de prueba de características o que no pasa ningún estándar específico. Se establecerá de manera predeterminada en gnu89, lo que supone un entorno mixto (man feature_test_macros). Aparentemente, MSVC no tiene esa posibilidad.

+3

GCC no declara nombres POSIX o incluso C estándar. Ese es el trabajo de glibc. – Potatoswatter

2

Para el registro, ISO no desaprobó getcwd(). Fue "obsoleto" por Microsoft. Microsoft reescribió muchas funciones C, a menudo con un poco más de seguridad en mente (por ejemplo, funciones de cadena que también toman un parámetro max_length). Luego hicieron que su compilador escupiera estas advertencias, lo que considero falso porque ningún grupo de estándares desaprobó ninguna de las funciones declaradas en desuso.

+8

_CRT_SECURE_NO_WARNINGS and forget :) –

+0

Pregunta: "¿por qué getcwd() no cumple con la ISO?/Este artículo de MSDN indica que getcwd() ha quedado obsoleto ..." Respuesta: "getcwd() no está en desuso; Microsoft está escupiendo advertencias con una extraña definición de 'obsoleto' ". ¿Cómo no responde eso la pregunta? ¿De qué manera estaba pidiendo una aclaración? –

+0

'getcwd()' también está obsoleto por GNU.Consulte la página de manual "Por razones de portabilidad y seguridad, el uso de getwd() está en desuso". –

3

El artículo de MSDN es algo confuso en lo que una persona normal concluiría de una lectura rápida (si no lo leen con un ojo muy cuidadoso de un abogado).

Lo que el artículo de MSDN dice es: getcwd() no es compatible con el estándar ISO C++. Para cumplir con ese estándar ISO C++ para nombrar funciones (que es lo que getcwd viola), Microsoft pone correctamente un _ en el frente de la función, por lo que la misma función se convierte en _getcwd(). Esa es la forma compatible con ISO C++ para nombrar la función porque getcwd() y _getcwd() no son una función estándar de ISO C++, sino que son una función específica de implementación específica de Microsoft (proveedor).

El artículo no indica qué sería una llamada estándar ISO de C++ para obtener el directorio de trabajo ... aunque eso es lo que la gente tiende a leer de un vistazo rápido.

Cuestiones relacionadas