[過去ﾛｸﾞ] C++相談室 part156 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
54(2): 2021/05/23(日)08:15 ID:apxwsDfF(4/10) AAS
>>53
投げたブツの型の情報がどうやってcatchする場所に伝わっているのかｷﾎﾞﾝ
55: 2021/05/23(日)08:18 ID:W+jRvSTD(1) AAS
以心伝心
56(1): 2021/05/23(日)08:30 ID:GrP2Tvrl(1) AAS
Emacs で LSP 使わず開発してる人いる？
おもしろ設定とか参考になるサイトあったら教えてほしい
flycheck しか入れてない
57(1): 2021/05/23(日)09:14 ID:p04S1woO(2/2) AAS
>>54
関数呼び出しと一緒やぞ
catch節に書いた仮引数でオーバーロードしてると思えばいい
58(1): 2021/05/23(日)09:31 ID:apxwsDfF(5/10) AAS
>>57
ありえん
1つのthrowに対し、呼び出し元のcatchで呼び出すべき（オーバーロードされた）関数シンボルを一意に列挙できるなら
アンワインド時にオーバーロードのしくみで例外ハンドラの解決を行えるかもしれないが、これは論理的に成り立たない
なぜなら、例えばintを例外をスローする関数foo()がbar()とbaz()から呼ばれているとして、
bar()にcatch (int)が書かれているのにbaz()に描かれていないとした場合、
bar()経由の呼び出しにおいては（オーバーロードされた）関数シンボルのリストに func(int)が含まれるのに対し、
baz()経由の呼び出しにおいては（オーバーロードされた）関数シンボルのリストに func(int)が含まれない、
となって一意にならず、throwした瞬間にどっちなのか解決不能
やっぱcatch側が（何が来るかわからない状態で）待ち受けているとしか考えられない
59(1): 2021/05/23(日)09:40 ID:apxwsDfF(6/10) AAS
ちょっち補足すると、
bar()でtry { foo(); } catch (int ex) { .... } したときに handler(int)を例外ハンドラのリストに動的に登録し、
baz()ではtry { foo(); } catch (int ex) { .... } が無いからhandler(int)を例外ハンドラのリストに動的に登録しないようにすれば、
foo()でthrowしたときに最新の例外ハンドラのリストを参照することによって解決はｷﾞﾘ可能だが、
スタックとは別に例外ハンドラのリストに動的に管理するみたいなことをしているのかとｶﾅｰﾘ疑問に、
（例外がfall throughする関数の中にはゼロコストの奴も含まれるので、スタック上で細工して例外ハンドラのリストを更新管理することは不可能
60: 2021/05/23(日)09:42 ID:vhcqGTpc(1/3) AAS
>>54
exception_ptr
61(1): 2021/05/23(日)09:52 ID:apxwsDfF(7/10) AAS
exception_ptrの主な用途は、バックグランドスレッドからメインスレッドに、例外オブジェクトを持ち運ぶ、というものである。標準ライブラリにおいては、promiseとfutureの実装で使用される。
と書いてあってスレッド間をまたぐ用（promiseしたことを実行中に起きた例外を、promise完了を待っているやつに伝える）とき限定に見える
単純にcalleeからcaller側に飛ばす通常の例外ではどうなのや？？
intやdoubleやconst char*を型情報とともに収容可能なexception_ptrみたいな構造体が絡んでいるのだろうとは思いまするが
62: 2021/05/23(日)09:54 ID:apxwsDfF(8/10) AAS
ｲﾏｲﾁ確証が無い
63(1): 2021/05/23(日)10:08 ID:vhcqGTpc(2/3) AAS
>>61
スレッドは関係ないぞ
同一スレッドでも監視ブロックを抜けrた後でrethrow_exceptionできるし
64(1): 2021/05/23(日)10:30 ID:apxwsDfF(9/10) AAS
>>63
言わんとすることはわかりまするが
（そもそもpromise/futureのしくみも論理的には単なる継続なので単一スレッドでの実装もあり得るという意味でスレッドは関係無い
しかしrethrow_exception(ex)はrethrow_exception(ex)であってthrow exとは別の文やん？？
本当に単純にcalleeからcaller側に飛ばす通常の例外も同じしくみなのかどうか、、、
65: 2021/05/23(日)10:45 ID:apxwsDfF(10/10) AAS
ｽﾏﾝ>>58、>>59は撤回
やっぱ関数のオーバーロードで呼び出すべきハンドラを解決している可能性がありえまつね
というのはスタックにはreturn addressが積まれているので、throw intするfoo()は、
throwする瞬間に自分がbar()経由で呼ばれたのかbaz()経由なのか判定可能
あとはreturn addressに対して呼び出すべきハンドラ（のシンボルのリスト）を与えるテーブルがあれば、
関数のオーバーロードで呼び出すべきハンドラを解決できる
極力実行コストを低くする手となるとこれかなあ……
長々とｽﾏﾝｶｯﾀ、継続調査しまつ
66(1): 2021/05/23(日)12:13 ID:MJ9lD3tL(1) AAS
>>56
>Emacs で LSP 使わず開発
その発想がナンセンス
67: 2021/05/23(日)13:43 ID:p+CWzw6b(1) AAS
>>66
lsp-mode インストールしてファイル開いてみたら「これはなんのプロジェクトにも属してないファイルだ」とか言って何もしてくれなかったもん
テキストエディタだぞ
単一ファイルのソースも普通に編集できるべきだ
68: 2021/05/23(日)13:53 ID:P4UGjjTl(1) AAS
インストールさせるという選択肢である以上は
emacs側はそれをやるかどうかの選択をユーザに委ねていることになる
なのでNoという選択もありうる、とemacs側は考えている
選択肢が無く強制なら選択をさせずインストール現象もまた起こらない
インストールさせるということはYesかNoかをユーザが選ぶことができる仕組みになっているからだ
YesでもNoでもなく選択出来ないならインストールさせない仕組みになっているハズだ
ここでインストールできるということはユーザのYes/Noの意思が尊重されることに他ならない
選ぶ・選ばない・強制、などにおいて、選ぶことが出来る事象については何を選択してもいいし、emacs側もそれを容認している
69: 2021/05/23(日)14:03 ID:JOTdPSSV(1) AAS
>>45
有難う。
70: 2021/05/23(日)14:27 ID:vhcqGTpc(3/3) AAS
>>64
よくわからんが、こういうこと？
void caller()
{
exception_ptr ex;
ex = callee();
try
{
rethrow_exception(ex);
}
省16
71(1): 2021/05/26(水)14:25 ID:h0MuFhR9(1) AAS
クラスAがクラスBのインスタンスをメンバに持つとき (移譲っていうんだっけ？)、Bのコンストラクタってどーやって呼ぶんよ
72: はちみつ餃子 ◆8X2XSCHEME 2021/05/26(水)15:13 ID:BWKw9sIj(1/2) AAS
>>71
メンバ初期化子リスト
外部ﾘﾝｸ:ja.cppreference.com
73: はちみつ餃子 ◆8X2XSCHEME 2021/05/26(水)16:01 ID:BWKw9sIj(2/2) AAS
C++20 からは std::string は constexpr 対応になっとるな。
実装が追いついとるかどうか知らんけど。
74: 2021/05/26(水)17:48 ID:ArjioGpg(1) AAS
vectorもconstexpr
75: 2021/05/27(木)04:38 ID:wOxUHlR5(1) AAS
constexpr引数ってコンセプトとか使っても無理なん
76(1): 2021/05/27(木)10:11 ID:KxmxhHMB(1/2) AAS
なぁ…何気に…普通に…何の気なしに…以下の様なコードを書く…
textView1->get_source_buffer()->place_cursor(
textView1->get_source_buffer()->get_iter_at_line(minusList.front() - 1));
なんだけどさ…このplace_cursorの引数はiteratorなんだが…この一時的に作った無名の変数の寿命って…
どうなってるの？…ちなみに…place_cursorは&で受ける…やばいのかな？
77: 2021/05/27(木)10:35 ID:KxmxhHMB(2/2) AAS
place_cursorを実行している段階では…生きている…そうだ…次のステップに移行すると…消える…らしい
ほんまかいなと思いますが…一応…信じておきます…
78: 2021/05/27(木)11:20 ID:tgaRcrWk(1) AAS
またお前か
79(1): はちみつ餃子 ◆8X2XSCHEME 2021/05/27(木)13:24 ID:tXzwBfxM(1/4) AAS
>>76
一時的なオブジェクトの寿命が完全式の終わりであることは保証されている。
外部ﾘﾝｸ:timsong-cpp.github.io
参照が一時オブジェクトに束縛されているときは更に寿命が延長されることもある。
80: 2021/05/27(木)14:31 ID:U0nLnJgd(1) AAS
勝手に消えるのは確かだが
いつ消えるかは確定出来ないんじゃないの？
次の行の実行中かも知れないし
もう少し生きてるかも知れない
関数抜けたら消えるだろうけど
81: 2021/05/27(木)14:35 ID:P6misAvy(1) AAS
その、意味があるとかないとかを、どうやって判断するかと聞いてるんじゃないかね
82: 2021/05/27(木)14:57 ID:THQ6jHMK(1) AAS
記述時に事細かに寿命を制御・確定できるような時制プログラミングを作ればいい
C++の場合だと新しい原理を作ればいい
83(1): 2021/05/27(木)15:03 ID:kQVwJQto(1/5) AAS
> 参照が一時オブジェクトに束縛されている
一時オブジェクトが参照に束縛されている、だろ
ここではconstでない左辺値参照は含まない
84(1): はちみつ餃子 ◆8X2XSCHEME 2021/05/27(木)15:10 ID:tXzwBfxM(2/4) AAS
>>83
> 一時オブジェクトが参照に束縛されている、だろ
いいえ。 束縛されるのは参照で束縛するのはオブジェクトです。
85(2): 2021/05/27(木)15:24 ID:kQVwJQto(2/5) AAS
>>84
規格票での言葉遣いはこうなっているぞ
CA &&r = A{}; // OK, reference binds to temporary array object
86: はちみつ餃子 ◆8X2XSCHEME 2021/05/27(木)15:27 ID:tXzwBfxM(3/4) AAS
>>85
実際はそこらへんいいかげんなんですよ。
87: 2021/05/27(木)15:30 ID:kQVwJQto(3/5) AAS
いや、おかしいだろ
rand(); //ここで消えてしまう一時オブジェクトを
auto&& a = rand(); //引き止める（束縛する主体が参照で
客体が一時オブジェクトだぞ
88: 2021/05/27(木)15:31 ID:kQVwJQto(4/5) AAS
typo
(束縛する)
89(1): はちみつ餃子 ◆8X2XSCHEME 2021/05/27(木)15:46 ID:tXzwBfxM(4/4) AAS
>>85
このへんのセクション内部ではどちらの表現もある。
外部ﾘﾝｸ[ref]:timsong-cpp.github.io
"自由変数と束縛変数"
外部ﾘﾝｸ:ja.wikipedia.org
このへんの数学的用語では束縛されているのは変数で、 ML 系とか Scheme とかでも一貫してこの用法に従ってるんだけど、
めんどいから私は「××との間に束縛を持つ」みたいな言い回しでどちらが主語なのか曖昧にしたりしてる。
今回の場合は >>79 で示した通りオブジェクトの寿命に関する項目での表現では束縛されているのは参照だから
それにならっただけでどっちがどっちでもまあ重要じゃないよ。
90: 2021/05/27(木)16:09 ID:kQVwJQto(5/5) AAS
>>89
１つめのリンクでは
結合する主体は参照を宣言するコンテキストだね
結合される客体がオブジェクトである点は変わってない
数学や他言語がどうたらには付き合ってやんね
ちゃんとC++の話のなかで例えるなら
実体定義と外部宣言はどちらが使われる側と使う側なのか
のような話だろ
91(1): 2021/05/28(金)04:05 ID:cE/PGHSY(1) AAS
そことは直接関係ないけど、cppreferenceの英語版って、英語として文法的におかしい
ことが有る気がする。主語が無くていきなり三人称単数現在のsが付いた動詞で
始まっている文章も、見出しの直後ならダメではないが、見出しの直後以外の
if節の後にあったりして、しかもそれがif節の中に繋がっていなくて、本来なら
主語を省略できない場合とか。
Microsoftの英語版はすらすら読めるけどcppreferenceの英語版は読めない。
92(1): 2021/05/28(金)04:22 ID:bFqxphgp(1/2) AAS
int 配列の参照って
int (&a)[N]
であって
(int&) a[N]
じゃないよね？
後者は「参照の配列」を意味するようで変なのは分かるんだが、前者は前者でどこに&ついてんねんって感じなんだが
93: 2021/05/28(金)04:30 ID:O9o6B/0s(1) AAS
>>91
てにをはがおかしいのは日本国憲法に比べればかなりマシ。がまんしろ
94(1): 2021/05/28(金)04:57 ID:0J3ydS6A(1/2) AAS
>>92
>int (&a)[N]
それは、数学記号の様に読み取ることが出来る。
()は優先順位を変えているだけ。
優先順位に従って書いてみると、
a --> & --> [N] --> int
となる。これにより、
「a は、参照で、それは、[N] を指し、その要素は int である」
と読めて、もう少し自然な言語に直すと
「a は、参照で、それは、N要素の配列を指し、その配列の要素は int である」
省4
95: 2021/05/28(金)05:01 ID:0J3ydS6A(2/2) AAS
>>94
[補足]
a --> & --> [N] --> int
を英語で読んでみると、
「a is & to [N] to int」
となる。& を「reference」、[N]を「N要素のarray」に置き換えてみると、
「a is reference to "N要素の配列" to int」
となる。日本語に直せば、
「aは、int 型の N要素の配列への参照」
となる。
96(1): 2021/05/28(金)05:51 ID:bFqxphgp(2/2) AAS
それはたとえば
int (a&)[N]
などを禁止する理由になってるだろうか
97: 2021/05/28(金)06:18 ID:fuFcwWPl(1/4) AAS
参照修飾子はすぐ右にある対象を修飾する
98: 2021/05/28(金)06:24 ID:Q2cy611+(1) AAS
>>39の
> 2つの文字列リテラルの共通部分列の長さをコンパイル時定数として扱う
をやろうとして苦戦しています
再帰 constexpr 関数で計算しようと思ったんですが、引数として受け取った文字列リテラルの要素って定数と見なせないですよね？
そもそも無理か、勉強次第でできるかだけでも教えていただけたらありがたいです
99(1): 2021/05/28(金)12:14 ID:sAi5WsuI(1/9) AAS
>>96
(a&)
の部分は、()は優先順位を変えているだけなので、コンパイラは
a&
という部分式を認識しようとする。しかし、a& という部分式は
C++では文法的に存在して無いのでエラーとなる。
単にそれだけの事。
100(1): 2021/05/28(金)12:22 ID:sAi5WsuI(2/9) AAS
>>99
[補足]
C++コンパイラが
int x[N]; // (1)
というテキストをパースする際、コンパイラ内部では、
x --> [N] --> int
という順序の演算が並んでいると理解されている。そして、
int (&a)[N] // (2)
というテキストをパースする時、優先順位括弧があるために、
(1)において、x を &a に置き換えたようにコンパイラは理解するなので、
省11
101(1): 2021/05/28(金)12:48 ID:sAi5WsuI(3/9) AAS
>>100
[さらに補足]
C++では、「宣言文」と地の文における「式」とは別扱いになっている。
なので、式における &a と宣言文における &a では、& の意味が異なる。
今回の場合は「宣言文」。
宣言文における &a は、a が参照型であることを意味する。
式における &a は、a のアドレスを取得する演算子である。
> x --> [N] --> int
> という順序の演算が並んでいると理解されている。
において「演算」と書いたのは、適切な言葉が見つからなかったため。
省9
102(2): 2021/05/28(金)12:59 ID:yA47hu4B(1/3) AAS
>>101
> 「演算」と書いたのは、適切な言葉が見つからなかったため
抽象構文木？
長いしもうちょっと整理してから書いてや
独自記法もやめてな
103: 2021/05/28(金)13:02 ID:sAi5WsuI(4/9) AAS
>>102
抽象構文木とは限らない。
104: 2021/05/28(金)13:10 ID:sAi5WsuI(5/9) AAS
>>102
整理すると理解できないと思うぞ。
俺は個の痛手は良く馬鹿にされるが、IQは170くらいある。
105(1): 2021/05/28(金)13:20 ID:fuFcwWPl(2/4) AAS
IQが20違うともう対話が成立しないって聞いたことがある
106(1): 2021/05/28(金)13:31 ID:ymLe7hdU(1/3) AAS
「a&は禁止されてるから禁止」て言ってるだけじゃねえか
バカなのかコイツ
107: 2021/05/28(金)14:17 ID:sAi5WsuI(6/9) AAS
>>106
そうじゃない。a& という部分式が、記号として未定義と言っている。
禁止じゃなく、未定義。数学でも、
-a
は符号反転とか、負符合という意味で定義されているが、
a-
は定義されていないのと同様。
禁止ではなく、定義されない。だからエラーになる。
108(1): 2021/05/28(金)14:21 ID:yA47hu4B(2/3) AAS
「パーサーが受理しない」なら言っていい
109: 2021/05/28(金)14:40 ID:fuFcwWPl(3/4) AAS
未定義って言ってんじゃん
パーサーなんて規格票で使わない用語を持ち出す必要ねえよ
110(1): 2021/05/28(金)14:40 ID:sAi5WsuI(7/9) AAS
>>108
それでは、なぜ受理(認識)しないのかという理由が曖昧。
理由は、そのトークン列が「未定義だから」。
111(1): 2021/05/28(金)14:46 ID:yA47hu4B(3/3) AAS
>>110
還元できる構文規則がないからだよ
redexは非終端記号も含むから「トークン列」はそもそも誤り
112: 2021/05/28(金)14:50 ID:sAi5WsuI(8/9) AAS
>>111
専門用語をなるべく使わずに平易に説明してるつもりだった。
113: 2021/05/28(金)14:55 ID:sAi5WsuI(9/9) AAS
俺は、非終端記号、構文規則、redex、受理みたいな専門用語はなるべく使わずに、
生まれながらの頭の良ささえあれば理解できる様に書いたつもりだ。
だから、他に本などを読まなくても俺の説明をちゃんと読めば、数学的に高IQの人なら
理解できるはず。
114: 2021/05/28(金)15:32 ID:noi5k0SL(1) AAS
>>105
115: 2021/05/28(金)15:39 ID:fuFcwWPl(4/4) AAS
> 独自記法もやめてな
脳天にどでかいブーメランぶっ刺さってんぞｗ
116(2): 2021/05/28(金)19:49 ID:ymLe7hdU(2/3) AAS
定義されてないから未定義なのか
定義できないから未定義なのか
未定義にしている理由なら、禁止してるから定義にないのは当然じゃん
定義にあるのは許可されたやつだけだから禁止されたものは書かれてない
定義に無いから禁止されてる
未定義＝禁止であって、未定義なのは禁止されてるから
なんで無いのかを聞いてるんだからどっかで禁止されたんだろ
で、答えが「未定義だから定義には無い」「禁止されたから禁止されている」何も言ってないじゃないか
なんでそのルールが無いのか、ルールそのものには書いてないじゃん
117: 2021/05/28(金)20:19 ID:cxRyZpXl(1) AAS
>>116
？？？
c++標準で未定義と定義されているのが「未定義」だろ。
>定義されてないから未定義なのか
>定義できないから未定義なのか
どちらもc++の「未定義」じゃない。
c++標準くらい読めよ。
118: 2021/05/28(金)20:26 ID:9RgT2QcU(1) AAS
関数呼び出し時の引数の評価順は未だに未規定(unspecified)ですね
でも未定義(undefined)ではない
最適化をしやすくするためとか
119: 2021/05/28(金)20:42 ID:ymLe7hdU(3/3) AAS
コイツが言ってんのは、構文解析の規則にないから未定義であり禁止、だろ
禁止されてんのは構文規則には入ってないです、未定義だからです、だから禁止です、ってな
そりゃ構文規則には受理する規則だけが書いてあるだけなんだから受理しない規則は書いてない
定義しない理由があったんならそりゃ禁止する理由だ
でなければ定義に書かれている
構文ルールに入って無いのはそのルールが未定義なのか禁止されてるだけなのかそもそも定義できないのか、それは分からないだろ
だから禁止されているかどうかの答えにはなってない
禁止されたから構文ルールには入ってねえんだよ
120(1): 2021/05/28(金)23:14 ID:/t1wIdDl(1) AAS
ある入力を受理するかどうか未定義ってどうやって書くんじゃ……
わざとあいまいなNFAにでもするのか…………
つかBNFはPDAなのでは……………………
PDNFAみたいなもんがこの世にはあるんか…………………………………………
121: 2021/05/29(土)01:22 ID:3Clqo4vt(1) AAS
初期化されてない自動変数やポインタを使うのはスリルあるね
122(1): 2021/05/29(土)01:28 ID:ppnc++Os(1) AAS
>>120
構文規則には、その言語(C/C++など)で定義されたパターンを、非終端記号と終端記号を
組み合わせてBNFなどを使って書く(その構文規則をコンパイラ理論では「文法」と呼んでいる。)。
トークン列が、その構文規則のパターンに当てはまる場合、「認識された」という。
このとき、認識されないトークン列はエラーであり「受理されない」。
ようは、文法規則に当てはまってないトークン列が、「受理されない/未定義」。
123(1): 2021/05/29(土)01:39 ID:QJfgb1eG(1/5) AAS
>>116
C++の宣言文において、&x を x が参照型であることを意味する文法を最初に
定義するのは、人間。そういう言語にしたいからそうしただけ。
そしてその文法は、(必須ではないが)、BNFなどを使った構文規則として仕様公開される。
C++の構文規則には、x&というパターンは書いてない。
なので、積極的に「禁止」しなくても、トークン列にx&というものが現れても、
どの構文規則にも「マッチング」しないのでエラーが表示される。
それだけのこと。
124: はちみつ餃子 ◆8X2XSCHEME 2021/05/29(土)02:08 ID:F7QShN9h(1/2) AAS
仕様が提示する構文規則 (BNF) に合致しないというレベルの違反は診断対象規則 (diagnosable rules) に反するので処理系がユーザに通知する義務はある。
125: 2021/05/29(土)02:51 ID:gVnTXjgE(1/3) AAS
>>122
受理されなかった入力は非マッチなのであってエラーの一択なのでは……
126(2): 2021/05/29(土)02:53 ID:gVnTXjgE(2/3) AAS
>>123
x&とかxが型なら普通にパターンとして現れるのでは…………
127: 2021/05/29(土)03:11 ID:gVnTXjgE(3/3) AAS
「C++の構文規則にマッチする入力テキストの集合」が一意確定になることを疑う理由は無いから
入力テキストにわざわざ未定義などというクラスを設けるする必要は無いのでは……………………
128: 2021/05/29(土)03:13 ID:QJfgb1eG(2/5) AAS
>>126
構文規則の中に x&y は存在しているが、x&単独では存在していない。
だから、z = x&y; や z=(x&y) は受理されるが、z = x&; や z=(x&)
はエラーになる。
129(1): 2021/05/29(土)03:14 ID:QJfgb1eG(3/5) AAS
>>126
おっと、読み間違えた。
xが型の場合は受理されるよ。
xが名前トークンの場合は受理されない。
130(1): 2021/05/29(土)03:21 ID:QJfgb1eG(4/5) AAS
>>129
[補足]
・xが名前トークンでも意味論的にxが型名とみなせる場合にはxは型だと扱われる。
・xが変数名の場合には変数だとみなされる。
・xが変数名の場合には、x&yは文法の中の有る規則にマッチングするので
受理されるが、xが変数名の場合にはx&という文法規則は存在してないので
どんな文法規則にもマッチングできないのでエラーになる。
131: 2021/05/29(土)03:24 ID:QJfgb1eG(5/5) AAS
>>130
[さらに補足]
・xが(ユーザー定義の)型名の場合でも、それが現れる文脈次第で
x&が受理され無い事がある。
文脈によって受理されるパターンが違うので。
132(1): 2021/05/29(土)16:51 ID:thkl3N6c(1/2) AAS
たぶんくそしょうもない質問いいですか
コンストラクタの初期化子リストで
まさに今初期化したばっかりの他のメンバを使うのはアリですか
class Foo{
Foo(Bar bar,Baz baz);
Bar bar_;
Baz baz_;
...
};
Foo::Foo(Bar bar,Baz baz)
省5
133: 2021/05/29(土)16:59 ID:RxiQSMqK(1) AAS
>>132
クラスのメンバ変数は定義に書かれた順に初期化されるから、その例についてはokなんじゃないかな
134(1): はちみつ餃子 ◆8X2XSCHEME 2021/05/29(土)17:29 ID:F7QShN9h(2/2) AAS
メンバ初期化子として書いた順ではなくクラス定義内のデータメンバ宣言順に従うというのが重要ポイントで、
勘違いを防ぐために宣言順とメンバ初期化子の順序は一致させるのが一般的な習慣になってる。
(一致させなくてもそれ自体は規格違反ではない。)
C++20 から入る指示付初期化 (Designated initialization) で順序を一致させるのが必須に
なっているのはこのへんの反省があったんだと思う。
135: 2021/05/29(土)19:10 ID:thkl3N6c(2/2) AAS
各位 ありがとう
>>134
後半はへーって感じなので調べてみる
136: 2021/05/31(月)20:14 ID:OyXVhXUR(1/2) AAS
構造化束縛とか範囲for文が必ず新規にオブジェクトを宣言しないといけない仕様になってるのが何気に解せないのだが
既存のオブジェクトを使い回せた方が都合良いだろうに、なぜこういうことになったの？
137: 2021/05/31(月)20:47 ID:6/QCGWOG(1) AAS
構造化束縛の方はtieで行けるだろ
int a, b;
std::tie(a, b) = std::make_pair(1, 2);
138(1): 2021/05/31(月)20:48 ID:7Qq6EdKQ(1) AAS
参照じゃダメ？
139: 2021/05/31(月)21:28 ID:s2XLu44M(1) AAS
c++11やり始めた頃、for(auto& e:〜やfor(const auto& e:〜と出来るのを知らず、酷いコードを大量に垂れ流してしまったよ
140(1): 2021/05/31(月)22:31 ID:OyXVhXUR(2/2) AAS
>>138
参照にしてもfor文のスコープ外で宣言できた方が都合が良いことがままある
141: 2021/06/01(火)01:12 ID:reo3/Kbw(1) AAS
ループの最後の値を使いたいという事？
142: 2021/06/01(火)09:11 ID:qu3686ge(1) AAS
>>140
言っても「稀に」程度だろうし、やりたければスコープ外で宣言した変数に代入すれば済む。
何を問題としているのかわからない。
143: 2021/06/01(火)12:18 ID:GfvVYbqX(1) AAS
お漏らし推奨
144: 2021/06/01(火)12:20 ID:cpTyMADV(1) AAS
自作関数の引数を initializer_list にするのってなんか使い道あるんですか？
参照の組を渡せる？
145(1): 2021/06/01(火)18:21 ID:S9WvGpu9(1) AAS
MyVector v{1,2,3,4,5};
とかできる
146: 2021/06/01(火)20:14 ID:Y6fKUmaQ(1) AAS
ま、まいべくたーｗ
147: 2021/06/02(水)06:27 ID:P6q02jmG(1/4) AAS
>>145
コンストラクタの引数にするくらいしかメリットないの？
前スレ掘ってたら、同じ型の参照の組なら initializer_list で関数に投げれるってのを見つけたんだがそれはどうやんの
initializer_listを引数にとる関数 hoge を
hoge({fuga, var, aaa})
って呼び出したら実体を渡してることになるよね？
148(1): 2021/06/02(水)06:48 ID:2dvb28jp(1/6) AAS
MyVector(initializer_list<reference_wrapper<int>>) { }
149(1): 2021/06/02(水)07:01 ID:P6q02jmG(2/4) AAS
>>148
それって vector< reference_wrapper<T> > とは違うんけ？
150: 2021/06/02(水)07:55 ID:2dvb28jp(2/6) AAS
template <class T>をつけるならね
151(1): 2021/06/02(水)07:57 ID:2dvb28jp(3/6) AAS
reference_wrapperはC++11からでC++03にはないから> >にする意味ないぞ
152: 2021/06/02(水)08:15 ID:c6cNO3VA(1) AAS
初期化のときに登場する｛｝が初期化子リストだと言うことがつい最近判明した
概念を区分して分離したのが一番大きいので、用途についてはあまり考えられていない
153(1): 2021/06/02(水)08:44 ID:P6q02jmG(3/4) AAS
>>151
いや自分の可読性のためにそうしてるだけ
他の人にとってはそっちの方が見づらかったらすみません
それはそうと、関数に参照の組を渡すなら、initializer_list 云々というよりは reference_wrapper の組として渡すってことですね
もう一点、関数に initializer_list を渡すときって
・関数の引数の型が initializer_list である
よりも
・関数の引数のコンテナを initializer_list で初期化している
の方がしっくりくるんですが、前者で設計するメリットってありますか
上下前次1-新書関写板覧索設栞歴
あと 849 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.264s*