2009-03-15 19 views

risposta

19

Le funzioni non specificate nello standard devono essere precedute da un carattere di sottolineatura come un'indicazione che sono estensioni specifiche del fornitore o aderiscono a uno standard non ISO. Quindi la "conformità" qui è stata per Microsoft per aggiungere un trattino basso al nome di questa specifica funzione poiché non fa parte dello standard ISO.

+1

Hanno il loro lavoro tagliato convertendo l'API di Windows :-) –

+4

Non penso che nessuno abbia mai affermato che l'API Win32 fosse compatibile con qualsiasi cosa. windows.h non si compila nemmeno se si disabilitano le estensioni della lingua in VC++. :) – jalf

+1

La cosa confusa è che hanno fatto questo per funzioni posix che non erano presenti anche nelle intestazioni C standard. –

3

Per quanto ne so, getcwd() non è mai stato parte di ISO Standard C++. _getcwd() sicuramente non lo è, poiché i nomi standard non inizieranno con un trattino basso.

In effetti, l'articolo MSDN si collega a una pagina man che afferma che è dichiarata in direct.h, che non è un file di intestazione C++ standard. L'articolo sembra fasullo per me.

3

Per aggiungere al post di Dan Olson: Vedere ANSI C Compliance pagina su MSDN

I nomi delle funzioni e variabili globali specifiche di Microsoft iniziano con un singolo trattino. Questi nomi possono essere sovrascritti solo localmente, nell'ambito del codice. Ad esempio, quando si includono i file di intestazione di runtime Microsoft, è ancora possibile sovrascrivere localmente la funzione specifica di Microsoft denominata _open dichiarando una variabile locale con lo stesso nome. Tuttavia, non è possibile utilizzare questo nome per la propria funzione globale o variabile globale.

4

Come altri hanno già sottolineato, getcwd non è incluso in ISO C++, ma fa parte di POSIX/IEEE Std 1003.1.

Microsoft ha deciso di includere alcune delle funzioni POSIX più comunemente utilizzate nella libreria standard C (ma prefigura queste funzioni con un carattere di sottolineatura per scoraggiare essenzialmente il loro utilizzo).

23

C'è uno good discussion a tale proposito. P.J. Plauger risposte a questa

Sono il ragazzo che ha insistito di nuovo nel 1983 che lo spazio di nomi disponibili a un programma C essere suddivisa in:

a) quelli definiti dalla realizzazione per la vantaggio del programmatore (come printf)
b) quelli riservati al programmatore (come ad esempio foo)
c) quelli riservati alla realizzazione (come _unlink)

Sapevamo anche allora che "l'attuazione" era troppo monolitico - spesso più di uno approvvigionarsi bit di attuazione - ma che è stato il migliore che potevamo fare in quel momento. Lo standard C++ ha introdotto gli spazi dei nomi per aiutare, ma hanno raggiunto solo lo una frazione dei loro obiettivi dichiarati. (Questo è quello che succede quando si standardizzare una tigre di carta.)

In questo caso particolare, Posix fornisce un elenco di categorie (a) i nomi (come unlink) che si dovrebbe ottenere definito quando e solo quando si includete determinate intestazioni.Poiché il C Standard ha rubato le intestazioni da Unix, che è la stessa fonte di Posix, alcune di queste intestazioni si sovrappongono storicamente. Tuttavia, gli avvertimenti del compilatore dovrebbero avere un modo per tenere in considerazione se l'ambiente supportato è "puro" standard C++ (un ideale Platonic) o misto C/C++/Posix . L'attuale tentativo di Microsoft di aiutare noi poveri programmatori non riesce a tenerne conto. Insiste sul trattamento dello scollegamento come nome di categoria (b), che è miope.

Beh, GCC non dichiarerà nomi POSIX in modalità C rigorosa, almeno (anche se, lo fa ancora in C modalità ++):

#include <stdio.h> 

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

uscita utilizzando -std=c99

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

È dovrò dirlo esplicitamente che stai operando in un misto C/Posix usando macro di test di funzionalità o non passando alcun standard specifico. Verrà automaticamente impostato su gnu89 che presuppone un ambiente misto (man feature_test_macros). Apparentemente, MSVC non ha questa possibilità.

+3

GCC non dichiara POSIX o anche nomi C standard. Questo è il lavoro di glibc. – Potatoswatter

2

Per la registrazione, getcwd() non è stato ritirato dall'ISO. È stato "deprecato" da Microsoft. Microsoft ha riscritto molte funzioni C, spesso con un po 'di sicurezza in mente (ad esempio, le funzioni di stringa che assumono anche un parametro max_length). Hanno quindi chiesto al compilatore di emettere questi avvertimenti, che considero falsi perché nessun gruppo di standard ha deprecato nessuna delle funzioni dichiarate deprecate.

+8

_CRT_SECURE_NO_WARNINGS e dimenticare :) –

+0

Domanda: "perché getcwd() non è conforme ISO?/Questo articolo MSDN afferma che getcwd() è stato deprecato ..." Risposta: "getcwd() non è deprecato; Microsoft sta sputando gli avvisi con una strana definizione di "deprecato". " Come non rispondere alla domanda? In che modo chiedevo chiarimenti? –

+0

'getcwd()' è deprecato anche da GNU.Vedi la pagina man "Per motivi di portabilità e sicurezza, l'uso di getwd() è deprecato." –

3

L'articolo MSDN è un po 'confuso in quello che una persona normale concluderebbe da una semplice lettura (se non la leggono con un occhio molto attento da parte dell'avvocato).

L'articolo di MSDN dice: getcwd() non è conforme allo standard ISO C++. Per rispettare lo standard ISO C++ per la denominazione delle funzioni (che è ciò che viola getcwd), Microsoft inserisce correttamente _ sulla parte anteriore della funzione, quindi la stessa funzione diventa _getcwd(). Questo è il modo conforme ISO C++ di nominare la funzione perché getcwd() e _getcwd() non sono una funzione standard ISO C++, ma sono una funzione specifica di Microsoft (fornitore) o di implementazione.

L'articolo non indica che cosa una chiamata standard ISO C++ per ottenere la directory di lavoro sarebbe ... anche se questo è ciò che le persone tendono a leggere in una rapida occhiata.

Problemi correlati