C++相談室 part156

**デフォルトの名無しさん** · 2021/05/19(水) 10:55:13.24

前スレ
C++相談室 part155
https://mevius.5ch.net/test/read.cgi/tech/1616555235/

**デフォルトの名無しさん** · 2021/05/19(水) 11:23:50.45

乙

**デフォルトの名無しさん** · 2021/05/19(水) 11:31:17.57

乙でございます

**デフォルトの名無しさん** · 2021/05/19(水) 11:33:27.40

乙python

**デフォルトの名無しさん** · 2021/05/19(水) 11:36:23.16

前スレの>>989
> 可変個の参照の組 (vectorでいい) を関数 hoge に渡したいときって、hoge が vector< reference_wrapper<T> > を取るようにして
> hoge({ref(A), ref(B), ref(C)})
> みたいに呼ぶか、可変引数テンプレートを使って hoge の中でパースするかっていうのが普通のやり方かな？

なんですが、もしかして reference_wrapper って構築時に左辺値を渡したらそれの参照を保持してくれる？
だとしたら
hoge({A, B, C})
と呼べるしかなりスッキリしますね
hoge 内でいちいち get() しないといけないのはダルいですが……

**デフォルトの名無しさん** · 2021/05/19(水) 12:17:48.45

継承や委譲との付き合い方がよく分からなくなった

あるクラスの機能を全部持っていてほしいが is-a 関係がないとかで継承関係にはないように思える場合ってどうすんの
例えば一辺の長さを表す変数やはみ出し判定メソッドを持つ「グリッド座標クラス」があったとして、今「オセロを解くクラス」を作りたいとき

オセロを解くこと is a グリッド座標では全くないし継承するのは頓珍漢に思える
一方で「オセロを解くクラス」がグリッド座標のインスタンスを委譲として持っていたとして、盤の大きさとかはみ出し判定メソッドにわざわざ「グリッド座標クラス」のインスタンスを通してアクセスするのも果たして正しいだろうか
例えば盤面 a と盤面 b を同時に持ったりもするだろうが、a.size() とか b.size() は同じものを表すのでこのようにアクセスするのは可読性を損なう
だから「オセロを解くクラス」は盤面の大きさとかはみ出し判定メソッドを自分のメンバとして持っていてほしいが、継承するべきようにも思えない

**デフォルトの名無しさん** · 2021/05/19(水) 12:37:51.61

複数の盤面持つんならメンバで持つ一択だと思うけど
「解くクラス」に外部からはみ出し判定アクセスするのもおかしな話だけど
描画の都合とかで外部からアクセスするのが欠かせないなら、インデックス受け取って盤面の参照返すメンバ関数でも用意すればいい

**デフォルトの名無しさん** · 2021/05/19(水) 12:44:45.80

あ、あるいは解くクラスが単に外部の盤面を参照する形でもいいかもね

**デフォルトの名無しさん** · 2021/05/19(水) 12:46:25.42

>>7
> 複数の盤面持つんならメンバで持つ一択だと思うけど
「オセロを解く」といった時点で盤の大きさ等決まるんだから、自分のメンバとして基本的な機能持っててほしいと思うんですが、偏った考え方ですかね

> 「解くクラス」に外部からはみ出し判定アクセスするのもおかしな話だけど
そう思います

**デフォルトの名無しさん** · 2021/05/19(水) 12:47:08.07

>>8
それはインスタンスとして盤面を持つという意味ではなくですか？

**デフォルトの名無しさん** · 2021/05/19(水) 12:51:42.12

フロント部分とオセロを解くソルバー部分で持ち方変えるってのが普通

**デフォルトの名無しさん** · 2021/05/19(水) 12:52:13.78

