Le C ++ 20 exige-t-il que le code source soit stocké dans des fichiers?


106

Une question un peu étrange, cependant, si je me souviens bien, le code source C ++ ne nécessite pas de système de fichiers pour stocker ses fichiers.

Avoir un compilateur qui scanne les papiers manuscrits via une caméra serait une implémentation conforme. Bien que cela n'ait pratiquement pas beaucoup de sens.

Cependant, C ++ 20 ajoute maintenant l'emplacement source avec file_name. Cela implique-t-il maintenant que le code source doit toujours être stocké dans un fichier?


13
C'est en C depuis toujours - __FILE__. La classe source_locationvous permet simplement de l'obtenir sur le site d'appel de fonction.
StaceyGirl

28
Vous ne pouvez pas donner un nom de fichier à vos papiers manuscrits?
Jarod42

8
Je pense que c'est un détail de mise en œuvre, que le code source soit dans des fichiers ou autre chose. Si le compilateur peut recevoir du code source via stdin, la source peut se trouver dans une base de données.
Eljay

8
Mon exemple est peut-être un peu étrange, mais si vous utilisez un compilateur à la volée, tel que TCC, vous pouvez toujours fournir un nom de source lisible par l'homme pour des raisons de rapport d'erreurs, même si vous compilez directement à partir de la mémoire. Le fait d'avoir un "nom de fichier" n'implique pas du tout d'être stocké sous forme de fichier.
user7860670

2
Ce ne sont sûrement pas des fichiers d'implémentation tels que <iostream> ceux-ci (si vous voyez ce que je veux dire), pas les fichiers écrits par les développeurs?

Réponses:


110

Non, le code source ne doit pas provenir d'un fichier (ni aller dans un fichier).

Vous pouvez compiler (et lier) C ++ complètement dans un tube, en plaçant votre compilateur au milieu, par exemple

generate_source | g++ -o- -xc++ - | do_something_with_the_binary

et c'est comme ça depuis des décennies. Voir également:

L'introduction de std::source_locationdans C ++ 20 ne change pas cet état de fait. C'est juste que certains codes n'auront pas d'emplacement source bien défini (ou il peut être bien défini, mais pas très significatif). En fait, je dirais que l'insistance sur la définition à l' std::source_locationaide de fichiers est un peu myope ... même si, en toute honnêteté, c'est juste un équivalent sans macro de __FILE__et __LINE__qui existe déjà en C ++ (et C).

@ HBv6 note que si vous affichez la valeur de __FILE__lors de la compilation en utilisant GCC à partir du flux d'entrée standard:

echo -e '#include <iostream>\n int main(){std::cout << __FILE__ ;}' | g++ -xc++  -

exécuter les impressions exécutables résultantes <stdin>.

Le code source peut même provenir d'Internet.

@Morwenn note que ce code:

#include <https://raw.githubusercontent.com/Morwenn/poplar-heap/master/poplar.h>

// Type your code here, or load an example.
void poplar_sort(int* data, size_t size) {
    poplar::make_heap(data, data + size);
    poplar::sort_heap(data, data + size);
}

fonctionne sur GodBolt (mais ne fonctionnera pas sur votre machine - aucun compilateur populaire ne le prend en charge.)

Êtes-vous un avocat spécialisé dans les langues? Ok, alors consultons la norme.

La question de savoir si les sources de programmes C ++ doivent provenir de fichiers n'est pas clairement répondue dans la norme de langage. En regardant un brouillon de la norme C ++ 17 (n4713), la section 5.1 [lex.separate] se lit comme suit:

  1. Le texte du programme est conservé dans des unités appelées fichiers source dans ce document. Un fichier source avec tous les en-têtes (20.5.1.2) et les fichiers source inclus (19.2) via la directive de prétraitement #include, moins les lignes source ignorées par l'une des directives de prétraitement d'inclusion conditionnelle (19.1), est appelé une unité de traduction.

