C++相談室 part166

2025/11/16(日) 19:06:28.66

>>757
文字なんでニュアンスが伝わりづらいだけだよ

「この前の件だけど、両方出来るようになったよ」
「他と同じように片方のみで良かったと思うよ」

まあ誤解を与えない書き方とすると

「他と同じように片方のみで良かったのにと思うよ」
って感じで「のに」をいれた方が残念がっている様子が伝わってくるよね

2025/11/17(月) 09:06:44.31

C++はよく分からないので、cpprefjpにはいつもお世話になっているんだけど、生文字列リテラルのところにある「改行が入力された場合、改行の制御文字 '\n' に変換される」というのは説明として正確なのかな。
raw文字列リテラルのところの規格にはそれっぽいことは書いていないように思うし、改行文字は通常の文字としてそのままraw文字列リテラルに含められるだけであって、別に「変換」とかはされていないんじゃないかと思うんだけど。

2025/11/17(月) 10:18:46.23

>>761
'\n' に変換するという説明は誤りだと私も思う。
規格内の例中では \n と同等というような説明はあるのでこれを変換と誤解したのかも？
https://timsong-cpp.github.io/cppwp/n4950/lex.string#5

2025/11/17(月) 10:27:40.74

余談だけど生文字列リテラルの扱いにはちょっと変な特別扱いがある。
C++ では処理の初期段階で行を連結 (改行を削除) してしまうことになっていて、その時点では各改行が生文字列リテラルの中なのかどうか認識してない。
https://timsong-cpp.github.io/cppwp/n4950/lex#phases-1.2
後でトークンを分割するときになって生文字列リテラルを認識したらその範囲では連結を「取り消す」という処理が入る。
https://timsong-cpp.github.io/cppwp/n4950/lex#pptoken-3.1
結果としては改行はそのまま含まれるだけなんだけど、理屈としては色々な操作 (変換？) はされてる。

ただ、これは C++ の言語の解釈の話であって処理系の実装方法ではない。
つまり結果が同じであれば実装方法は問わないので連結してから取り消すのではなく連結の例外にしてもかまわないし、
生文字列リテラルを普通の文字列リテラルに変換するような手法もあるのかもしれない。

2025/11/17(月) 20:16:57.16

>>761
gccにCRLF改行のソースコードを食わせてもLF(\n)だけになったので変換はされてるんじゃないか
他のコンパイラの動作はしらね

2025/11/18(火) 02:43:23.41

>>763
削除されるのは「\（改行）」（Pythonとかでは明示的な行継続と言われているやつ）みたいなやつだけで、（\ に後続しない）単なる改行はwhitespace文字として扱われるだけかと思っていたんだけど。

>>764
改行をLFだけにする（正規化？）のは、raw文字列リテラルに限らない共通の処理なのでは。

2025/11/18(火) 07:15:20.89

規格が決めてるのはソース中の論理的な「改行」の振る舞いであって、そのバイト表現は知ったこっちゃないって奴じゃないの
知らんけど

2025/11/18(火) 10:05:52.54

>>766
従来はそうだったはずだけど C++23 からは Unicode (UTF-8) のコードポイントの並びで規定されていて、 CRLF が単一の改行に置き換えられる規則が明記されてる。
ただ、 Unicode 系以外の文字コードから処理系定義の規則で Unicode に適当にマッピングするようなのも認めているので実態はあまり変わらない。

2025/11/18(火) 23:53:18.65

>>764-765
termcapだかterminfoだかでゴニョゴニョ

2025/11/19(水) 15:04:12.19

>>768
関係ない