C++相談室 part166

2025/11/13(木) 23:07:46.30

もしくはunique_ptrをunique_refでラップしてしまうのが楽か

2025/11/13(木) 23:10:58.33

>>736
たまにある
外部リソース（たとえばファイルハンドル）を一時的にクラスに保持して使いやすくするとか
なんにせよ寿命を明示的に管理しておかないと後でやばいことになる

2025/11/13(木) 23:14:39.55

>>738
ファイルハンドルだとして、それを管理するクラスがファイルハンドルの値自体を持たずにヨソに置いて参照するのはなぜ？
やっぱり意味がわからない

2025/11/13(木) 23:20:38.76

>>732
UB になる。
ポインタと違って参照自体は無効を表現できないのが C++ の基本ルールであり、 reference_wrapper でもそれは同じ。
それでもあえてやるなら適当にダミーのオブジェクトを作っておいてそれを参照していたら無効ということにするというようなことをできなくはないが……それはそれでちょっと不恰好だよね。

2025/11/13(木) 23:22:41.52

>>739
クラス内部でちゃんと管理するのがいいんだけど時には関数内クラスを定義してちょっとしたことを行うこともある（かも）
その時には所有権を一時的にでも委譲しなきゃならなくなる

2025/11/13(木) 23:30:06.73

>>741
ハンドルは外部で持ったままで、その関数内クラスにはハンドルの参照を渡す（関数内クラスの参照メンバを外部のハンドルで初期化する）って言ってる？それ委譲とは言わないよ
委譲したからにはそのリソースはその関数内クラスの消滅とともに消えないといけないけど、そうなったら外部で持ってたハンドルの実体はどうなるの？
どんなケースを想定してるのか全然わかんない

2025/11/14(金) 12:19:28.56

>>740
までもnull objectはよく使ってるからそれにするわ
個人的にはすっきり
でもc++の参照っていらん子やん？って気がしてならない

class A {
　static constexpr std::string s_empty_str{""};
　std::reference_wrapper<const std::string> m_s;
public:
　A(const std::string& s) : m_s(s) {}
　A(A&& rhs) : m_s(std::exchange(rhs.m_s, s_empty_str)) { }
};

2025/11/14(金) 17:06:33.25

>>743
型無しのnullpointerが型システム(機能保証)を破壊しているから、型を強要する参照は必要。

2025/11/14(金) 17:48:56.23

>>744
古くね？
そういうのはoptional使えってのが最近のやり方でしょ？

2025/11/14(金) 19:18:46.50

>>743
参照は色々な場面で有用ではあるが、 D&E によれば最初の動機は演算子オーバーロードだと書かれている。
オブジェクトをコピーする必要がない (値をコピーせずに場所を渡せば充分) ような状況で参照がなくポインタを使うならいちいち &a+&b みたいにして書く必要が生じる。
いかにも煩わしいだろう。

2025/11/14(金) 19:55:59.90

C++より古いの新しいの含めて多くの言語が採用してるように参照は引数でのみ使用可能で良かったと思うよ

2025/11/14(金) 20:35:30.63

>>747
他の言語はともかく、C++の参照は引数に限定されてないですよ。

int a = 10;
int* pa = &a;

2025/11/15(土) 10:22:10.37

747は、（実際の仕様はそうなっていないけど）引数でのみ使用可能なら良かったのに……という意味だと思うぞ。

2025/11/15(土) 19:11:12.30

ああ
＞使用可能で良かったと思うよ

ではなく、

＞使用可能だったら良かったのにと思うよ
って事ですか

2025/11/15(土) 19:25:57.81

カスみたいな読解力

2025/11/15(土) 19:35:13.09

そんなコミュ力高かったら、石が友達なんて言わない

2025/11/15(土) 19:39:44.33

分かりやすいように749みたいに書いたけど、747で普通に意味が通じるので、「ではなく」というとちょっと違う気がするかな。言葉って難しい。

2025/11/16(日) 01:00:07.67