Ainsi, le code source n'est pas nécessairement conservé dans un fichier en soi, mais dans une "unité appelée fichier source". Mais alors, d'où viennent les includes? On pourrait supposer qu'ils proviennent de fichiers nommés sur le système de fichiers ... mais cela n'est pas non plus obligatoire.

En tout cas, std::source_locationne semble pas changer cette formulation en C ++ 20 ni affecter son interprétation (AFAICT).


9
Ce tube est un "fichier source" aux fins de la norme.
melpomene

5
Je regarde la norme C, qui définit: "Le texte du programme est conservé dans des unités appelées fichiers source (ou fichiers de prétraitement ) dans la présente Norme internationale." Donc, partout où le code est stocké, c'est un "fichier source" en Standardese. (Addendum: Un langage similaire se trouve dans la norme C ++ sous [lex].)
melpomene

8
@melpomene: Les unités sont simplement appelées fichiers source, cela ne dit pas qu'ils doivent en fait être des fichiers source. Mais je vais modifier la réponse pour l'inclure.
einpoklum

13
Juste essayé avec GCC: "echo '#include <stdio.h> \ nint main () {printf ("% s \\ n ", __FILE__); return 1;}' | gcc -o test -xc -" ( sans citations). Lorsqu'il est exécuté, il imprime <stdin>.
HBv6

11
Voici une chose amusante à propos des termes, des noms et des concepts dans les normes (et les sciences): ils sont généralement atomiques. Autrement dit, "fichier source" n'est pas nécessairement un "fichier" qui est "source", en fait, le terme "fichier" peut simplement ne pas être défini - comparer avec les nombres dans les mathématiques: il n'y a pas de " nombre ", uniquement" nombre naturel "," nombre rationnel "," nombre réel ", etc.
Joker_vD

53

Même avant C ++ 20, la norme avait:

__FILE__

Le nom présumé du fichier source actuel (une chaîne de caractères littérale).

La définition est la même pour source_location::file_name.

En tant que tel, il n'y a pas eu de changement en ce qui concerne la prise en charge des implémentations sans système de fichiers dans C ++ 20.

La norme ne définit pas exactement ce que signifie «fichier source», donc la question de savoir s'il se réfère à un système de fichiers peut dépendre de l'interprétation. Vraisemblablement, il pourrait être conforme pour une implémentation de produire "la note manuscrite que vous m'avez remise juste à ce moment-là" si cela identifie effectivement le "fichier source" dans cette implémentation du langage.


En conclusion: Oui, les sources sont appelées «fichiers» par la norme, mais ce qu'est un «fichier» et si un système de fichiers est impliqué n'est pas spécifié.


2
@Yksisarvinen Je ne connais pas exactement l'intention de la qualification de "présomption" de la règle, mais je présume :) que c'est une clarification que le nom de fichier doit être absolu ou canonique, mais plutôt un nom relatif du point de vue de le compilateur est suffisant. Je peux me tromper.
eerorika

4
Je peux juste voir scanner-c++revenir "Armoire de gauche, troisième tiroir, quatrième dossier à onglets rouges, page 17" .
dmckee --- ex-moderator chaton

2
FWIW, dans le sens POSIX, un tube (ou tout autre élément de type fichier) est un "fichier" - en tant que tel, stdin / stdout sont des "fichiers", mais pas des fichiers disque, etc. dans ce sens.

3
@Yksisarvinen: Le Comité tient souvent compte des situations où des implémentations obscures pourraient avoir de bonnes raisons de faire quelque chose de contraire aux comportements courants. Ce faisant, il s'appuie sur les rédacteurs de compilateurs pour juger si leurs clients trouveraient le comportement courant plus ou moins utile qu'une alternative. Le fait que de telles choses soient laissées au jugement des exécutants peut être considéré comme une "ambiguïté", mais c'est délibéré, car les bons rédacteurs de compilateurs en sauront plus sur les besoins de leurs clients que le Comité ne le pourrait jamais.
supercat

1
@dmckee ... dans des toilettes désaffectées avec une pancarte sur la porte disant "Attention au léopard".
Andrew Henle
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.