Pourquoi getcwd () n'est-il pas conforme à ISO C ++?

Question

Cet article MSDN indique que getcwd () est obsolète et _getcwd compatible ISO C ++ doit être utilisé à la place, ce qui soulève la question suivante: qu'est-ce qui rend getcwd () non conforme à ISO?

Answer 1

Les fonctions non spécifiées dans la norme sont supposées être précédées d'un trait de soulignement, ce qui indique qu'elles correspondent à des extensions propres au fournisseur ou à une norme non ISO. Ainsi, le " compliance " Microsoft a dû ajouter un trait de soulignement au nom de cette fonction spécifique, car elle ne fait pas partie de la norme ISO.

Answer 2

Il existe un bonne discussion à ce sujet. P.J. Plauger répond à cette

  

Je suis le gars qui a insisté en 1983 pour que l'espace de   Les noms disponibles pour un programme C doivent être partitionnés en:

     

a) ceux définis par la mise en œuvre au bénéfice du programmeur (tels que printf)
    b) ceux réservés au programmeur (tels que foo)
    c) ceux réservés à la mise en œuvre (tels que _unlink)

     

Nous savions même alors que "la mise en œuvre" était trop monolithique -   souvent plusieurs sources fournissent des éléments de la mise en œuvre -   mais c’était ce que nous pouvions faire de mieux à l’époque. C ++ standard   a introduit des espaces de noms pour aider, mais ils n’ont atteint que   une fraction de leurs objectifs déclarés. (C'est ce qui arrive quand tu   standardiser un tigre de papier.)

     

Dans ce cas particulier, Posix fournit une liste de noms de catégorie (a)   (par exemple, UnLink) que vous devez définir quand et seulement quand vous   inclure certains en-têtes. Depuis que la norme C a volé ses en-têtes de   Unix, qui est la même source que pour Posix, certains de ces en-têtes   se chevauchent historiquement. Néanmoins, les avertissements du compilateur devraient avoir   un moyen de prendre en compte si l'environnement pris en charge   est " pure " Standard C ++ (idéal platonicien) ou mixte C / C ++ / Posix   environnement. La tentative actuelle de Microsoft pour nous aider pauvres   les programmeurs ne parviennent pas à en tenir compte. Il insiste sur le traitement   dissocier en tant que nom de catégorie (b), qui est myope.

Eh bien, GCC ne déclarera pas les noms POSIX en mode C strict, du moins (bien que ce soit toujours le cas en mode C ++):

#include <stdio.h>

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

Sortie avec -std = c99

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

Vous devrez lui indiquer explicitement que vous travaillez dans un mélange C / Posix en utilisant des macros de test de fonctionnalité ou en ne respectant aucune norme spécifique. Il utilisera par défaut gnu89 , qui suppose un environnement mixte ( man feature_test_macros ). Apparemment, MSVC n’a pas cette possibilité.

Answer 3

Comme d'autres l'ont déjà souligné, getcwd n'est pas inclus dans ISO C ++, mais fait partie de POSIX / Norme IEEE 1003.1.

Microsoft a décidé d’inclure certaines des fonctions POSIX les plus utilisées dans leur bibliothèque standard C (mais préfixez-les par un trait de soulignement pour décourager essentiellement leur utilisation).

Answer 4

Pour ajouter au message de Dan Olson: voir Conformité ANSI C page sur MSDN

  

Les noms des fonctions spécifiques à Microsoft et des variables globales commencent par un simple trait de soulignement. Ces noms ne peuvent être remplacés que localement, dans le cadre de votre code. Par exemple, lorsque vous incluez des fichiers d'en-tête d'exécution Microsoft, vous pouvez toujours remplacer localement la fonction spécifique à Microsoft nommée _open en déclarant une variable locale du même nom. Cependant, vous ne pouvez pas utiliser ce nom pour votre propre fonction globale ou variable globale.

Answer 5

Autant que je sache, getcwd () n’a jamais fait partie de la norme ISO C ++. _getcwd () ne l’est certainement pas, car les noms standard ne commenceront pas par un trait de soulignement.

En fait, l'article MSDN est lié à une page de manuel indiquant qu'elle est déclarée dans direct.h , ce qui n'est pas un fichier d'en-tête Standard C ++. L'article me semble faux.

Answer 6

Pour l'enregistrement, getcwd () n'était pas obsolète par ISO. Il était "obsolète". par Microsoft. Microsoft a réécrit de nombreuses fonctions C, souvent dans un souci de sécurité (par exemple, les fonctions de chaîne qui utilisent également un paramètre max_length ). Ils ont ensuite fait compiler ces avertissements par le compilateur, ce que je considère comme fictif, car aucun groupe de normes n’a déconseillé d’exercer les fonctions déclarées obsolètes.

Answer 7

L'article de MSDN est un peu déroutant en ce qu'une personne normale pourrait conclure d'une simple lecture rapide (si elle ne le lit pas avec un œil d'avocat très attentif).

Voici ce que dit l'article MSDN: getcwd () n'est pas conforme à la norme ISO C ++. Pour se conformer à cette norme ISO C ++ en matière de dénomination de fonctions (ce que getcwd enfreint), Microsoft a correctement placé un _ sur le dessus de la fonction. La même fonction devient donc _getcwd (). C’est le moyen de nommer la fonction conforme à ISO C ++ car getcwd () et _getcwd () ne sont pas une fonction standard ISO C ++, mais une fonction spécifique à Microsoft (fournisseur) ou à une implémentation.

L'article n'indique pas ce qu'un appel standard ISO C ++ pour obtenir le répertoire de travail serait ... bien que ce que les gens ont tendance à lire d'un coup d'œil.