こういう人が仕様書読んで実装すると思うとこわい

2025/11/16(日) 13:18:16.47

横からだけど
>>747 で充分判る
>>748 は本当に日本人か？

2025/11/16(日) 13:32:50.84

C++ばっかりやっとるからだよ
日本語を使え

2025/11/16(日) 16:38:31.73

>>755
>748だけど日本人だよ。
>747日本語の文法としておかしいと思うんだが分かるんか…。
こっちが年食ったんかなぁ…。

2025/11/16(日) 16:49:19.65

あんたは機能的非識字なんでしょ
歳とか関係ないって

2025/11/16(日) 18:20:15.84

747は、日本語の文法としておかしなところは別にないけれども、748のような読み方も許すという点で多義的な文にはなっているかな。
「C++より～ように」という前半の文脈があるので748のような受け取り方はしない方が普通だと思うが、文法的には748のような読み方も一応可能だろう。
「使用可能（ということ）で良かった」としたら、完全に一義的になっているとまでは言えないまでも、多少ニュアンスは明確になっているかな。そうでもないか。

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
関係ない

2025/12/13(土) 08:54:58.15

LF　<--> CR LF 変換はI/Oの段階で行われるものだという印象
証拠に、"\r\n" をテキストモードでファイルに書くと "\r\r\n" になり、
それをテキストモードで読むと "\r\n" に戻るのは万国共通のふるまいのはず（適当
（バイナリモードだともちろん文字列リテラルとファイルのデータ両方 "\r\n"。
すなわちC/C++言語における文字列リテラルの改行は古来より "\n" の1文字……

なので
>従来はそうだったはずだけど C++23 からは Unicode (UTF-8) のコードポイントの並びで規定されていて、 CRLF が単一の改行に置き換えられる規則が明記されてる。
こそ
>（ソースコード上の生文字リテラル内での行の折り返しを）「改行が入力された場合、改行の制御文字 '\n' に変換される」
ことの根拠になっているのでは……

で、
>Unicode 系以外の文字コードから処理系定義の規則で Unicode に適当にマッピングするようなのも認めているので
というのは "\r\n" <--> "\n" の変換（文字数が違う）を正当化しないと思う

2025/12/13(土) 09:19:18.23

>>763
のは次のような特殊なケースでのみ問題になるだけなのではないかという希ガス
#define TEXT_DEFINITION R"(begin\
a,\
b,\
c\
end)"
std::string text = TEXT_DEFINITION; // textの内容が "(begin\na\nb\nc\nend)" になることを気体

初期段階、と書かれるとようわからんが、行を結合するのはプリプロセッサが行うだけのはず……
C/C++は文脈自由言語でありかつ改行文字はトークンでないから、パーサー部分が行を結合する必然性が無い

2025/12/13(土) 10:11:52.86

プラットフォームごとの改行コードに合わせた変換がI/Oの段階で行われるのはそうだろうけど（たとえばPythonは変換仕様の細かい指定がprint関数でできるし、他の言語でも同様の機能があることが多いのではないかと思う。なので、\r\nと\r\r\nの変換が万国共通ということは別にないはず）、規格で規定されているのはソースコードをコンパイルする前処理としての改行コードの正規化（？）の話であって、別の話なのではないかと思うが。

2025/12/13(土) 10:26:05.41

>>772
>\r\nと\r\r\nの変換が万国共通ということは別にないはず
>>770 の前段のは、
C/C++のバイナリモードとテキストモードのI/Oの挙動がC/C++言語の文字列リテラル内の改行が "\n" 一文字であることを含意しているという主旨、
なので、あくまでC/C++のI/Oの挙動において\r\nと\r\r\nの変換が万国共通ならおk、

>ソースコードをコンパイルする前処理としての改行コードの正規化（？）の話
Windowsのメモ帳で
R"(begin
a)"
と書いたらソースファイル上は beginとaの間に CR LF が入るが文字列リテラルの期待値は "begin\na" ですよ（CR LF → LF 1文字に変換）、という話のはず……

