2017-04-09 5 views
1

Les deux langages permettent à un seul programme/bibliothèque de s'étendre sur plusieurs fichiers. Les langages C utilisent des instructions utilisant des fichiers d'en-tête créés explicitement, alors que Fortran fait générer par le compilateur une interface à partir d'un seul module. Pardonnez-moi d'avance si j'ai mal compris comment l'une ou l'autre langue compile son code source. Dans les programmes c/C++, vous créez généralement des fichiers .c contenant du code source et des fichiers .h contenant l'interface de votre code afin que les autres fichiers sources puissent anticiper ce qui est dans la source, qui est ensuite compilé dans les bibliothèques Dans les programmes Fortran (90+), vous pouvez mettre du code dans des modules séparés, et au lieu d'écrire explicitement un fichier d'en-tête/interface pour chacun d'entre eux, le compilateur va générer des interfaces pour eux et les placer en fichiers binaires séparés (fichiers .mod) en plus des fichiers objet compilés. Créer des bibliothèques, des fichiers objets, etc. nécessite ensuite de les compiler/les lier ensemble.Différence subtile entre Fortran et c par rapport à la façon dont les sources sont interfacées et compilées ensemble

Pourquoi y a-t-il une différence subtile entre la façon dont ces langages compilent leurs interfaces? Est-ce juste une bizarrerie qui résulte des longues histoires de l'une ou l'autre langue?

+0

La norme Fortran ne dit rien sur les fichiers '.mod'. – francescalus

+2

Si différentes langues ne pouvaient pas utiliser différentes approches pour accomplir les mêmes choses, combien de langues aurions-nous? – Dmitri

+2

Oui, c'est surtout un artefact de l'histoire du développement de chaque langue. Et d'autres langues (comme, par exemple, Java) font leur propre chose. Il n'y a aucune raison de s'attendre à ce que deux langues différentes utilisent les mêmes conventions pour compiler et lier du code dans plusieurs fichiers source. –

Répondre

4

C est beaucoup moins organisé que vous ne le pensez. L'utilisation des fichiers "header" est purement une convention ; le préprocesseur permet des inclusions textuelles arbitraires, et il n'y a pas de division raisonnée entre "interface" et "implémentation" intégrée dans le langage.

Le fait est que le fait de relier des unités de traduction séparées d'un programme C n'est pas vérifié ou "sûr"; c'est votre responsabilité que les pièces que vous liez correspondent réellement.

Au début C, les déclarations de fonction pouvaient être implicites, et les arguments de fonction n'étaient pas vérifiés du tout. Vous pouvez donc placer un appel foo(1, 2, 3) dans votre code, et cela impliquerait la déclaration d'une fonction int foo(), et les arguments devront correspondre aux paramètres que la définition de fonction éventuelle utilisera.

Les deux principales caractéristiques de C qui font en-tête des fichiers utiles sont déclarations et prototypes de fonction. Si vous acceptez de toujours exiger une déclaration explicite d'une fonction avant de l'utiliser (ce dont les compilateurs peuvent vous avertir), vous pouvez fournir cette déclaration dans un "fichier d'en-tête", et il y a de meilleures chances que le lien soit adapté. Les prototypes de fonctions sont une extension du concept de déclarations qui corrigent automatiquement les arguments sur le site d'appel avec les paramètres de la définition de fonction. Ainsi, si vous choisissez d'utiliser toutes ces fonctionnalités, vous pouvez documenter raisonnablement . Mais tout cela est purement conventionnel!

+0

En fait, C moderne (depuis C99) nécessite des déclarations de fonctions avant de les utiliser. – Olaf

+0

@Olaf: Oui, mais vous pouvez toujours exécuter cette déclaration localement, comme 'extern f();'. [Démo] (https: // wandbox.org/permlink/nZyH1HxbFhECggel) –

+0

Une déclaration 'extern' n'est pas locale actuellement. Quoi qu'il en soit, vous avez raison, un déclarateur non-prototype est toujours autorisé. Il vient d'être fait une fonction d'obsolescence dans C11 (pas sûr si c'était déjà en C99). OMI un autre point que le comité était trop timide pour rendre la langue plus sûre. Je parie qu'ils ne retireront pas cet héritage d'un héritage même de C2x. – Olaf