そう、内包しようとしない方が自然かもしれない
(読んだ範囲で勝手に考えてるだけだけど)
例えばその解くクラスってのがAI的に自動で解くクラスなら、じゃあその対戦相手に同じ(だがインスタンスは別)AIや
プレイヤーが参戦したらどうなるんだ？と考えると
盤面は独立してるほうが自然な気はする(個人の見解です

**デフォルトの名無しさん** · 2021/05/19(水) 12:54:28.27

>>6
オセロを解くアルゴリズムとオセロをプレイするモデル次第なのでなんとも。

まあ、オセロを解くんだったら多数のオセロ盤を持つだろうから、グリッドクラスを派生させてオセロ盤クラスを作るだろうな。
人間がオセロをプレイするのを素直にモデル化してもいいけど、ゲーム機のオセロゲームをプレイするようにモデル化したほうが、オセロを解く側のミスや負担が減る。

**デフォルトの名無しさん** · 2021/05/19(水) 13:23:50.34

>>11
フロント部分って今の場合だと「オセロクラス」ってことですか？
つまり「オセロクラス」と「オセロを解くクラス」が、どちらがどちらを含むではなく、やり取りしあって動くべきだということですか？

**デフォルトの名無しさん** · 2021/05/19(水) 13:26:27.55

>>13
派生って継承ってことですか？
つまり必ずしも is-a を満たさなくても機能を全部引き継ぐなら継承は是 (あるいはそうモデル化するのが良い) ということでしょうか

**デフォルトの名無しさん** · 2021/05/19(水) 14:13:31.63

かんたんだろ
色々判定してくれるオセロ妖精すなわち神を作ればいい

**デフォルトの名無しさん** · 2021/05/19(水) 14:28:08.35

＞is-a を満たさなくても機能を全部引き継ぐなら
どちらも自分で書いてるしグリッドクラスも継承を想定して作れるんだからそれでいいとおも
他人の書いた継承を想定してなさそうなのはやめといた方がいいけどね

てかis-a,has-aはあくまで迷ったときの指針に過ぎんし自分で継承が良さそうと感じたならそれで正解だよ

**デフォルトの名無しさん** · 2021/05/19(水) 14:43:02.57

>>15
この場合、is-aは「グリッドとして同一視できる」を意味するから、オセロ盤をグリッドとして扱うことができるのなら継承もあり。

ただc++の継承は、継承元を総称として扱うという強い意味（継承元と派生クラス全体の強い結びつき）もあるのに注意。
オセロ盤とかその他のゲーム盤とかのクラスを（グリッドとして）使うということでもなければ、継承しないほうが設計の自由度を保てる。

**デフォルトの名無しさん** · 2021/05/19(水) 14:53:47.60

>>18
> ただc++の継承は、継承元を総称として扱うという強い意味（継承元と派生クラス全体の強い結びつき）もあるのに注意。

まさに、そういった意味論的なところで悩んでいます
まあ実際にオセロソルバを作ろうとしているわけではないのですが、同じような局面に何度も出くわして、継承も委譲もどうも適切でないように思えて最終的に「グリッドクラス」の中身をコピペして「オセロソルバクラス」を作るようなこともしばしばしてしまいます

**デフォルトの名無しさん** · 2021/05/19(水) 15:26:58.77

そんなん言い出したらメタプログラミングで取り入れるメンバを選択するための継承なんか全部アウトだぞ
STL内部でやってるようなのも全部

ていうか
>まあ実際にオセロソルバを作ろうとしているわけではないのですが
>まあ実際にオセロソルバを作ろうとしているわけではないのですが
>まあ実際にオセロソルバを作ろうとしているわけではないのですが

**デフォルトの名無しさん** · 2021/05/19(水) 15:43:24.71

継承でできることを別の手段でもできるって言ってるだけでは説得力がない
そんなん言い出したらC++でできることをCで擬似コード書けるしな

特にコード量が増える「別の手段」を推奨するには
格段に強い理由がないと誰も動かせない

**デフォルトの名無しさん** · 2021/05/19(水) 16:02:58.49

cpprefjp によると std::swap の実装って
void swap(T& a, T& b){
　auto tmp = move(a);
　a = move(b);
　b = move(tmp);
}
みたいな感じですよね？
よくされる「move された後のオブジェクトはどうなってる保証もないのでもう触るべきでない」みたいな説明に照らせば、上のコードは move した後のオブジェクトを再利用してるけど大丈夫なのかなって思ってしまいます
大丈夫なんでしょうか？
また、参照をmoveしたら当然参照元のオブジェクトが「どうなってる保証もない」と考えるべきなんでしょうか？

**デフォルトの名無しさん** · 2021/05/19(水) 16:39:28.28

もう一個質問させてください
引数に参照をとる関数に一時オブジェクトを渡したいこともあるんですが、この場合は const参照か右辺値をとる関数としてオーバーロードするしかないですよね？

**デフォルトの名無しさん** · 2021/05/19(水) 16:43:38.10

>MoveConstructibleかつMoveAssignable
こうなってるからヨシ！

**デフォルトの名無しさん** · 2021/05/19(水) 19:24:14.37

>>22
move後の変数は、読み取った場合の値はどうなってるか保証できないが、
値を書き込むことは正常に出来る事が保証されていると聞いた。
破棄することや、初期化することも問題ない。

◆QZaw55cn4c · 2021/05/19(水) 19:54:41.64

>>1
お疲れ様です

**デフォルトの名無しさん** · 2021/05/19(水) 20:51:32.06

>>25
moveコンストラクタは呼ばれないの？
呼ばれるのなら保証するのは自分自身なのでは？

**デフォルトの名無しさん** · 2021/05/20(木) 02:43:42.49

>>27
moveコンストラクタは、変数定義を
TYPE x = y;
の形式で書いた場合に y が右辺値の場合に呼び出されるだけ。
move代入は、
x = y;
の形式で書いた場合に y が右辺値の場合に呼び出されるだけ。
後者の場合、xがmove後であるかどうかは関係ない。

変数xの中身をmove後のxへの書き込み、xの破棄、x.init()などとしての
再初期化が「保証される」というのは、保証されるようにSTLライブラリなどが
作られているという意味で、コンパイラが保証するというわけではない。

**デフォルトの名無しさん** · 2021/05/21(金) 05:29:55.67

T が値なら終了して、vector<T> なら再帰的に自分を呼ぶ関数を作りたいのですが、T が vector (あるいはコンテナ) かどうかで分岐する処理ってどうやって書くのが良いですか

あと近い話題で、+ 演算子をオーバーロードして vector + vector が結合された vector を返すようにするのってナシですかね？(string のように)
要素同士の和をとるのと紛らわしいですか？
cat(vector, vector) とかの方が良いかな

**デフォルトの名無しさん** · 2021/05/21(金) 06:16:08.57

固定長文字列クラスってないんですかね

template<int N> void hoge(string s){
　……
　assert(N == s.size());
　array<int, N> a;
　……
}
なる関数を呼び出すときにテンプレートパラメータを省略したいんです
s が固定長なら s から N を推論してくれますよね

**デフォルトの名無しさん** · 2021/05/21(金) 06:29:04.74

あるいは hoge の引数を costexpr に限る方法なんかがあれば、N は必ずコンパイル時に推論できるようになるの思うので、もしそういうものがあればそれでも大丈夫です

**デフォルトの名無しさん** · 2021/05/21(金) 11:15:57.88

もしかして、C++11に対応したSTLで、BSD/MIT 系ライセンスのものは存在してませんか？
・apache-stlは、2008年くらいで開発が終了しているようです。
・msvc用のstlはapacheライセンスですが、vcruntime.hが存在しないと
　エラーになるようです。

**デフォルトの名無しさん** · 2021/05/21(金) 12:27:55.17

apacheで良ければllvm

**デフォルトの名無しさん** · 2021/05/21(金) 15:55:15.71

>>30-31
これマジキボンヌなので何卒よろしくお願いします

**デフォルトの名無しさん** · 2021/05/21(金) 16:07:34.25

>>30
よくわからんが何で長さの相違を型の相違にしたいんだ？

文字列リテラルならこういう手があるけど
template <int N> void hoge(const char(&s)[N])
{
}

**デフォルトの名無しさん** · 2021/05/21(金) 16:09:26.25

>>34
整数のテンプレート引数を使って、std::stringを継承した文字列クラステンプレートを作ればなんとかなりそう。試してないけど。
std::stringの継承はけっこうクセがあった気がするから、自分で調べてね。

**デフォルトの名無しさん** · 2021/05/21(金) 16:18:16.28

>>30
＞テンプレートパラメータを省略したいんです
の理由がただお遊びレベルのような気がしてスルーしてたけど
固定長の文字列クラスは標準には無い、欲しけりゃ探すか自分で作れ、それか>>35

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/21(金) 16:51:46.16

コンパイル時プログラミングのための機能を満載したライブラリ Sprout がある。
constexpr 対応した文字列クラスもある。
http://boleros.hateblo.jp/entry/20110926/1318115291

ボレロ村上が亡くなってもう一年以上たったんだなぁ……。
Sprout のメンテナンスを引き継ぐ大きな組織とかないのかね？
いっそ Boost に編入するとかでもよいような気がするが。

**デフォルトの名無しさん** · 2021/05/22(土) 04:55:57.93

>>35
> 何で長さの相違を型の相違にしたいんだ？
すみません。どういう意味でしょうか
やりたいことは、関数に渡した定文字列の長さをコンパイル時定数として扱うことです

> 文字列リテラルならこういう手があるけど
ありがとうございます
これが現在やりたいことに最も近いです
2つの文字列リテラルの共通部分列の長さをコンパイル時定数として扱うみたいなこともできそうで、ワクワクしています

>>36-37
ありがとうございます
自作は想像だにしない失敗に繋がりそうなのでやめておきます

固定長文字列とか引数を constexpr に限るとかすごい便利な機能に思えるんですが、今後標準に入ることはあるんでしょうか
それとも僕の不理解で便利に見えるだけなんでしょうか

**デフォルトの名無しさん** · 2021/05/22(土) 10:24:05.95

固定長文字列ってCOBOL以外にあるの？
FORTRANにも無いしCにも無い
現行言語には存在すらしない
昔から特殊技術で需要が少ない

**デフォルトの名無しさん** · 2021/05/22(土) 10:31:31.29

malloc使わなかったらcも固定長でしょ
あとsql

**デフォルトの名無しさん** · 2021/05/22(土) 12:24:13.54

>>39
文字列長ごとにメソッドが別になってプログラムサイズの肥大化に繋がる。

スタックに文字列を全部乗っけて（若干の）スピードアップを狙うこともあるけど、そのときでも「〇〇文字以下」みたいにサイズ制限するくらい。Delphiの文字列がそうだったと思う。

**デフォルトの名無しさん** · 2021/05/22(土) 14:32:38.17

>>40
FORTRANにもあるしPascalにもあるぞ
需要じゃなくてお前の知識が少ないだけだろw

**デフォルトの名無しさん** · 2021/05/22(土) 16:10:33.68

clangで、#includeや#include_nextした全てのインクルードファイルの
パスの一覧をテキストファイルに出力することは出来ますか？

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/22(土) 18:00:59.52

>>44
-MD オプションかな。これは gcc と clang で共通。

**デフォルトの名無しさん** · 2021/05/23(日) 06:05:08.87

すみません
>>5の方法で可変個の参照の組を関数に渡そうとして行き詰まりました

hoge の定義を
template<class T> void hoge(vector< reference_wrapper<T> >);
として、hoge({a, b, c}) と呼んだら T が推論できないとエラーが出ました

**デフォルトの名無しさん** · 2021/05/23(日) 07:05:25.07

a, b, c がfoo_t型だとして
単に型foo_tを明示して hoge<foo_t>({ a, b, c}) と呼んだら良いんｼﾞｬﾈｰﾉ；；；

**デフォルトの名無しさん** · 2021/05/23(日) 07:07:18.56

質問ですがvirtualでないクラスFoo（つまりdynamic_cast適用不能）のオブジェクトをthrowしたら
catchできます？

**デフォルトの名無しさん** · 2021/05/23(日) 07:30:24.57

>>47
ありがとうございます
ただ、なぜに推論できないのでしょうか

template<class T> void hoge(vector< reference_wrapper<T> >);
と
template<class T> void hoge(vector<T>);
が両方あってどっちか判断できないって話なら分かるんですが

**デフォルトの名無しさん** · 2021/05/23(日) 07:33:59.12

reference_wrapper<T> をテンプレート型として認識できないからでしょ

**デフォルトの名無しさん** · 2021/05/23(日) 07:51:37.19

>>50
ありがとうございます
コンテナの入れ子の中に T があっても推論してくれる例を知っていたので、いつでもできるのだと誤解していました

**デフォルトの名無しさん** · 2021/05/23(日) 08:00:14.50

{ 1, 2, 3 }というだけではstd::vector<int>なのかstd::vector<double>なのか（ひょっとしたらstd::vector<long>とかかも？？）
わからないからという理由
自動型変換結果とのマッチングは追求しだすときりが無いので規格でどの範囲でやるか制限がかかっているたはず

**デフォルトの名無しさん** · 2021/05/23(日) 08:08:22.67

>>48
C++はintだって投げられるし捕まえられるぞ

**デフォルトの名無しさん** · 2021/05/23(日) 08:15:35.83

>>53
投げたブツの型の情報がどうやってcatchする場所に伝わっているのかｷﾎﾞﾝ

**デフォルトの名無しさん** · 2021/05/23(日) 08:18:02.28

以心伝心

**デフォルトの名無しさん** · 2021/05/23(日) 08:30:19.77

Emacs で LSP 使わず開発してる人いる？
おもしろ設定とか参考になるサイトあったら教えてほしい

flycheck しか入れてない

**デフォルトの名無しさん** · 2021/05/23(日) 09:14:09.25

>>54
関数呼び出しと一緒やぞ
catch節に書いた仮引数でオーバーロードしてると思えばいい

**デフォルトの名無しさん** · 2021/05/23(日) 09:31:01.96

>>57
ありえん
1つのthrowに対し、呼び出し元のcatchで呼び出すべき（オーバーロードされた）関数シンボルを一意に列挙できるなら
アンワインド時にオーバーロードのしくみで例外ハンドラの解決を行えるかもしれないが、これは論理的に成り立たない
なぜなら、例えばintを例外をスローする関数foo()がbar()とbaz()から呼ばれているとして、
bar()にcatch (int)が書かれているのにbaz()に描かれていないとした場合、
bar()経由の呼び出しにおいては（オーバーロードされた）関数シンボルのリストに func(int)が含まれるのに対し、
baz()経由の呼び出しにおいては（オーバーロードされた）関数シンボルのリストに func(int)が含まれない、
となって一意にならず、throwした瞬間にどっちなのか解決不能
やっぱcatch側が（何が来るかわからない状態で）待ち受けているとしか考えられない

**デフォルトの名無しさん** · 2021/05/23(日) 09:40:45.57

ちょっち補足すると、
bar()でtry { foo(); } catch (int ex) { .... } したときに handler(int)を例外ハンドラのリストに動的に登録し、
baz()ではtry { foo(); } catch (int ex) { .... } が無いからhandler(int)を例外ハンドラのリストに動的に登録しないようにすれば、
foo()でthrowしたときに最新の例外ハンドラのリストを参照することによって解決はｷﾞﾘ可能だが、
スタックとは別に例外ハンドラのリストに動的に管理するみたいなことをしているのかとｶﾅｰﾘ疑問に、
（例外がfall throughする関数の中にはゼロコストの奴も含まれるので、スタック上で細工して例外ハンドラのリストを更新管理することは不可能

**デフォルトの名無しさん** · 2021/05/23(日) 09:42:11.13

>>54
exception_ptr

**デフォルトの名無しさん** · 2021/05/23(日) 09:52:50.26

exception_ptrの主な用途は、バックグランドスレッドからメインスレッドに、例外オブジェクトを持ち運ぶ、というものである。標準ライブラリにおいては、promiseとfutureの実装で使用される。
と書いてあってスレッド間をまたぐ用（promiseしたことを実行中に起きた例外を、promise完了を待っているやつに伝える）とき限定に見える

単純にcalleeからcaller側に飛ばす通常の例外ではどうなのや？？

intやdoubleやconst char*を型情報とともに収容可能なexception_ptrみたいな構造体が絡んでいるのだろうとは思いまするが

**デフォルトの名無しさん** · 2021/05/23(日) 09:54:00.48

ｲﾏｲﾁ確証が無い

**デフォルトの名無しさん** · 2021/05/23(日) 10:08:43.53

>>61
スレッドは関係ないぞ
同一スレッドでも監視ブロックを抜けrた後でrethrow_exceptionできるし

**デフォルトの名無しさん** · 2021/05/23(日) 10:30:51.86

>>63
言わんとすることはわかりまするが
（そもそもpromise/futureのしくみも論理的には単なる継続なので単一スレッドでの実装もあり得るという意味でスレッドは関係無い
しかしrethrow_exception(ex)はrethrow_exception(ex)であってthrow exとは別の文やん？？
本当に単純にcalleeからcaller側に飛ばす通常の例外も同じしくみなのかどうか、、、

**デフォルトの名無しさん** · 2021/05/23(日) 10:45:18.88

ｽﾏﾝ>>58、>>59は撤回
やっぱ関数のオーバーロードで呼び出すべきハンドラを解決している可能性がありえまつね
というのはスタックにはreturn addressが積まれているので、throw intするfoo()は、
throwする瞬間に自分がbar()経由で呼ばれたのかbaz()経由なのか判定可能
あとはreturn addressに対して呼び出すべきハンドラ（のシンボルのリスト）を与えるテーブルがあれば、
関数のオーバーロードで呼び出すべきハンドラを解決できる
極力実行コストを低くする手となるとこれかなあ……
長々とｽﾏﾝｶｯﾀ、継続調査しまつ

**デフォルトの名無しさん** · 2021/05/23(日) 12:13:22.18

>>56
>Emacs で LSP 使わず開発

その発想がナンセンス

**デフォルトの名無しさん** · 2021/05/23(日) 13:43:41.87

>>66
lsp-mode インストールしてファイル開いてみたら「これはなんのプロジェクトにも属してないファイルだ」とか言って何もしてくれなかったもん
テキストエディタだぞ
単一ファイルのソースも普通に編集できるべきだ

**デフォルトの名無しさん** · 2021/05/23(日) 13:53:03.07

インストールさせるという選択肢である以上は
emacs側はそれをやるかどうかの選択をユーザに委ねていることになる
なのでNoという選択もありうる、とemacs側は考えている

選択肢が無く強制なら選択をさせずインストール現象もまた起こらない
インストールさせるということはYesかNoかをユーザが選ぶことができる仕組みになっているからだ
YesでもNoでもなく選択出来ないならインストールさせない仕組みになっているハズだ
ここでインストールできるということはユーザのYes/Noの意思が尊重されることに他ならない

選ぶ・選ばない・強制、などにおいて、選ぶことが出来る事象については何を選択してもいいし、emacs側もそれを容認している

**デフォルトの名無しさん** · 2021/05/23(日) 14:03:17.45

>>45
有難う。

**デフォルトの名無しさん** · 2021/05/23(日) 14:27:22.85

>>64
よくわからんが、こういうこと？
void caller()
{
exception_ptr ex;

ex = callee();

try
{
rethrow_exception(ex);
}
catch(double err)
{
cout << "What the hell does that mean?\n";
}
}

exception_ptr callee()
{
try
{
throw 0.1;
}
catch(...)
{
return current_exception();
}
}

**デフォルトの名無しさん** · 2021/05/26(水) 14:25:57.68

クラスAがクラスBのインスタンスをメンバに持つとき (移譲っていうんだっけ？)、Bのコンストラクタってどーやって呼ぶんよ

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/26(水) 15:13:47.43

>>71
メンバ初期化子リスト
https://ja.cppreference.com/w/cpp/language/initializer_list

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/26(水) 16:01:46.87

C++20 からは std::string は constexpr 対応になっとるな。
実装が追いついとるかどうか知らんけど。

**デフォルトの名無しさん** · 2021/05/26(水) 17:48:11.97

vectorもconstexpr

**デフォルトの名無しさん** · 2021/05/27(木) 04:38:09.87

constexpr引数ってコンセプトとか使っても無理なん

**デフォルトの名無しさん** · 2021/05/27(木) 10:11:42.93

なぁ…何気に…普通に…何の気なしに…以下の様なコードを書く…
textView1->get_source_buffer()->place_cursor(
textView1->get_source_buffer()->get_iter_at_line(minusList.front() - 1));
なんだけどさ…このplace_cursorの引数はiteratorなんだが…この一時的に作った無名の変数の寿命って…
どうなってるの？…ちなみに…place_cursorは&で受ける…やばいのかな？

**デフォルトの名無しさん** · 2021/05/27(木) 10:35:07.24

place_cursorを実行している段階では…生きている…そうだ…次のステップに移行すると…消える…らしい
ほんまかいなと思いますが…一応…信じておきます…

**デフォルトの名無しさん** · 2021/05/27(木) 11:20:16.69

またお前か

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/27(木) 13:24:29.13

>>76
一時的なオブジェクトの寿命が完全式の終わりであることは保証されている。
https://timsong-cpp.github.io/cppwp/n3337/class.temporary#3

参照が一時オブジェクトに束縛されているときは更に寿命が延長されることもある。

**デフォルトの名無しさん** · 2021/05/27(木) 14:31:37.41

勝手に消えるのは確かだが
いつ消えるかは確定出来ないんじゃないの？
次の行の実行中かも知れないし
もう少し生きてるかも知れない
関数抜けたら消えるだろうけど

**デフォルトの名無しさん** · 2021/05/27(木) 14:35:50.64

その、意味があるとかないとかを、どうやって判断するかと聞いてるんじゃないかね

**デフォルトの名無しさん** · 2021/05/27(木) 14:57:58.21

記述時に事細かに寿命を制御・確定できるような時制プログラミングを作ればいい
C++の場合だと新しい原理を作ればいい

**デフォルトの名無しさん** · 2021/05/27(木) 15:03:35.45

> 参照が一時オブジェクトに束縛されている

一時オブジェクトが参照に束縛されている、だろ
ここではconstでない左辺値参照は含まない

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/27(木) 15:10:56.23

>>83
> 一時オブジェクトが参照に束縛されている、だろ

いいえ。束縛されるのは参照で束縛するのはオブジェクトです。

**デフォルトの名無しさん** · 2021/05/27(木) 15:24:54.29

>>84
規格票での言葉遣いはこうなっているぞ
CA &&r = A{}; // OK, reference binds to temporary array object

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/27(木) 15:27:03.62

>>85
実際はそこらへんいいかげんなんですよ。

**デフォルトの名無しさん** · 2021/05/27(木) 15:30:34.22

いや、おかしいだろ
rand(); //ここで消えてしまう一時オブジェクトを
auto&& a = rand(); //引き止める（束縛する主体が参照で
客体が一時オブジェクトだぞ

**デフォルトの名無しさん** · 2021/05/27(木) 15:31:06.17

typo
(束縛する)

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/27(木) 15:46:15.37

>>85
このへんのセクション内部ではどちらの表現もある。
https://timsong-cpp.github.io/cppwp/n3337/over.ics.ref

"自由変数と束縛変数"
https://ja.wikipedia.org/wiki/%E8%87%AA%E7%94%B1%E5%A4%89%E6%95%B0%E3%81%A8%E6%9D%9F%E7%B8%9B%E5%A4%89%E6%95%B0

このへんの数学的用語では束縛されているのは変数で、 ML 系とか Scheme とかでも一貫してこの用法に従ってるんだけど、
めんどいから私は「××との間に束縛を持つ」みたいな言い回しでどちらが主語なのか曖昧にしたりしてる。

今回の場合は >>79 で示した通りオブジェクトの寿命に関する項目での表現では束縛されているのは参照だから
それにならっただけでどっちがどっちでもまあ重要じゃないよ。

**デフォルトの名無しさん** · 2021/05/27(木) 16:09:02.89

>>89
１つめのリンクでは
結合する主体は参照を宣言するコンテキストだね
結合される客体がオブジェクトである点は変わってない

数学や他言語がどうたらには付き合ってやんね

ちゃんとC++の話のなかで例えるなら
実体定義と外部宣言はどちらが使われる側と使う側なのか
のような話だろ

**デフォルトの名無しさん** · 2021/05/28(金) 04:05:49.41

そことは直接関係ないけど、cppreferenceの英語版って、英語として文法的におかしい
ことが有る気がする。主語が無くていきなり三人称単数現在のsが付いた動詞で
始まっている文章も、見出しの直後ならダメではないが、見出しの直後以外の
if節の後にあったりして、しかもそれがif節の中に繋がっていなくて、本来なら
主語を省略できない場合とか。
Microsoftの英語版はすらすら読めるけどcppreferenceの英語版は読めない。

**デフォルトの名無しさん** · 2021/05/28(金) 04:22:43.88

int 配列の参照って
int (&a)[N]
であって
(int&) a[N]
じゃないよね？
後者は「参照の配列」を意味するようで変なのは分かるんだが、前者は前者でどこに&ついてんねんって感じなんだが

**デフォルトの名無しさん** · 2021/05/28(金) 04:30:30.62

>>91
てにをはがおかしいのは日本国憲法に比べればかなりマシ。がまんしろ

**デフォルトの名無しさん** · 2021/05/28(金) 04:57:54.48

>>92
>int (&a)[N]
それは、数学記号の様に読み取ることが出来る。
()は優先順位を変えているだけ。
優先順位に従って書いてみると、
a --> & --> [N] --> int
となる。これにより、
「a は、参照で、それは、[N] を指し、その要素は int である」
と読めて、もう少し自然な言語に直すと
「a は、参照で、それは、N要素の配列を指し、その配列の要素は int である」
となり、さらにわかり易くすると、
「a は、要素が int の配列を指している参照である」
となる。このように数学の式変形の様な工程を経ているだけの、単なる計算の様な
ものに過ぎない。

**デフォルトの名無しさん** · 2021/05/28(金) 05:01:18.55

>>94
[補足]
a --> & --> [N] --> int
を英語で読んでみると、
「a is & to [N] to int」
となる。& を「reference」、[N]を「N要素のarray」に置き換えてみると、
「a is reference to "N要素の配列" to int」
となる。日本語に直せば、
「aは、int 型の N要素の配列への参照」
となる。

**デフォルトの名無しさん** · 2021/05/28(金) 05:51:02.47

それはたとえば
int (a&)[N]
などを禁止する理由になってるだろうか

**デフォルトの名無しさん** · 2021/05/28(金) 06:18:19.72

参照修飾子はすぐ右にある対象を修飾する

**デフォルトの名無しさん** · 2021/05/28(金) 06:24:24.88

>>39の
> 2つの文字列リテラルの共通部分列の長さをコンパイル時定数として扱う
をやろうとして苦戦しています
再帰 constexpr 関数で計算しようと思ったんですが、引数として受け取った文字列リテラルの要素って定数と見なせないですよね？

そもそも無理か、勉強次第でできるかだけでも教えていただけたらありがたいです

**デフォルトの名無しさん** · 2021/05/28(金) 12:14:40.97

>>96
(a&)
の部分は、()は優先順位を変えているだけなので、コンパイラは
a&
という部分式を認識しようとする。しかし、a& という部分式は
C++では文法的に存在して無いのでエラーとなる。
単にそれだけの事。

**デフォルトの名無しさん** · 2021/05/28(金) 12:22:24.96

>>99
[補足]
C++コンパイラが
int x[N];　　　　　　// (1)
というテキストをパースする際、コンパイラ内部では、
x --> [N] --> int
という順序の演算が並んでいると理解されている。そして、
int (&a)[N]　　　　　// (2)
というテキストをパースする時、優先順位括弧があるために、
(1)において、x を &a に置き換えたようにコンパイラは理解するなので、
数学の式変形での「代入」のように考えて、
&a --> [N] --> int　　 // (3)
のようになる。そしてさらに、&a は、a --> & のように式変形されるので、
(3) に安全のために優先順位の()を付けてそれを「代入」すると、
(a --> &) --> [N] --> int　　 // (4)
となる。しかし、この場合、優先順位の括弧ははずせるので、
a --> & --> [N] --> int　　 // (5)
となる。ここで、もとのテキストが、
int (a&)[N]　　　　　// (6)
だったならば、x が a& に相当することになるが、a& という部分式はC++には
存在しないので、そこでエラーになる。

**デフォルトの名無しさん** · 2021/05/28(金) 12:48:09.21

>>100
[さらに補足]
C++では、「宣言文」と地の文における「式」とは別扱いになっている。
なので、式における &a と宣言文における &a では、& の意味が異なる。
今回の場合は「宣言文」。
宣言文における &a は、a が参照型であることを意味する。
式における &a は、a のアドレスを取得する演算子である。

> x --> [N] --> int
> という順序の演算が並んでいると理解されている。

において「演算」と書いたのは、適切な言葉が見つからなかったため。
演算といっても、今回は宣言文ので、式における演算子とは意味が違う。
式に置いて x[y] は、常に *(x+y) と等価な演算子であるが、
宣言置いて x[N] は、演算子ではなく、x が N要素の配列型であることを
意味しているだけである。
また、最後の xxx --> int も演算子ではなく、型指定部と呼ばれ、
xxx の部分が int 型であるということを意味しているだけである。

しかし、コンパイラ内部では、
x --> [N] --> int
のように意味解釈がされていることだけは確かである。

**デフォルトの名無しさん** · 2021/05/28(金) 12:59:39.48

>>101
> 「演算」と書いたのは、適切な言葉が見つからなかったため

抽象構文木？
長いしもうちょっと整理してから書いてや
独自記法もやめてな

**デフォルトの名無しさん** · 2021/05/28(金) 13:02:59.68

>>102
抽象構文木とは限らない。

**デフォルトの名無しさん** · 2021/05/28(金) 13:10:26.55

>>102
整理すると理解できないと思うぞ。
俺は個の痛手は良く馬鹿にされるが、IQは170くらいある。

**デフォルトの名無しさん** · 2021/05/28(金) 13:20:08.34

IQが20違うともう対話が成立しないって聞いたことがある

**デフォルトの名無しさん** · 2021/05/28(金) 13:31:32.53

「a&は禁止されてるから禁止」て言ってるだけじゃねえか
バカなのかコイツ

**デフォルトの名無しさん** · 2021/05/28(金) 14:17:05.39

>>106
そうじゃない。a& という部分式が、記号として未定義と言っている。
禁止じゃなく、未定義。数学でも、
-a
は符号反転とか、負符合という意味で定義されているが、
a-
は定義されていないのと同様。
禁止ではなく、定義されない。だからエラーになる。

**デフォルトの名無しさん** · 2021/05/28(金) 14:21:07.08

「パーサーが受理しない」なら言っていい

**デフォルトの名無しさん** · 2021/05/28(金) 14:40:50.20

未定義って言ってんじゃん
パーサーなんて規格票で使わない用語を持ち出す必要ねえよ

**デフォルトの名無しさん** · 2021/05/28(金) 14:40:59.94

>>108
それでは、なぜ受理(認識)しないのかという理由が曖昧。
理由は、そのトークン列が「未定義だから」。

**デフォルトの名無しさん** · 2021/05/28(金) 14:46:15.77

>>110
還元できる構文規則がないからだよ
redexは非終端記号も含むから「トークン列」はそもそも誤り

**デフォルトの名無しさん** · 2021/05/28(金) 14:50:28.42

>>111
専門用語をなるべく使わずに平易に説明してるつもりだった。

**デフォルトの名無しさん** · 2021/05/28(金) 14:55:24.82

俺は、非終端記号、構文規則、redex、受理みたいな専門用語はなるべく使わずに、
生まれながらの頭の良ささえあれば理解できる様に書いたつもりだ。
だから、他に本などを読まなくても俺の説明をちゃんと読めば、数学的に高IQの人なら
理解できるはず。

**デフォルトの名無しさん** · 2021/05/28(金) 15:32:28.15

>>105

**デフォルトの名無しさん** · 2021/05/28(金) 15:39:25.96

> 独自記法もやめてな

脳天にどでかいブーメランぶっ刺さってんぞｗ

**デフォルトの名無しさん** · 2021/05/28(金) 19:49:19.58

定義されてないから未定義なのか
定義できないから未定義なのか

未定義にしている理由なら、禁止してるから定義にないのは当然じゃん
定義にあるのは許可されたやつだけだから禁止されたものは書かれてない
定義に無いから禁止されてる
未定義＝禁止であって、未定義なのは禁止されてるから

なんで無いのかを聞いてるんだからどっかで禁止されたんだろ
で、答えが「未定義だから定義には無い」「禁止されたから禁止されている」何も言ってないじゃないか

なんでそのルールが無いのか、ルールそのものには書いてないじゃん

**デフォルトの名無しさん** · 2021/05/28(金) 20:19:45.17

>>116
？？？
c++標準で未定義と定義されているのが「未定義」だろ。

>定義されてないから未定義なのか
>定義できないから未定義なのか
どちらもc++の「未定義」じゃない。
c++標準くらい読めよ。

**デフォルトの名無しさん** · 2021/05/28(金) 20:26:19.34

関数呼び出し時の引数の評価順は未だに未規定(unspecified)ですね
でも未定義(undefined)ではない
最適化をしやすくするためとか

**デフォルトの名無しさん** · 2021/05/28(金) 20:42:46.54

コイツが言ってんのは、構文解析の規則にないから未定義であり禁止、だろ
禁止されてんのは構文規則には入ってないです、未定義だからです、だから禁止です、ってな

そりゃ構文規則には受理する規則だけが書いてあるだけなんだから受理しない規則は書いてない
定義しない理由があったんならそりゃ禁止する理由だ
でなければ定義に書かれている

構文ルールに入って無いのはそのルールが未定義なのか禁止されてるだけなのかそもそも定義できないのか、それは分からないだろ
だから禁止されているかどうかの答えにはなってない

禁止されたから構文ルールには入ってねえんだよ

**デフォルトの名無しさん** · 2021/05/28(金) 23:14:02.41

ある入力を受理するかどうか未定義ってどうやって書くんじゃ……
わざとあいまいなNFAにでもするのか…………
つかBNFはPDAなのでは……………………
PDNFAみたいなもんがこの世にはあるんか…………………………………………

**デフォルトの名無しさん** · 2021/05/29(土) 01:22:28.79

初期化されてない自動変数やポインタを使うのはスリルあるね

**デフォルトの名無しさん** · 2021/05/29(土) 01:28:07.59

>>120
構文規則には、その言語(C/C++など)で定義されたパターンを、非終端記号と終端記号を
組み合わせてBNFなどを使って書く(その構文規則をコンパイラ理論では「文法」と呼んでいる。)。
トークン列が、その構文規則のパターンに当てはまる場合、「認識された」という。
このとき、認識されないトークン列はエラーであり「受理されない」。
ようは、文法規則に当てはまってないトークン列が、「受理されない/未定義」。

**デフォルトの名無しさん** · 2021/05/29(土) 01:39:13.51

>>116
C++の宣言文において、&x を x が参照型であることを意味する文法を最初に
定義するのは、人間。そういう言語にしたいからそうしただけ。
そしてその文法は、(必須ではないが)、BNFなどを使った構文規則として仕様公開される。
C++の構文規則には、x&というパターンは書いてない。
なので、積極的に「禁止」しなくても、トークン列にx&というものが現れても、
どの構文規則にも「マッチング」しないのでエラーが表示される。
それだけのこと。

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/29(土) 02:08:34.72

仕様が提示する構文規則 (BNF) に合致しないというレベルの違反は診断対象規則 (diagnosable rules) に反するので処理系がユーザに通知する義務はある。

**デフォルトの名無しさん** · 2021/05/29(土) 02:51:05.83

>>122
受理されなかった入力は非マッチなのであってエラーの一択なのでは……

**デフォルトの名無しさん** · 2021/05/29(土) 02:53:15.80

>>123
x&とかxが型なら普通にパターンとして現れるのでは…………

**デフォルトの名無しさん** · 2021/05/29(土) 03:11:30.39

「C++の構文規則にマッチする入力テキストの集合」が一意確定になることを疑う理由は無いから
入力テキストにわざわざ未定義などというクラスを設けるする必要は無いのでは……………………

**デフォルトの名無しさん** · 2021/05/29(土) 03:13:13.35

>>126
構文規則の中に x&y は存在しているが、x&単独では存在していない。
だから、z = x&y; や z=(x&y) は受理されるが、z = x&; や z=(x&)
はエラーになる。

**デフォルトの名無しさん** · 2021/05/29(土) 03:14:43.85

>>126
おっと、読み間違えた。
xが型の場合は受理されるよ。
xが名前トークンの場合は受理されない。

**デフォルトの名無しさん** · 2021/05/29(土) 03:21:31.22

>>129
[補足]
・xが名前トークンでも意味論的にxが型名とみなせる場合にはxは型だと扱われる。
・xが変数名の場合には変数だとみなされる。
・xが変数名の場合には、x&yは文法の中の有る規則にマッチングするので
　受理されるが、xが変数名の場合にはx&という文法規則は存在してないので
　どんな文法規則にもマッチングできないのでエラーになる。

**デフォルトの名無しさん** · 2021/05/29(土) 03:24:12.95

>>130
[さらに補足]
・xが(ユーザー定義の)型名の場合でも、それが現れる文脈次第で
　x&が受理され無い事がある。
　文脈によって受理されるパターンが違うので。

**デフォルトの名無しさん** · 2021/05/29(土) 16:51:48.20

たぶんくそしょうもない質問いいですか

コンストラクタの初期化子リストで
まさに今初期化したばっかりの他のメンバを使うのはアリですか

class Foo{
Foo(Bar bar,Baz baz);
Bar bar_;
Baz baz_;
...
};

Foo::Foo(Bar bar,Baz baz)
:bar_(42)
,baz_(bar_) // ← これ
{...
自分の環境では動いてるようですが
規格に照らし合わせて合法なものなのでしょうか？

**デフォルトの名無しさん** · 2021/05/29(土) 16:59:07.85

>>132
クラスのメンバ変数は定義に書かれた順に初期化されるから、その例についてはokなんじゃないかな

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/29(土) 17:29:48.88

メンバ初期化子として書いた順ではなくクラス定義内のデータメンバ宣言順に従うというのが重要ポイントで、
勘違いを防ぐために宣言順とメンバ初期化子の順序は一致させるのが一般的な習慣になってる。
(一致させなくてもそれ自体は規格違反ではない。)

C++20 から入る指示付初期化 (Designated initialization) で順序を一致させるのが必須に
なっているのはこのへんの反省があったんだと思う。

**デフォルトの名無しさん** · 2021/05/29(土) 19:10:01.56

各位　ありがとう

>>134
後半はへーって感じなので調べてみる

**デフォルトの名無しさん** · 2021/05/31(月) 20:14:45.42

構造化束縛とか範囲for文が必ず新規にオブジェクトを宣言しないといけない仕様になってるのが何気に解せないのだが
既存のオブジェクトを使い回せた方が都合良いだろうに、なぜこういうことになったの？

**デフォルトの名無しさん** · 2021/05/31(月) 20:47:21.20

構造化束縛の方はtieで行けるだろ

int a, b;
std::tie(a, b) = std::make_pair(1, 2);

**デフォルトの名無しさん** · 2021/05/31(月) 20:48:51.74

参照じゃダメ？

**デフォルトの名無しさん** · 2021/05/31(月) 21:28:28.96

c++11やり始めた頃、for(auto& e:～やfor(const auto& e:～と出来るのを知らず、酷いコードを大量に垂れ流してしまったよ

**デフォルトの名無しさん** · 2021/05/31(月) 22:31:51.93

>>138
参照にしてもfor文のスコープ外で宣言できた方が都合が良いことがままある

**デフォルトの名無しさん** · 2021/06/01(火) 01:12:38.27

ループの最後の値を使いたいという事？

**デフォルトの名無しさん** · 2021/06/01(火) 09:11:18.08

>>140
言っても「稀に」程度だろうし、やりたければスコープ外で宣言した変数に代入すれば済む。
何を問題としているのかわからない。

**デフォルトの名無しさん** · 2021/06/01(火) 12:18:45.46

お漏らし推奨

**デフォルトの名無しさん** · 2021/06/01(火) 12:20:20.23

自作関数の引数を initializer_list にするのってなんか使い道あるんですか？
参照の組を渡せる？

**デフォルトの名無しさん** · 2021/06/01(火) 18:21:02.43

MyVector v{1,2,3,4,5};
とかできる

**デフォルトの名無しさん** · 2021/06/01(火) 20:14:13.74

ま、まいべくたーｗ

**デフォルトの名無しさん** · 2021/06/02(水) 06:27:13.91

>>145
コンストラクタの引数にするくらいしかメリットないの？
前スレ掘ってたら、同じ型の参照の組なら initializer_list で関数に投げれるってのを見つけたんだがそれはどうやんの
initializer_listを引数にとる関数 hoge を
hoge({fuga, var, aaa})
って呼び出したら実体を渡してることになるよね？

**デフォルトの名無しさん** · 2021/06/02(水) 06:48:10.69

MyVector(initializer_list<reference_wrapper<int>>) { }

**デフォルトの名無しさん** · 2021/06/02(水) 07:01:45.97

>>148
それって vector< reference_wrapper<T> > とは違うんけ？

**デフォルトの名無しさん** · 2021/06/02(水) 07:55:44.63

template <class T>をつけるならね

**デフォルトの名無しさん** · 2021/06/02(水) 07:57:13.92

reference_wrapperはC++11からでC++03にはないから> >にする意味ないぞ

**デフォルトの名無しさん** · 2021/06/02(水) 08:15:03.57

初期化のときに登場する｛｝が初期化子リストだと言うことがつい最近判明した
概念を区分して分離したのが一番大きいので、用途についてはあまり考えられていない

**デフォルトの名無しさん** · 2021/06/02(水) 08:44:42.49

>>151
いや自分の可読性のためにそうしてるだけ
他の人にとってはそっちの方が見づらかったらすみません

それはそうと、関数に参照の組を渡すなら、initializer_list 云々というよりは reference_wrapper の組として渡すってことですね

もう一点、関数に initializer_list を渡すときって
・関数の引数の型が initializer_list である
よりも
・関数の引数のコンテナを initializer_list で初期化している
の方がしっくりくるんですが、前者で設計するメリットってありますか

**デフォルトの名無しさん** · 2021/06/02(水) 10:14:59.83

overloadに弱くなる

**デフォルトの名無しさん** · 2021/06/02(水) 10:21:56.66

>>153
長かったC++03時代でそういうクセが染みついちまった、ならわかる

**デフォルトの名無しさん** · 2021/06/02(水) 10:48:08.32

気狂いいてワロ
(a, b, c) と ( a, b, c ) さえどちらが良いかなんて誰にも決められないのに、なぜ < <> > と <<>> なら後者の方が問答無用で良いと思い込んでるのだろうか
こういう、一概には言えないことを押し付けるタチの異常者が回答側に回ってるのイタ過ぎだろ

**デフォルトの名無しさん** · 2021/06/02(水) 10:51:36.57

同和ンゴ

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/02(水) 11:11:42.37

トークン分割の段階では >> というひとつのトークンとして切り出された上で
構文解析の側で辻褄を合わせるという変な解釈が不格好だから好きじゃないな。
構文が複雑になる分には仕方がないと割り切れるんだが、
異なるレイヤをまたいで辻褄合わせするのってなんか嫌じゃない？

でもまあ > > よりは >> のほうが見やすい気がするからそう書いてるんだけど、
割とモヤモヤしがち。

**デフォルトの名無しさん** · 2021/06/02(水) 11:13:17.27

何で押しつけたことになるんだ？
被害妄想で攻撃的になるやつこそ病んでるぞ

スタイルは案件ごとにある
そこでいらぬ波風立てるやつは叩き出される
仕事は成果で語るものなのに勘違いして
つまらんことに気を取られるやつは使い物にならん

**デフォルトの名無しさん** · 2021/06/02(水) 11:41:07.35

>>149
おそらく初期化子リスト版の方が高速に動作する
まぁ、今時のコンパイラの最適化は変態レベルに進化してるから結局同じようなコードに落ち着くかもしれないけど

**デフォルトの名無しさん** · 2021/06/02(水) 11:54:53.84

>>154
initializer_list をとることにしておけばコンテナの種類を決めておく必要がないから得ってことですか？

**デフォルトの名無しさん** · 2021/06/02(水) 12:01:59.24

>>159
> スタイルは案件ごとにある
元質問はスタイルが指定された案件では全くないので、自分が頓珍漢なこと言ってたって認めるわけね

> そこでいらぬ波風立てるやつは叩き出される
> つまらんことに気を取られるやつは使い物にならん
狂おしいまでに己のことだな

**デフォルトの名無しさん** · 2021/06/02(水) 12:11:17.92

>>162
元質問には特定の案件か否かはどちらとも書いていないね
さらに俺は特定の案件の話だともそうでないとも言ってない

次から次へと勝手に決めつける軽率なやつが
他人に向かって頓珍漢とか天に唾するってやつだぜ

**デフォルトの名無しさん** · 2021/06/02(水) 12:24:56.03

恥ずかしくなってネタっぽくしてるが隠しきれてない同和ンゴ

**デフォルトの名無しさん** · 2021/06/04(金) 15:31:20.39

cout と cerr に同じもん流し込みたいときって
cout << hoge;
cerr << hoge;
ってやるしかない？
一行というか一文で書けたら楽だが

**デフォルトの名無しさん** · 2021/06/04(金) 15:57:51.35

>>165
すなおに以下のようなマクロにしとけばどうかな
#define HOGE(x) std::cout << x; std::cerr << x;
例えば以下のように使う
HOGE(hoge << endl);

**デフォルトの名無しさん** · 2021/06/04(金) 17:29:57.12

random_device{}();
の中括弧って何なん
デフォルトコンストラクタで構築するってこと？
なんで丸括弧じゃないん

**デフォルトの名無しさん** · 2021/06/04(金) 18:26:04.60

別に中()でも問題なくない？

**デフォルトの名無しさん** · 2021/06/05(土) 05:37:22.25

ラムダ式のキャプチャ構文の個別コピーとか個別参照がなんで存在するのかイミフなんだが
引数で良いじゃん

**デフォルトの名無しさん** · 2021/06/05(土) 07:13:07.04

キャプチャにもコストは掛かるから必要なものだけ最小限キャプチャしたい時に必要なんだよ
なぜ引数でいいと思うのかはイミフ

**デフォルトの名無しさん** · 2021/06/05(土) 07:24:52.28

既存の関数ポインタや関数オブジェクトと整合性を取るには、寿命やスコープの異なる変数を使うための仕組み(キャプチャ)が必要だったからでしょ

**デフォルトの名無しさん** · 2021/06/05(土) 07:29:08.22

とあるラムダ式を読みづらいと感じるならそこでは使わないほうがいい
煽っているわけではなくて、ラムダ式の存在意義は可読性の改善なので、ラムダ式を読みづらいのは本末転倒だからね

**デフォルトの名無しさん** · 2021/06/05(土) 07:39:00.13

>>170
キャプチャデフォルトにしても使わなかったやつはキャプチャされないから
あえて個別にするのは何か理由があるときだね

**デフォルトの名無しさん** · 2021/06/05(土) 08:28:34.32

>>170
キャプチャできるオブジェクトってみんな引数としても渡せるじゃん
参照、const参照、コピーも自由自在だし
コストって言うけど、参照キャプチャと参照渡し、コピーキャプチャとコピー渡しってコスト違うの？

一応断っておくと[&]と[=]の存在意義は分かる
オブジェクトを個別にキャプチャするのがイミフってだけ
「こういうときに使う。引数渡しではできない」という例があったら教えていただきたいです

**デフォルトの名無しさん** · 2021/06/05(土) 08:43:36.40

ラムダ式がキャプチャするタイミングと呼び出すタイミングは違ってもいい

**デフォルトの名無しさん** · 2021/06/05(土) 08:53:12.54

呼び出し時にキャプチャ元の存在は保証されない自己責任

**デフォルトの名無しさん** · 2021/06/05(土) 09:10:01.93

>>174
これを引数渡しではどう書く？

random_device dev;
int ary[256];
generate(begin(ary), end(ary), [&]{ return dev(); });

**デフォルトの名無しさん** · 2021/06/05(土) 09:10:44.09

>>175
なるほど
コピーしたいけど呼び出しの度には嫌だ、というときに役立つのか
神機能だな

**デフォルトの名無しさん** · 2021/06/05(土) 09:11:42.81

>>177
もう解決しました

**デフォルトの名無しさん** · 2021/06/05(土) 09:21:58.27

>>176
コピーならHOSYOUされる

>>178
つか新しい関数を作る機能

>>169
カリー化

**デフォルトの名無しさん** · 2021/06/05(土) 09:28:59.14

普通のｷｬﾌﾟﾁｬ（コピー）ではなくて
異常なｷｬﾌﾟﾁｬ（参照のｷｬﾌﾟﾁｬ）なら呼び出し時にキャプチャ元（参照されているオブジェクト）
の存在はＨＯＳＹＯＵされないから注意しないとＫＩＫＥＮだが
なんでそんな機能があるのかというとオブジェクトをカリー化（？）する場合にあったら便利だねえ、ぐらいの勢いの話
普通のｷｬﾌﾟﾁｬだけでもポインタをｷｬﾌﾟﾁｬしたら同じことができる

**デフォルトの名無しさん** · 2021/06/05(土) 09:37:27.71

もっとも、自動変数として作られたオブジェクトxをｷｬﾌﾟﾁｬする場合、
xを参照のキャプチャする代わりに&xを普通のキャプチャしてしまうと
（「＆」演算子が使われたことにより）微
妙に最適化に響きかねない問題というのは微妙にあるが微妙なので普通は気にするほどではないはず……

**デフォルトの名無しさん** · 2021/06/05(土) 09:53:54.69

元のデータをFUCKYUできないような書き方はAUTO

**デフォルトの名無しさん** · 2021/06/05(土) 10:05:44.68

キモい言葉遣いヤメレ

◆QZaw55cn4c · 2021/06/05(土) 15:25:47.75

ヒドロキシクルルキン
イベルメクチン

◆QZaw55cn4c · 2021/06/05(土) 15:26:27.50

ヒドロキシクロロキン
イベルメクチン

**デフォルトの名無しさん** · 2021/06/05(土) 16:15:28.53

C++において関数は第一級オブジェクト
なのに C++ が関数型プログラミングを全く想定していない仕様に思えるのはなぜ

**デフォルトの名無しさん** · 2021/06/05(土) 16:15:54.58

関数型のパラダイムもうまく取り込んでほしい

**デフォルトの名無しさん** · 2021/06/05(土) 16:34:45.82

>>187 古いから。
>>188 提案するのは自由だから、がんばって。

**デフォルトの名無しさん** · 2021/06/05(土) 16:53:27.35

>>187
c++の関数は第一級オブジェクトじゃないだろ。
高階プログラムはテンプレートという別の仕組みでサポートしている。

**デフォルトの名無しさん** · 2021/06/05(土) 18:54:44.68

関数型プログラミングは別に古くないはず……
ＧＥＮＪＩＴＳＵ世界が状態を持ち破壊的代入を伴うから
まだチューリングマシン的な計算モデルの方が対応がとりやすい（気がする）だけ
C/C++が関数型プログラミング一本鎗にならないのはそれが根本原因

**デフォルトの名無しさん** · 2021/06/05(土) 20:10:51.62

・弱体化された関数型の機能
・構造化プログラミング
・GOTO文
これがCだよ

で、多分70年代当時は関数型プログラミングはおそらく過去の遺物になってた
でないとこの頃のlispの失速が説明つかない

**デフォルトの名無しさん** · 2021/06/05(土) 20:22:19.29

当時生まれてないけど
あのマシン性能が貧相な時代によくLISPなんて流行ってたな

**デフォルトの名無しさん** · 2021/06/05(土) 20:31:42.60

むしろマシンリソースが少ない時代だからこそ流行したといえる
LISPマシンはすなわちスタックマシンだ
複雑な語句パーサーとツリー構造の構築がなくても、ストリームから
はいってきたキーワードを順繰りに解釈してスタックにつんでいき
かっこが閉じたらスタックからひっぱればちゃんと動くものがつくれる

**デフォルトの名無しさん** · 2021/06/05(土) 20:53:06.54

>>190
禿は「第一級オブジェクト」をテンポラリでないオブジェクトと言っているようだが

**デフォルトの名無しさん** · 2021/06/05(土) 21:21:58.41

権威者がこれこれと言ってたからこれこれであるという話の持って行き方は
今日の世界では小学生レベルの人間しかしない

中世ヨーロッパでは過去の偉人の言葉をいかにうまく引くかが議論の上手下手を左右したらしいが

**デフォルトの名無しさん** · 2021/06/05(土) 21:28:06.29

その世界の教祖のような人でも一切、言葉を引いてはいけないのか
小学生で年収1000越えそうな人ってジュジュちゃんとかいるけど
自分の年収を棚に上げてわかったようなことをｗ

**デフォルトの名無しさん** · 2021/06/05(土) 22:00:37.95

>>194
それForthじゃね？

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/05(土) 22:00:51.75

>>196
ここで必要なのは範例ではなく定義。
何が正しいのかを議論したいわけじゃなくてどの定義を使う「ことにする」という擦り合わせ。
C++ における定義を決めるなら設計者の言を元にするのは妥当だろ。

それはそれとして >>195 はなんかおかしいこと言っていると思うし、
なんか勘違いしてそうな気がするが。

**デフォルトの名無しさん** · 2021/06/05(土) 22:49:20.33

関数型プログラミングが古いと主張する香具師は
MVCとかなMと表示等が分離した設計モデルでありかつ
Mがマルチスレッド（UIスレッドとは別）なケースのプログラミングを
ラムダ式を使わずにして見られれば宜しい
すっきり収拾をつけるにはコールバック関数として関数オブジェクトを渡すか、
コールバック関数をvoid*引数の関数にするという前近代的な設計にするかしかなく、
classを使って手で書く関数オブジェクトはラムダ式を見たコンパイラが生成するコードと大差ないから
前者は関数型プログラミングに他ならない
という印象、
※ 個人の感想です

それはそれとして>>192も相当おかしいことを言っていると思うし以下略