C++相談室 part166 (783レス)
1-

1: sage (ワッチョイ 8732-NXaD) 04/26(土)10:34 ID:pbPDl6lv0(1/2) AAS
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

※前スレ
C++相談室 part165
省1
703: (ワッチョイ 2d7c-2Udd) 09/29(月)19:56 ID:BDszbKFL0(1) AAS
こういうこと?
要はconst性を「セーブさせたくない」という符丁に使いたいのかな

class Hoge; // DoSave()持ち

void foo(Hoge& h1, const Hoge& ch2)
{
  h1.DoSave(); //ゆるす
  ch2.DoSave(); //ゆるさない
省2
704: (ワッチョイ adf0-pGVw) 09/29(月)20:49 ID:Qgirjd9Z0(1) AAS
const_cast<Hoge*>(&ch2)->DoSave();
705
(3): (ワッチョイ 4376-Duv+) 09/29(月)22:22 ID:ALxfRd8b0(2/2) AAS
>> 703-704
すみませんサンプルを載せるべきでした

ソース:
double Point::X(){return x;}
void Point::X(double value){ x=value;}
ヘッダ:
static Point {
省18
706
(1): (ワッチョイ 1b39-ZlhK) 09/29(月)23:01 ID:jk3QzjEU0(1) AAS
NOLINT
707
(1): 09/29(月)23:04 ID:rfIMSjI90(1) AAS
>>705
その場合const付けたほうが良い理由は「変更されないことを明示」することより
constのインスタンスに対してその関数を呼べなくなることでは?
↓はエラーか警告(どっちかは忘れた)になると思う(constオブジェクトの非constメンバ関数は呼び出せない)

void SaveData(const Sample sample)
{
sample.DoSave();
省3
708
(1): (ワッチョイ adf0-pGVw) 09/30(火)01:33 ID:Xmjd+d/v0(1) AAS
処理だからconst付けないんじゃなくて、そのメンバ関数がPointクラスの中身を書き変えないことを保証するためにメンバ関数の後ろにconstは付ける
つまり、Save処理はPointクラスを特段変更するメソッドではないだろ?
だったらconstは付けるべき
709
(1): (ワッチョイ 2d7c-2Udd) 09/30(火)07:07 ID:NaKN2pJV0(1) AAS
>>705
つまり、constを本来の意味(中身を変更するかどうか)ではなく「getterであるかどうか」を示すラベルとして使いたいってことでしょ?
で、何を持って「getterであるかどうか」はあなたの頭の中にしかない定義であって、そのlintはもちろんコンパイラもエディタも世のライブラリも知ったことではない
それらをオレオレconstラベルに適合させるためにどうしたらいいか?というのがあなたの問うていることだ
やっぱりどうしてそんなことがしたいのか全く理解できない
710
(1): はちみつ餃子◆8X2XSCHEME (ワッチョイ 2d32-jLB2) 09/30(火)08:58 ID:0fqHawiZ0(1/3) AAS
>>705
オブジェクトがなんらかのストレージを抽象化したものであると考えたらそのオブジェクトが const であるときはセーブ機能を使えないようにしたいというのはわからんでもない。
実際の管理は他の場所でやっていて窓口に過ぎないならメンバ関数に const を付加可能 (だがそうしたくない) なこともあるだろう。

それが良い設計かどうかは脇に置いてそうすることに決めたときに clang-tidy の警告はどうすればいいのかということなら、
例外的な状況なので例外的なものとして無視してもらうしか仕方ないんじゃないか。
NOLINT コメントを書いておくと clang-tidy はその箇所については警告を抑制してくれるよ。
711: (スッップ Sd43-WwN1) 09/30(火)10:38 ID:Dzyyn8xKd(1) AAS
>>706-710
御返事がおそくなりすみません
ご意見ありがとうございます
自分の理解不足と設計思想が間違ってるまたはずれてるんだと理解しました

・「readability-make-member-function-const」の指示にしたがってconstを付けるのが良い
・更に言うと-fixオプションで自動付与するレベルの内容
・だけどNOLINTで無視もできるよ(無視してるとは言ってない)
省3
712
(1): (ワッチョイ 2596-TDpG) 09/30(火)21:38 ID:bXNPhBlr0(1/2) AAS
VC++20のテンプレート制約で不可思議なことが起きるのだけど、以下の二つは同じ意味だよね?
1だと目的通りTParentに該当static関数<T>があれば適用、なければスルーという挙動になるのだけど、
2だと無くても適用されちゃって他を探しに行かずにオーバーロード未解決に陥るんだけどどういうことだろう?

1
template<typename T, typename TParent> concept HasSizeGetter = requires { (size_t)TParent::template get_size<T>(); };
template<HasSizeGetter<TParent> T> static consteval size_t get_require_space() { return TParent::get_size<T>(); }

2
省1
713: (ワッチョイ 2596-TDpG) 09/30(火)21:40 ID:bXNPhBlr0(2/2) AAS
ちょっと書き間違えてたけど1はget_require_spaceじゃなくてちゃんと2と同じくget_sizeね
714
(1): はちみつ餃子◆8X2XSCHEME (ワッチョイ 2d32-jLB2) 09/30(火)23:39 ID:0fqHawiZ0(2/3) AAS
>>712
オーバーロード未解決という形で現れるのはよくわからないけど
この場合はその関数テンプレートを使わなくても (呼び出さなくても) エラーになるのが正しい挙動だと思う。

get_size は依存名ではないのでテンプレートの定義時 (テンプレート実引数を当てはめる前) に名前のルックアップが試みられて失敗する。
requires 節はテンプレート引数の妥当性を検証する仕組みなのでテンプレート引数をあてはめなくても式が不成立になるようなのはエラー。

というのが私の理解なんだけどあんまり自信はない……。
715
(1): はちみつ餃子◆8X2XSCHEME (ワッチョイ 2d32-jLB2) 09/30(火)23:47 ID:0fqHawiZ0(3/3) AAS
>>714
これは TParent::get_size が存在しない場合の話で、
TParent::get_size が存在するけど TParent::get_size<T> の展開に失敗する場合はちゃんと次の候補が選ばれるはず。
(手元に MSVC がないんだけどオンラインコンパイラで一応の動作確認はした。)
716
(1): (ワッチョイ 2596-TDpG) 10/01(水)06:54 ID:O1Ml42XO0(1) AAS
>>715
そう、2の場合でもTParent::get_sizeはあるけど<T>とはマッチしない場合にはちゃんと1と同じ挙動になるんだよね
TParentにstaticなget_sizeが全くない場合だと1と2で挙動が変わってしまう
でも2って1をインラインに直接書いたものであって同じ意味だよね?
だからrequiresがどういう意味を持つかとか以前に挙動変わってくる時点で不可思議なんだよね
717: はちみつ餃子◆8X2XSCHEME (ワッチョイ 2d32-I4u/) 10/01(水)07:43 ID:XKqCU3PC0(1) AAS
>>716
1 の場合は get_size は依存名だ。
そこで解釈が違うよ。
718
(1): (ワッチョイ faa6-/eJP) 10/22(水)12:58 ID:6nuMV8zc0(1) AAS
C++26から入るらしい^^と[::]という二つの演算子はどういう用途に使うものなのでしょうか?
719: はちみつ餃子◆8X2XSCHEME (ワッチョイ 4132-ctWl) 10/22(水)13:31 ID:/iXiQCcE0(1) AAS
>>718
リフレクションで検索したら色々な例がみつかるよ。
構文要素を値として取り扱う、本物のマクロだ。
720: (アウアウウー Sa09-u8G0) 10/22(水)19:35 ID:t2Chdy11a(1) AAS
^^
↑ちょっと顔にみえる
721: (ワッチョイ aa71-zeRK) 10/22(水)21:43 ID:q+0a8lK20(1) AAS
^^;
722: (アウアウウー Sa09-HZvd) 10/22(水)21:55 ID:tW3LNod+a(1) AAS
^^;ゞ
723: (ワッチョイ 417c-ib/k) 10/22(水)22:05 ID:b6F/3uj70(1) AAS
^^::←グローバル名前空間のリフレクション値
724: (ワッチョイ d6d6-9FkA) 10/23(木)05:29 ID:HOQCmR4+0(1) AAS
v^^
725: (ワッチョイ c1ef-6mJJ) 10/23(木)21:41 ID:FPW1mHao0(1) AAS
山崎渉
726: (アウアウウー Sa09-6N1s) 10/24(金)14:17 ID:nAYKU6CIa(1) AAS
GGは
へへ
ミミ
727: (JP 0Hab-oW0m) 10/29(水)17:48 ID:KY7jGttbH(1) AAS
Y(^_^)Y なんすかこれ

口が違う。覚えてる人修正して
728: (アウアウウー Sae3-N4yN) 11/11(火)14:16 ID:crDtfQHZa(1) AAS
バルタン星人のひと元気かな
729
(1): (ブーイモ MM9f-lDbn) 11/13(木)14:20 ID:jo2+4JNJM(1) AAS
多分基本的な質問ですまんけど、参照型のメンバー持ったクラスをmove対応させるのってどうやんのが定石?
ポインタにするしかない?
730
(1): はちみつ餃子◆8X2XSCHEME (ワッチョイ 9f32-jcp5) 11/13(木)14:53 ID:bJCWdXAy0(1/2) AAS
>>729
その参照が差す先のオブジェクトの所有権 (最終的に後始末する責任) を持っている状況ということ?
ポインタを交換する手法がよく使われるのはヌルで無効を表現してるだけなので所有権を持ってるかどうかわかるフラグを立てれるならなんでもいいよ。
型システム的に表現するなら optional と reference_wrapper を組み合わせるのがよいかな。(optional は参照を直接には保持できない。)
731: (ワッチョイ ffd6-UeF3) 11/13(木)22:00 ID:oKSfQs8Q0(1) AAS
いきなりわからんorz
732
(1): (ブーイモ MMd3-lDbn) 11/13(木)22:38 ID:PBCTneT3M(1) AAS
>>730
なるほどサンキュー
でもoptionは省きたいところ
moveしたあとは使わない前提でこれはUBになる?

class A {
 std::reference_wrapper<const std::string> m_s;
public:
省3
733: (ワッチョイ 9f7c-18cq) 11/13(木)22:48 ID:qvmNyT2p0(1/4) AAS
・T*(ナマポ)にする
Pros: 一番素直、ムーブ後状態をぬるぽで自然に表現できる。
Cons: メンバ使ってるとこで*付けたり.を->に書き換えたりが必要。deleteとか加減算とか好き勝手できちゃう。今どきナマポとかダサい。
・std::unique_ptr<T>やstd::shared_ptr<T>にする
Cons: 多分セマンティクス違う(もともとはヨソのオブジェクト覗いてるだけでしょ?)
・std::referrence_wrapper<T>にする
Pros: 参照の置き換えという意味でこれも素直。
省8
734: (ワッチョイ 1f01-/Hnv) 11/13(木)23:01 ID:/tchf03X0(1/4) AAS
unique_ptrと同様のもの(unique_ref)を作ればいいんじゃねえのって話だろ
ただしptrはnullptrで無効を表現してるから
代わりにフラグを用意する
class unique_ref{
T& ref;//参照
bool isValid;//無効判定
//コンストラクタ
省9
735: (ワッチョイ 1fa6-0yYo) 11/13(木)23:06 ID:pKRh1I850(1) AAS
参照なんて引数と演算子オーバーロード以外で使ってもいいこと無くね?
736
(1): (ワッチョイ 9f7c-18cq) 11/13(木)23:07 ID:qvmNyT2p0(2/4) AAS
そもそも所有権自分で保持してるメンバがもともとT&ってことはないだろ
どっか遠くのオブジェクトを見えるようにしてるだけでしょ?
(それはそれで設計的に焦げ臭いけど置いとく)
737: (ワッチョイ 1f01-/Hnv) 11/13(木)23:07 ID:/tchf03X0(2/4) AAS
もしくはunique_ptrをunique_refでラップしてしまうのが楽か
738
(1): (ワッチョイ 1f01-/Hnv) 11/13(木)23:10 ID:/tchf03X0(3/4) AAS
>>736
たまにある
外部リソース(たとえばファイルハンドル)を一時的にクラスに保持して使いやすくするとか
なんにせよ寿命を明示的に管理しておかないと後でやばいことになる
739
(1): (ワッチョイ 9f7c-18cq) 11/13(木)23:14 ID:qvmNyT2p0(3/4) AAS
>>738
ファイルハンドルだとして、それを管理するクラスがファイルハンドルの値自体を持たずにヨソに置いて参照するのはなぜ?
やっぱり意味がわからない
740
(1): はちみつ餃子◆8X2XSCHEME (ワッチョイ 9f32-jcp5) 11/13(木)23:20 ID:bJCWdXAy0(2/2) AAS
>>732
UB になる。
ポインタと違って参照自体は無効を表現できないのが C++ の基本ルールであり、 reference_wrapper でもそれは同じ。
それでもあえてやるなら適当にダミーのオブジェクトを作っておいてそれを参照していたら無効ということにするというようなことをできなくはないが……それはそれでちょっと不恰好だよね。
741
(1): (ワッチョイ 1f01-/Hnv) 11/13(木)23:22 ID:/tchf03X0(4/4) AAS
>>739
クラス内部でちゃんと管理するのがいいんだけど時には関数内クラスを定義してちょっとしたことを行うこともある(かも)
その時には所有権を一時的にでも委譲しなきゃならなくなる
742: (ワッチョイ 9f7c-18cq) 11/13(木)23:30 ID:qvmNyT2p0(4/4) AAS
>>741
ハンドルは外部で持ったままで、その関数内クラスにはハンドルの参照を渡す(関数内クラスの参照メンバを外部のハンドルで初期化する)って言ってる?それ委譲とは言わないよ
委譲したからにはそのリソースはその関数内クラスの消滅とともに消えないといけないけど、そうなったら外部で持ってたハンドルの実体はどうなるの?
どんなケースを想定してるのか全然わかんない
743
(2): (ブーイモ MM0f-lDbn) 11/14(金)12:19 ID:YW3kWFexM(1) AAS
>>740
までもnull objectはよく使ってるからそれにするわ
個人的にはすっきり
でもc++の参照っていらん子やん?って気がしてならない

class A {
 static constexpr std::string s_empty_str{""};
 std::reference_wrapper<const std::string> m_s;
省4
744
(1): (ワッチョイ ff36-TpjX) 11/14(金)17:06 ID:sw2A38eb0(1) AAS
>>743
型無しのnullpointerが型システム(機能保証)を破壊しているから、型を強要する参照は必要。
745: (ブーイモ MM0f-lDbn) 11/14(金)17:48 ID:d/VpWy+aM(1) AAS
>>744
古くね?
そういうのはoptional使えってのが最近のやり方でしょ?
746: はちみつ餃子◆8X2XSCHEME (ワッチョイ 9f32-jcp5) 11/14(金)19:18 ID:YeCIJNF30(1) AAS
>>743
参照は色々な場面で有用ではあるが、 D&E によれば最初の動機は演算子オーバーロードだと書かれている。
オブジェクトをコピーする必要がない (値をコピーせずに場所を渡せば充分) ような状況で参照がなくポインタを使うならいちいち &a+&b みたいにして書く必要が生じる。
いかにも煩わしいだろう。
747
(3): (ワッチョイ 1fa6-0yYo) 11/14(金)19:55 ID:p/1JbX4j0(1) AAS
C++より古いの新しいの含めて多くの言語が採用してるように参照は引数でのみ使用可能で良かったと思うよ
748
(2): (ワッチョイ 9fda-V2U1) 11/14(金)20:35 ID:/xnnTPah0(1) AAS
>>747
他の言語はともかく、C++の参照は引数に限定されてないですよ。

int a = 10;
int* pa = &a;
749: (ワッチョイ 1f42-q6Sd) 11/15(土)10:22 ID:ncudN0/g0(1/2) AAS
747は、(実際の仕様はそうなっていないけど)引数でのみ使用可能なら良かったのに……という意味だと思うぞ。
750: (ワッチョイ 9fda-V2U1) 11/15(土)19:11 ID:lfrbAWbT0(1) AAS
ああ
>使用可能で良かったと思うよ

ではなく、

>使用可能だったら良かったのにと思うよ
って事ですか
751: (ワッチョイ ffa1-lDbn) 11/15(土)19:25 ID:3JdS/6Ib0(1) AAS
カスみたいな読解力
752: (オッペケ Srf3-rRus) 11/15(土)19:35 ID:QqRirP4Fr(1) AAS
そんなコミュ力高かったら、石が友達なんて言わない
753: (ワッチョイ 1f42-q6Sd) 11/15(土)19:39 ID:ncudN0/g0(2/2) AAS
分かりやすいように749みたいに書いたけど、747で普通に意味が通じるので、「ではなく」というとちょっと違う気がするかな。言葉って難しい。
754: (ワッチョイ 4d7c-2tyn) 11/16(日)01:00 ID:oagsDxeg0(1) AAS
こういう人が仕様書読んで実装すると思うとこわい
755
(1): (アウアウウー Sa85-H7iN) 11/16(日)13:18 ID:0LN83zrSa(1) AAS
横からだけど
>>747 で充分判る
>>748 は本当に日本人か?
756: (ワッチョイ 7901-djhR) 11/16(日)13:32 ID:Xh/GBEYv0(1) AAS
C++ばっかりやっとるからだよ
日本語を使え
757
(1): (ワッチョイ 0dda-43h0) 11/16(日)16:38 ID:r6khXsKc0(1) AAS
>>755
>748だけど日本人だよ。
>747日本語の文法としておかしいと思うんだが分かるんか…。
こっちが年食ったんかなぁ…。
758: (ワッチョイ 22f2-43h0) 11/16(日)16:49 ID:D8AV/AUw0(1) AAS
あんたは機能的非識字なんでしょ
歳とか関係ないって
759: (ワッチョイ 91df-iLwu) 11/16(日)18:20 ID:fnmgx6dT0(1) AAS
747は、日本語の文法としておかしなところは別にないけれども、748のような読み方も許すという点で多義的な文にはなっているかな。
「C++より〜ように」という前半の文脈があるので748のような受け取り方はしない方が普通だと思うが、文法的には748のような読み方も一応可能だろう。
「使用可能(ということ)で良かった」としたら、完全に一義的になっているとまでは言えないまでも、多少ニュアンスは明確になっているかな。そうでもないか。
760: (ワッチョイ 11da-ZOUt) 11/16(日)19:06 ID:B8gkzotY0(1) AAS
>>757
文字なんでニュアンスが伝わりづらいだけだよ

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

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

「他と同じように片方のみで良かったのにと思うよ」
って感じで「のに」をいれた方が残念がっている様子が伝わってくるよね
761
(3): (ワッチョイ e9f6-iLwu) 11/17(月)09:06 ID:g7E0m0EQ0(1) AAS
C++はよく分からないので、cpprefjpにはいつもお世話になっているんだけど、生文字列リテラルのところにある「改行が入力された場合、改行の制御文字 '\n' に変換される」というのは説明として正確なのかな。
raw文字列リテラルのところの規格にはそれっぽいことは書いていないように思うし、改行文字は通常の文字としてそのままraw文字列リテラルに含められるだけであって、別に「変換」とかはされていないんじゃないかと思うんだけど。
762: はちみつ餃子◆8X2XSCHEME (ワッチョイ 4d32-o1Ob) 11/17(月)10:18 ID:DdlSQj440(1/2) AAS
>>761
'\n' に変換するという説明は誤りだと私も思う。
規格内の例中では \n と同等というような説明はあるのでこれを変換と誤解したのかも?
外部リンク:timsong-cpp.github.io
763
(3): はちみつ餃子◆8X2XSCHEME (ワッチョイ 4d32-o1Ob) 11/17(月)10:27 ID:DdlSQj440(2/2) AAS
余談だけど生文字列リテラルの扱いにはちょっと変な特別扱いがある。
C++ では処理の初期段階で行を連結 (改行を削除) してしまうことになっていて、その時点では各改行が生文字列リテラルの中なのかどうか認識してない。
外部リンク[2]:timsong-cpp.github.io
後でトークンを分割するときになって生文字列リテラルを認識したらその範囲では連結を「取り消す」という処理が入る。
外部リンク[1]:timsong-cpp.github.io
結果としては改行はそのまま含まれるだけなんだけど、理屈としては色々な操作 (変換?) はされてる。

ただ、これは C++ の言語の解釈の話であって処理系の実装方法ではない。
省2
764
(2): (ワッチョイ e9a6-Bso2) 11/17(月)20:16 ID:3c799E+W0(1) AAS
>>761
gccにCRLF改行のソースコードを食わせてもLF(\n)だけになったので変換はされてるんじゃないか
他のコンパイラの動作はしらね
765
(1): (ワッチョイ 6e10-iLwu) 11/18(火)02:43 ID:oTdu6LNz0(1) AAS
>>763
削除されるのは「\(改行)」(Pythonとかでは明示的な行継続と言われているやつ)みたいなやつだけで、(\ に後続しない)単なる改行はwhitespace文字として扱われるだけかと思っていたんだけど。

>>764
改行をLFだけにする(正規化?)のは、raw文字列リテラルに限らない共通の処理なのでは。
766
(1): (ワッチョイ 4d7c-2tyn) 11/18(火)07:15 ID:cPKOUaFd0(1) AAS
規格が決めてるのはソース中の論理的な「改行」の振る舞いであって、そのバイト表現は知ったこっちゃないって奴じゃないの
知らんけど
767: はちみつ餃子◆8X2XSCHEME (ワッチョイ 4d32-o1Ob) 11/18(火)10:05 ID:BySuHnsX0(1) AAS
>>766
従来はそうだったはずだけど C++23 からは Unicode (UTF-8) のコードポイントの並びで規定されていて、 CRLF が単一の改行に置き換えられる規則が明記されてる。
ただ、 Unicode 系以外の文字コードから処理系定義の規則で Unicode に適当にマッピングするようなのも認めているので実態はあまり変わらない。
768
(1): (アウアウウー Sa85-H7iN) 11/18(火)23:53 ID:+AochNn2a(1) AAS
>>764-765
termcapだかterminfoだかでゴニョゴニョ
769: (ブーイモ MM22-hp//) 11/19(水)15:04 ID:HRoC/CWNM(1) AAS
>>768
関係ない
770
(1): (ワッチョイ ffa1-txSl) 12/13(土)08:54 ID:WPESu7ut0(1/5) AAS
LF <--> CR LF 変換はI/Oの段階で行われるものだという印象
証拠に、"\r\n" をテキストモードでファイルに書くと "\r\r\n" になり、
それをテキストモードで読むと "\r\n" に戻るのは万国共通のふるまいのはず(適当
(バイナリモードだともちろん文字列リテラルとファイルのデータ両方 "\r\n"。
すなわちC/C++言語における文字列リテラルの改行は古来より "\n" の1文字……

なので
>従来はそうだったはずだけど C++23 からは Unicode (UTF-8) のコードポイントの並びで規定されていて、 CRLF が単一の改行に置き換えられる規則が明記されてる。
省6
771: (ワッチョイ ffa1-txSl) 12/13(土)09:19 ID:WPESu7ut0(2/5) AAS
>>763
のは次のような特殊なケースでのみ問題になるだけなのではないかという希ガス
#define TEXT_DEFINITION R"(begin\
a,\
b,\
c\
end)"
省3
772
(1): (ワッチョイ 7746-RIfS) 12/13(土)10:11 ID:c4oXW2530(1) AAS
プラットフォームごとの改行コードに合わせた変換がI/Oの段階で行われるのはそうだろうけど(たとえばPythonは変換仕様の細かい指定がprint関数でできるし、他の言語でも同様の機能があることが多いのではないかと思う。なので、\r\nと\r\r\nの変換が万国共通ということは別にないはず)、規格で規定されているのはソースコードをコンパイルする前処理としての改行コードの正規化(?)の話であって、別の話なのではないかと思うが。
773
(1): (ワッチョイ ffa1-txSl) 12/13(土)10:26 ID:WPESu7ut0(3/5) AAS
>>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のメモ帳で
省3
774: (ワッチョイ 9756-RIfS) 12/13(土)10:53 ID:+GybsC590(1/4) AAS
①エスケープシーケンス \n と ②そのデコード結果であるLF、③実際の改行コード(プラットフォームにより、LF、CRLF、CRのいずれか)の区別を意識的にしないと議論が混乱すると思う。
cpprefjpの>>761 の説明に違和感があるのは、raw文字列リテラル内ではエスケープシーケンスのデコード処理はされないのに、エスケープシーケンス \n で説明している点にもあると思う。773も同様に①と②を同義語として使っているように見えるが、そこは本来は区別すべきではないか。
775
(1): (ワッチョイ 9756-RIfS) 12/13(土)10:59 ID:+GybsC590(2/4) AAS
>>773の最後の例でいえば、raw文字列リテラルの仕様として、改行コードがLF(エスケープシーケンス \n ではない)に変換されるという記述は特にないと思う。
776: (ワッチョイ 9756-RIfS) 12/13(土)11:05 ID:+GybsC590(3/4) AAS
実際には、最初にソースコード上の改行コードが一律にLFに変換され、トークン分割の段階でraw文字列リテラル中の改行コードと判明した場合には(>>763)、それに応じた処理をするんだろうが、LFからさらに変換したりはしないというのはありそうなことではある。
だけど、それは改行コードの正規化(?)に付随してそういう処理になっていることが多いというだけのことであって、raw文字列リテラルの仕様の一部としてそうすべきと規定されているわけではないよねってことだと思うんだが。
777
(1): (ワッチョイ 9756-RIfS) 12/13(土)11:07 ID:+GybsC590(4/4) AAS
NGワード規制回避のため分割レスになって申し訳ない。何がNGワードだったんどろう……、
778: (ワッチョイ ffa1-txSl) 12/13(土)18:42 ID:WPESu7ut0(4/5) AAS
>>775
↓これがどのプラットフォームのエディタで書いてビルドしてもequality 1 2がtrueになるのなら
ソースコードの改行(CR LF or LF)が「"\n" に変換されている」としか言いようがないような……
std::string text1 = R"(begin
a,
b,
c
省4
779: (ワッチョイ ffa1-txSl) 12/13(土)18:53 ID:WPESu7ut0(5/5) AAS
それはそうとしてRAW文字列とプリプロセッサとの関係で試したら(漏れにとって)奇怪なことがわかりた……
↓次のコードがビルドが通ってequality 2 5 がtrueになる……
// プリプロセッサを通す場合(3)
// マクロ定義が複数行に渡る場合、本来は \\ で行継続せねばならないが、RAW stringの行継続は特別視
#define TEXT_DEFINITION R"(begin
a,
b,
省9
780: (ワッチョイ 9f79-+7gk) 12/13(土)21:05 ID:jWXCFmDk0(1) AAS
実行ファイルの内部でどういうコードが埋め込まれるとか興味ないのかな
>>777は自分の書き込みと他を比較したりしないのかな
781
(1): (ワッチョイ 1f51-kDYN) 12/14(日)14:42 ID:71RgSOjf0(1/2) AAS
VSでC++をやっている。ファイルのバイナリのランダムアクセスをしているんだけど、ファイルの長さを短くしたくて、
ftruncateとか試すんだけど、なさそう。VSでファイルの長さ変更ってどうしたらいい?
782
(1): はちみつ餃子◆8X2XSCHEME (ワッチョイ e332-f85/) 12/14(日)14:48 ID:SWyrOIpz0(1) AAS
>>781
Windows には SetEndOfFile という API がある。
現在位置をファイル終端ということにするという機能なので事前に SetFilePointer で必要な位置に移動してから SetEndOfFile を使えば良い。
783: (ワッチョイ 1f51-kDYN) 12/14(日)15:51 ID:71RgSOjf0(2/2) AAS
>>782
とりあえずビルドは成功した。ありがと
1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.771s*