2025/12/13(土) 10:53:09.54

①エスケープシーケンス \n と ②そのデコード結果であるLF、③実際の改行コード（プラットフォームにより、LF、CRLF、CRのいずれか）の区別を意識的にしないと議論が混乱すると思う。
cpprefjpの>>761 の説明に違和感があるのは、raw文字列リテラル内ではエスケープシーケンスのデコード処理はされないのに、エスケープシーケンス \n で説明している点にもあると思う。773も同様に①と②を同義語として使っているように見えるが、そこは本来は区別すべきではないか。

2025/12/13(土) 10:59:50.95

>>773の最後の例でいえば、raw文字列リテラルの仕様として、改行コードがLF（エスケープシーケンス \n ではない）に変換されるという記述は特にないと思う。

2025/12/13(土) 11:05:17.48

実際には、最初にソースコード上の改行コードが一律にLFに変換され、トークン分割の段階でraw文字列リテラル中の改行コードと判明した場合には（>>763）、それに応じた処理をするんだろうが、LFからさらに変換したりはしないというのはありそうなことではある。
だけど、それは改行コードの正規化（？）に付随してそういう処理になっていることが多いというだけのことであって、raw文字列リテラルの仕様の一部としてそうすべきと規定されているわけではないよねってことだと思うんだが。

2025/12/13(土) 11:07:53.08

NGワード規制回避のため分割レスになって申し訳ない。何がNGワードだったんどろう……、

2025/12/13(土) 18:42:47.60

>>775
↓これがどのプラットフォームのエディタで書いてビルドしてもequality 1 2がtrueになるのなら
ソースコードの改行（CR LF or LF）が「"\n" に変換されている」としか言いようがないような……
std::string text1 = R"(begin
a,
b,
c
end)"; // "\n" を含まない文字列定義
std::string text2 = "begin\na,\nb,\nc\nend"; // "\n" を含む文字列定義
std::cout << std::boolalpha << "equality 1 2: " << (text1 == text2) << std::endl;

んまー説明のための新しい改行表現を定義したいなら止めはしませぬが……

2025/12/13(土) 18:53:55.47

それはそうとしてRAW文字列とプリプロセッサとの関係で試したら（漏れにとって）奇怪なことがわかりた……
↓次のコードがビルドが通ってequality 2 5 がtrueになる……
// プリプロセッサを通す場合(3)
// マクロ定義が複数行に渡る場合、本来は \\ で行継続せねばならないが、RAW stringの行継続は特別視
#define TEXT_DEFINITION R"(begin
a,
b,
c
end)"
std::string text5 = TEXT_DEFINITION;
std::cout << text5 << std::endl;
std::cout << std::boolalpha << "equality 2 5: " << (text2 == text5) << std::endl;

これはさすがにプリプロセスの段階でプリプロセッサが R"(...)" を認識しないとできない芸当……
（プリプロセッサの普通の挙動ならTEXT_DEFINITION の定義内容は R"(begin（ここで日記は終わってゐる
　にならねばおかしいはず
ソ～ス: https://ideone.com/AJcmZT

2025/12/13(土) 21:05:36.09

実行ファイルの内部でどういうコードが埋め込まれるとか興味ないのかな
>>777は自分の書き込みと他を比較したりしないのかな

2025/12/14(日) 14:42:29.18

VSでC++をやっている。ファイルのバイナリのランダムアクセスをしているんだけど、ファイルの長さを短くしたくて、
ftruncateとか試すんだけど、なさそう。VSでファイルの長さ変更ってどうしたらいい？

2025/12/14(日) 14:48:40.58

>>781
Windows には SetEndOfFile という API がある。
現在位置をファイル終端ということにするという機能なので事前に SetFilePointer で必要な位置に移動してから SetEndOfFile を使えば良い。

2025/12/14(日) 15:51:40.12

>>782
とりあえずビルドは成功した。ありがと