Si j'ai un multi-chaîne de ligne de C++11 constante de chaîne tels que
R"""line 1
line 2
line3"""
Est-il défini ce personnage(s) le terminateur de ligne/séparateur consiste?
Si j'ai un multi-chaîne de ligne de C++11 constante de chaîne tels que
R"""line 1
line 2
line3"""
Est-il défini ce personnage(s) le terminateur de ligne/séparateur consiste?
L'intention est qu'un saut de ligne dans le raw d'un littéral de chaîne cartes dans un seul
'\n'
de caractère. Cette intention n'est pas exprimé aussi clairement qu'il
devrait être, ce qui a conduit à une certaine confusion.
Les Citations sont à l'2011 standard ISO C++.
Tout d'abord, voici la preuve qu'il correspond à un seul '\n'
de caractère.
Une note dans la section 2.14.5 [lex.string] le paragraphe 4 dit:
[ Note: la source du fichier de nouvelle ligne dans le raw d'un littéral de chaîne de résultats dans un de nouvelle ligne dans le résultat de l'exécution de la chaîne littérale. En supposant qu'aucun les espaces blancs au début de la ligne dans l'exemple suivant, la affirmer la volonté de réussir:
const char *p = R"(a\
b
c)";
assert(std::strcmp(p, "a\\\nb\nc") == 0);
- la note de fin ]
Cela indique clairement qu'un retour à la ligne est mappé à un seul '\n'
caractère. Il correspond également au comportement observé de g++ 6.2.0 et
clang++ 3.8.1 (tests réalisés sur un système Linux en utilisant des fichiers source
De style Unix et Windows-style de fin de ligne).
Compte tenu de l'clairement l'intention énoncée dans la note et le comportement de deux populaire compilateurs, je dirais qu'il est sûr de compter sur cela, même si c' ce serait intéressant de voir comment d'autres compilateurs effectivement gérer cela.
Cependant, une lecture littérale de la normative libellé de l' la norme pourrait facilement mener à une conclusion différente, ou au moins à une certaine incertitude.
La Section 2.5 [lex.pptoken] l'alinéa 3 dit (italiques ajoutés):
Entre la première et la dernière, les guillemets doubles de l' chaîne brute, toutes les transformations effectuées dans les phases 1 et 2 (trigraphs universel de caractères, noms, et d'épissage en ligne) sont rétablies; cette réversion s'applique avant tout d-char, r-char, ou la délimitation entre parenthèses est identifié.
Les phases de traduction sont spécifiés dans 2.2 [lex.les phases]. Dans la phase 1:
Source physique de fichier caractères sont mis en correspondance, dans un la mise en œuvre définies de manière à la source de base de jeu de caractères (introduction de la nouvelle ligne de caractères de fin de ligne des indicateurs) si nécessaire.
Si nous supposons que la cartographie de la physique source fichier des caractères à l'
jeu de caractères de base et l'introduction de caractères de nouvelle ligne sont
"tranformations", on peut raisonnablement conclure que, par exemple,
un saut de ligne dans le milieu de raw d'un littéral de chaîne dans un Windows format
fichier source doit être équivalent à un \r\n
de la séquence. (J'imagine
qui peuvent être utiles pour Windows-code spécifique.)
(Cette interprétation n'conduire à des problèmes avec les systèmes où la la fin de la ligne de l'indicateur n'est pas une séquence de caractères, par exemple où chaque ligne est d'une largeur fixe d'enregistrement. De tels systèmes sont rares ces jours-ci.)
Comme "des Acclamations et des hth. - Alf"'s réponse souligne, il y a un Rapport De Défaut pour cette question. Il a été présenté en 2013 et n'a pas encore été résolu.
Personnellement, je pense que la racine de la confusion, le mot "tout" (emphase ajoutée comme avant):
Entre la première et la dernière, les guillemets doubles de la première chaîne, toutes les transformations effectuées dans les phases 1 et 2 (trigraphs, universel de caractères, noms, et d'épissage en ligne) sont rétablies; ce réversion s'applique avant tout d-char, r-char, ou la délimitation la parenthèse est identifié.
Sûrement la cartographie physique du fichier source caractères la source de base de jeu de caractères peut raisonnablement être considéré comme une transformation. La mise entre parenthèses de la clause "(trigraphs, universel de caractères des noms, et de la ligne d'épissage)" semble être destiné pour spécifier laquelle des transformations doivent être annulées, mais que soit les tentatives de changer le sens du mot "transformations" (dont la norme n'est pas officiellement définir) ou contredit l'utiliser le mot "tout".
Je suggère de remplacer le mot "tout" à "certains" serait express l'intention apparente beaucoup plus clairement:
Entre la première et la dernière, les guillemets doubles de la première chaîne de caractères, certaines transformations effectuées dans les phases 1 et 2 (trigraphs, universel de caractères, noms, et d'épissage en ligne) sont rétablies; ce réversion s'applique avant tout d-char, r-char, ou la délimitation la parenthèse est identifié.
Cette formulation de la rendre beaucoup plus claire que "trigraphs, universel de caractères, noms, et d'épissage en ligne" sont les seuls les transformations qui doivent être annulées. (Pas tout à fait dans la traduction des phases 1 et 2 est revenue, juste celles qui sont spécifiques répertorié transformations.)
La norme semble indiquer que:
R"""line 1
line 2
line3"""
est équivalent à:
"line 1\nline 2\nline3"
De 2.14.5 littéraux de Chaîne du C++11 standard:
4 [ Note: la source du fichier de nouvelle ligne dans le raw d'un littéral de chaîne de résultats dans une nouvelle ligne dans le résultat de l'exécution de la chaîne littérale. En supposant que pas d'espace au début de la ligne dans l'exemple suivant, l'assertion va réussir:
const char *p = R"(a\ b c)"; assert(std::strcmp(p, "a\\\nb\nc") == 0);
-la note de fin ]
5 [ Exemple: La chaîne brute
R"a( )\ a" )a"
est équivalent à
"\n)\\\na\"\n"
.
Remarque: la question a considérablement changé depuis les réponses ont été publiées. Seulement la moitié de la il reste, à savoir le C++ pur aspect. L'attention du réseau dans cette réponse, traite de la question de départ est “l'envoi d'un multi-ligne de chaîne à un serveur avec bien défini de fin de ligne des exigences”. Je ne tentez pas de la question de l'évolution en général.
En interne dans le programme, la norme C++ pour le saut de ligne est - \n
. C'est également utilisé pour le saut de ligne dans le raw d'un littéral. Il n'existe pas de convention spéciale pour les matières premières, les littéraux.
Habituellement \n
cartes ASCII de saut de ligne, qui est la valeur 10.
Je ne suis pas sûr de ce qu'il cartes en EBCDIC, mais vous pouvez vérifier que si nécessaire.
Sur le fil, cependant, c'est mon impression que la plupart des protocoles ASCII retour chariot et saut de ligne, c'est à dire 13 suivie par 10. Cela est parfois appelé CRLF, après l'ASCII abréviations CR pour le retour chariot et LF pour le saut de ligne. Lorsque le C++ fuites sont mappés en ASCII, c'est tout simplement \r\n
en C++.
Vous devez respecter les exigences du protocole que vous utilisez.
Pour un fichier ordinaire/flux i/o du C++ standard library prend soin de cartographie de l'interne \n
quelle que soit la convention de l'environnement hôte utilise. Cela s'appelle le mode texte, par opposition à la mode binaire où aucun mappage n'est effectué.
Pour le réseau i/o, qui n'est pas couvert par la bibliothèque standard, le code de l'application doit le faire elle-même, soit directement ou par l'intermédiaire de certaines fonctions de la bibliothèque.
Il y a un actif de question à ce sujet, du langage de base rapport de défaut #1655 “les fins de Ligne en raw littéraux de chaîne”, présentée par Mike Miller 2013-04-26, où il demande,
” est-il prévu que, par exemple, un CRLF à la source d'un raw littéral de chaîne est d'être représenté comme un caractère de saut de ligne ou que les caractères d'origine?
Depuis la fin de ligne les valeurs diffèrent selon le codage du fichier d'origine, et en considérant que, dans certains systèmes de fichiers, il n'est pas un encodage des fins de ligne, mais plutôt des lignes, des dossiers, il est clair que l'intention n'est pas de représenter le contenu du fichier en tant que-est – puisque c'est impossible de le faire dans tous les cas. Mais aussi loin que je puisse voir ce DR est pas encore résolu.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.