[過去ﾛｸﾞ] C++相談室 part157 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
453: 2021/09/29(水)10:21 ID:QYKzykPR(1) AAS
>>447
要は小学生がさんすうで習うような単純な数のことを「算術」と言うんだが
454(1): ハノン ◆QZaw55cn4c 2021/09/29(水)18:51 ID:+NS+8RdU(1) AAS
>>452
＞2自由度の行列に適切な演算を導入
有名な a b -b a 以外にも複素数と同様に振舞う行列を定義できるものでしょうか？それはどんな形？
455: 2021/09/29(水)19:37 ID:F6bYTA4Q(1) AAS
好きなX^2=-Iを満たす行列Xを用意すればaI+bXが複素数の表現になるよ
456(1): 2021/09/30(木)04:33 ID:a96KQdEj(1) AAS
>>454
> 有名な a b -b a 以外にも
> 複素数と同様に振舞う行列
この世のことを何一つとして理解してないことがよく伝わってくる2フレーズ
457: 2021/09/30(木)10:27 ID:rsDh5L5E(1) AAS
i 0
0 i
458: 2021/09/30(木)12:07 ID:CrfxKotF(1) AAS
複素数z=x+iy (x, y:実数)とした場合どうやって行列で表現できるのか分からん
そもそも無理だろ
459: 2021/09/30(木)12:15 ID:LH+TfD4u(1) AAS
いい加減スレチだぞお前ら
460(1): 2021/09/30(木)12:39 ID:HqpdIwHE(1) AAS
複素数の実行列表現あたりで調べれば出てくるから自分で調べろ。
複素数ライブラリの実装は行列表現だろ。
461: 2021/09/30(木)14:36 ID:rqtJMe+2(1) AAS
承認欲求が満たされなかったキチガイのハ◯ンが荒らしてるんだな
462: ハノン ◆QZaw55cn4c 2021/09/30(木)21:06 ID:SS5VJirH(1) AAS
>>460
キーワードありがとうございます！
1, 1, -2, -1 とか 3, 2, -5, -3 とか i に対応するものはいろいろあるんですね
>>456
生きていてすみません
463: 2021/09/30(木)22:32 ID:hyVGcxZ+(1) AAS
複素数ライブラリの実装が行列表現な訳ないだろ
464: 2021/10/01(金)04:28 ID:YSb3+a7i(1) AAS
パウリ行列やで
465: 2021/10/01(金)08:55 ID:wyBR1P+Z(1) AAS
それは四元数では
466: 2021/10/01(金)11:45 ID:o+E+DUKy(1) AAS
そもそも勝手な演算❎とかを用意して、それを複素数の演算になるような演算規則にすればいいだけの話
普通のプログラミング言語での実装は2要素ベクトルに対して複素数積となるような演算を＊に対応させているんだと思うけどな
行列積が複素数の積と同一視できるような表現行列があるというだけ
群論とか環論とか体論とか入門的にでもやればわかるよ
467(1): 2021/10/02(土)13:55 ID:cR/mfYmg(1/5) AAS
ベクトルの要素は座標変換で変わるからスカラーではない
468: 2021/10/02(土)13:59 ID:cR/mfYmg(2/5) AAS
まつがえたorz
誤： 変わるから
正： 変化すっから
469: 2021/10/02(土)14:34 ID:7v0dyN4q(1) AAS
物理屋さんか？
470: 2021/10/02(土)14:56 ID:cR/mfYmg(3/5) AAS
んまーたしかに物理現象は座標変換しても変わらない（同じもの）とみなすのが
物理の先生なのかもしれん スカラーもそん延長線上の概念
しかし観測が系に影響を与えると言い出した時点でいつまで真理でありつづけることやら……
471: 2021/10/02(土)20:42 ID:xJ5F1jwy(1) AAS
>>467
言葉足らずだったかもしれないが、複素数体と数学的にはR2の正規直交基底かつ基底の長さが1のベクトルの成分表示を、適切な演算を入れることによって同一視することができるという話をしているのであって、一般的なベクトル空間の話をしている訳ではない。
472: 2021/10/02(土)21:15 ID:cR/mfYmg(4/5) AAS
スカラーか否かというのは数をどこに使うかの話であって
数をどう表現するかの話ではないし、
473: 2021/10/02(土)21:16 ID:cR/mfYmg(5/5) AAS
それはそうとしてR^2と言っただけでは計量が入っていないから（平行移動も糞も無いため）ベクトル空間ではない
つまり { ベクトル空間 } ⊂ { R^2 } であってR^2の方がより一般的
R^2上で実数と同じ7つの演算則を満たす演算を形式的に定義することはできるが|i|=1を表すために
>正規直交基底かつ基底の長さが1のベクトルの成分表示
が必要になるから複素数体を正確に言い表すにはR^2ではなくてユークリッド空間か何かが要ることになるんじゃないの
474: 2021/10/02(土)22:42 ID:5uoG6j9g(1) AAS
加法(V × V → V)と係数体による倍演算(K × V → V)が入ってて線型ならベクトル空間だよ, 計量入れたら計量ベクトル空間
475(3): 2021/10/05(火)17:00 ID:YgA3J5wy(1) AAS
関数の引数に参照渡しで何も渡さないようにするはどうすればよいですか
自作クラスAがあったとして、それを引数にとる関数
void hoge(int& p1, A& p2)
があります。
ただ、p2は、ケースによっては要らない場合もあって、その場合にはどうすればよいですか。
調べてみたらnullptrみたいなのはあったので、
int p1 = 1;
hoge(p1, nullptr);
と書いてみても、
非constの左辺が何とかとエラーが出て、渡せませんでした。
476(2): 2021/10/05(火)17:34 ID:lBT+65cn(1/3) AAS
*nullptr
477(1): はちみつ餃子 ◆8X2XSCHEME 2021/10/05(火)17:41 ID:krkmojOq(1/3) AAS
>>475
参照は何も参照していない状態というのは作れない。
参照で受け取るように書いてあればその参照が無効ということはあり得ないという表明として解釈するのが通例。
(実際にはダングリング参照はあり得るけどそれは単に間違ったプログラムなので気にしない。)
引数として不要なのであればオーバーロードで引数が不要な関数も用意するのが真っ当な方法だけれど、
どうしても無効ということを表す状態を渡したいということであればダミーのオブジェクトを作っておいて
それを無効の意味に使うという方法は考えられる。 (不格好だけど……。)
#include <iostream>
struct A {};
A dummy;
省11
478: 2021/10/05(火)17:45 ID:UD2fraRe(1) AAS
NullObjectパターンすね
479: 2021/10/05(火)17:48 ID:lBT+65cn(2/3) AAS
hoge(p1,* static_cast<A*>(nullptr));
480(2): 2021/10/05(火)17:49 ID:3jRalumJ(1) AAS
>>476
*(A *)nullptr にしないとエラーになるな
そいで関数側で&p2==nullptrでnullptrが渡されたかどうかチェックできるね
でもこんなの許されてるの？
481: はちみつ餃子 ◆8X2XSCHEME 2021/10/05(火)17:52 ID:krkmojOq(2/3) AAS
>>476 >>480
当然だけど (空ポインタを含めて) 無効なポインタをデリファレンスしたらその時点で未定義。
482(2): 2021/10/05(火)19:00 ID:lBT+65cn(3/3) AAS
何いってんだ
キチンと動作する
ただの参照なんだから未定義じゃないだろ
他の変数に受け渡してるワケでもないし
483: はちみつ餃子 ◆8X2XSCHEME 2021/10/05(火)19:59 ID:krkmojOq(3/3) AAS
>>482
実質的な (コンパイルされた後の) 動作として値を取り出す必要がないというのは、
言語仕様上において * の適用を無かったことに出来るわけではない。
(C には単項 * の結果に単項 & を適用した場合に相殺されてどちらも無かったことになる規則があるが……。)
484: 2021/10/05(火)20:26 ID:SwNxahaG(1) AAS
また未定義動作なんか怖くない君か
命知らずなのはいいけどチームプログラミングには関わらないでね本当に迷惑だから
485(1): 2021/10/05(火)20:32 ID:7rL/DhC7(1) AAS
1. 参照をやめてポインタにする
2. std::optional<T>を使う(C++17以降)
俺ならこのどっちか
486: 2021/10/05(火)22:18 ID:bhHmmGon(1/3) AAS
クラスTが自作クラスなら
Tにnulを意味するlオブジェクトを定義すれば良い……
>>477なdummyオブジェクト方式はテンプレートの中で使いにくくなるいはず
>>485なstd::optional<T>案はどうせ余計な記憶を要するのだからT固有のnullを定義するうのとイーブン
487: 2021/10/05(火)22:24 ID:bhHmmGon(2/3) AAS
もちろんT固有のnull「値」の定義においては
オブジェクトの参照 == null値、
はアドレスの一致ではなく値の一致として解釈されねばならな
い
488: 2021/10/05(火)22:44 ID:bhHmmGon(3/3) AAS
さもないと、クラスTのnull値をT_NULLみたいな名前にしたとして、
T arr[] = { T_NULL, T_NULL, T_NULL, T_NULL };
みたいなことができないか
らな
489(1): 2021/10/06(水)00:36 ID:meWA0K5y(1) AAS
>>480,482
gcc 11 の -O2 で「&p2==nullptrでnullptrが渡されたかどうかチェック」はできなかった。
外部ﾘﾝｸ:wandbox.org
490: 2021/10/06(水)00:55 ID:E9G/hK4q(1/4) AAS
void hoge(int& p1, optional<A>& p2 = nullopt) { // constじゃないのでエラー
みたいなことってoptionalで上手いことやる方法ないの？
呼び出し元は
int i;
A a;
hoge(i, a);
hoge(i);
みたいな感じで
書き換えられるけどhogeから抜けたら消える初期値nulloptのoptional<A>をデフォルト値で渡せるのか知りたい
491: 2021/10/06(水)01:23 ID:V3EBITWg(1/2) AAS
なにいってんだおめ
492: 2021/10/06(水)01:31 ID:V3EBITWg(2/2) AAS
nullopt以外が渡されたらそのA&に対して、
nulloptが渡されたらスタックにAを構築したうえでそのA&に対して操作したい、ってこと？
それはvoid hoge(int& p1, A& p2 = デフォルト値)でいけるんじゃないかい
493(1): 2021/10/06(水)01:49 ID:E9G/hK4q(2/4) AAS
伝わらないようなので、コード書きました
外部ﾘﾝｸ:wandbox.org
494(1): はちみつ餃子 ◆8X2XSCHEME 2021/10/06(水)03:08 ID:3d8zh1Pt(1) AAS
>>493
やりたいことは std::optional<A>& ではなくて std::optional<A&> 的なことだろ。
しかし std::optional は参照を保持できないのでそういうときのために std::reference_wrapper がある。
コードにしたらこんな感じ。
外部ﾘﾝｸ:wandbox.org
495: 2021/10/06(水)06:31 ID:lNsYT/rw(1) AAS
部分特殊化できないのは関数テンプレートだよな
template<class T1, class T2>
struct test {
void fig1();
void fig2();
void fig3();
};
template< > void test<void, void>::fig1(); //ok
template<class T1> void test<T1 , void>::fig2(); //error
template<class T2> void test<void, T2 >::fig3(); //error
省1
496(1): 2021/10/06(水)06:43 ID:Cv4NDZSF(1/2) AAS
その部分特殊化されたtest(構造体)が定義されてないからだね
先にtestの部分特殊化を書けば通る
497(1): 2021/10/06(水)07:59 ID:E9G/hK4q(3/4) AAS
>>494
std::reference_wrapperは知りませんでした
std::optional<A>をstd::optional<A*>にしてconstのままいじれるようにした気分なので
実質無理ってことなのかなぁと思いますが…
ありがとうございます
498(1): 2021/10/06(水)08:17 ID:fON1wZ9Y(1) AAS
>>475
普通はオーバーロードだな。デフォルトを指定させたいのならnullobjectを始めとする定数オブジェクトかね。
nullポインタとか空のスマートポインタとかはエラーの元だから避けたいところ。
499: 2021/10/06(水)08:26 ID:E9G/hK4q(4/4) AAS
>>497
自己レスです
いずれにしても呼び出し元を変更せずに要件を満たせそうな唯一の方法っぽいので解決ですね
(私は>>475ではありません)
500: 2021/10/06(水)08:34 ID:4yqQ2QZ4(1) AAS
今は継承はなるべく使わない、がデフォなのかな
501: 2021/10/06(水)09:11 ID:lTl3I+RT(1/2) AAS
クラステンプレートがナウい
502: 2021/10/06(水)09:13 ID:lTl3I+RT(2/2) AAS
とはいえ、いきなりテンプレートにするのはハードル高いので、
結局は、継承クラスをいくつか作ってみてテンプレート化を試すことになる
503: 2021/10/06(水)09:41 ID:DE23Rkof(1) AAS
>>498
> 普通はオーバーロードだな。
これに一票
504: 2021/10/06(水)10:03 ID:7OUEgWer(1) AAS
>>489
gcc7でも-O2つけるとダメだね
つけなきゃ一致するけど
505: 2021/10/06(水)10:45 ID:Cv4NDZSF(2/2) AAS
デフォとかナウいとかアホかと
506: 2021/10/06(水)12:20 ID:iqYhGyd9(1) AAS
最適化オプションの違いで挙動が変わるようなコードはそもそもダメだって理解してくれよ
507: 2021/10/06(水)13:11 ID:BBSbIN5v(1) AAS
インテルコンパイラはもう規格満たしてないだろってくらい滅茶苦茶に挙動を変える
gccなら、最適化で結果が変わるようなコードはダメコードと言って良いと思う
508: 2021/10/08(金)05:56 ID:Xasiu/5n(1) AAS
>>496
遅レスすまそ
testなら部分特殊化できるのはわかるんだが
その場合クラス定義の全部を書き直すよな
template<class T1>
struct test<T1, void>
{
void fig1();
void fig2(); //特殊化したいのはここだけ
void fig3();
省3
509(1): 2021/10/08(金)23:05 ID:xNy0cJty(1) AAS
関数テンプレート内でラムダ式使おうとしたらコンパイルできない
template<class T> void hoge(){
auto func = [](){return 0;};
}
int main(){
hoge<int>();
return 0;
}
in instantiation of function template specialization 'hoge<int>' requested here
と出るが、何がだめなのかよくわからん
510: はちみつ餃子 ◆8X2XSCHEME 2021/10/08(金)23:18 ID:ZAq25yo3(1/2) AAS
>>509
そのメッセージは「関数テンプレートはここで特殊化 (テンプレート引数を当てはめて具体的な型に展開) されたやで」
というメッセージで、普通は他の警告やエラーの補足として出てくる。 なんか警告が一緒に出てない？
func が定義されとるけど使ってないという警告は出てくるけど無視して問題ない警告なのでコンパイルできないってことはない。
警告をエラー扱いにするオプションを付けてたりしない？
511(1): 2021/10/08(金)23:23 ID:awgtN1Ul(1) AAS
C+pod
画像ﾘﾝｸ[jpg]:toyota.jp
512: はちみつ餃子 ◆8X2XSCHEME 2021/10/08(金)23:28 ID:ZAq25yo3(2/2) AAS
>>511
C++20 では std::is_pod や POD の概念自体が非推奨になってるぞ。
次あたりでは廃止されるんとちゃうか。
513(1): 2021/10/09(土)21:11 ID:PhB5rfBq(1) AAS
あるラムダ式が他のラムダ式をコピーするとき、参照キャプチャにするかコピーキャプチャにするか迷うんですが、皆さんはどういう基準で決められてますか
514: 2021/10/09(土)21:14 ID:yAn344zh(1/2) AAS
外部ﾘﾝｸ:ideone.com
やたーセマフォできたよ。
これバグってるかな?
515: 2021/10/09(土)21:17 ID:yAn344zh(2/2) AAS
>>513
コピーキャプチャはコピーなので、それ相応のリソースを食う。
基本は参照キャプチャにしている。
516(2): 2021/10/10(日)01:44 ID:qGt3mQky(1/7) AAS
破壊的代入の余地が無いようする
つまりコピーを第一の選択肢として考えるする
517: 2021/10/10(日)01:50 ID:qGt3mQky(2/7) AAS
*thisはさすがに参照にすることが多いが（だいたいコピコンがあるとも限らないし、
とはいえ参照コピーしてパラメータに対する破壊的代入を許すと思想的に重箱読みになって気持ち悪い気がするし、
参照渡ししたオブジェクトは一般にスレッドローカルとは言い切れなくなることから
スレッドセーフと断言しにくくなるというのは実害に数えて良いと思う
入れ子になったラムダ式の奥深くでそれをやられると、いつ排他制御すべきなのかが全くﾜｹﾜｶﾒになりかねない
518(1): 2021/10/10(日)04:41 ID:/ScOmKIj(1) AAS
>>516
だとすると一番効果的なのは
C++でコード書くこと自体をやめることだな
あんたの場合は
519(1): 2021/10/10(日)07:01 ID:H3uBjuzu(1) AAS
>>516
コピーキャプチャが第一選択肢という結論は分かるが
それ以外の説明が完全に意味不明
520: 2021/10/10(日)09:28 ID:lWUpu20f(1/8) AAS
意図しない破壊を防ぐにはキャプチャしなきゃいいだけ
それを参照のせいにするゴミはプログラマの資質がない
521: 2021/10/10(日)09:31 ID:MbdCJRMe(1/2) AAS
とりあえずで[&]で書いてるな
丁寧にやりたければ変数ごとに考えて明示する
522(2): 2021/10/10(日)09:34 ID:lWUpu20f(2/8) AAS
コピーのコストに無頓着なやつは11以後のC++に向かないな
523: 2021/10/10(日)10:09 ID:B/tc3JZb(1/3) AAS
スレッド立ち上げるとかファイル書くとかクソ重い操作が伴う時にコピーコスト気にしてもしょうがない
場合によるとしか
524: 2021/10/10(日)10:37 ID:2ZvzU42q(1/7) AAS
どこでも使う汎用性高いものなら問題が起きる前に[=]にしてる
逆に[&]はよほど安全だと思わない限り使わない
525(1): 2021/10/10(日)10:45 ID:qGt3mQky(3/7) AAS
>>522
スレッドセーフをどう保証するかに無頓着な香具師はマルチスレッドプログラミングに向かんわ
>>518、>>519
低レベルなレスどうも
ラムダ式の成り立ちを知らなかったり
どのように使われるか想像できなかったり
使ったこと無いんじゃね；；；
526(1): 2021/10/10(日)10:59 ID:lWUpu20f(3/8) AAS
>>525
スレッドがどうたらはおまえさんが勝手に言い出したことで元質問にはない
まさかとは思うがコピーしてりゃスレッドセーフなんて主張はしてないよな
527(1): 2021/10/10(日)11:13 ID:qGt3mQky(4/7) AAS
ラムダ式は一般にラムダ式を定義したスコープの外に持ち出され、予見できないタイミングで使われうる
参照キャプチャだと
(1) ラムダ式が使われるタイミングで参照xの参照先が存在することが保証されていなければならない
(2) ラムダ式が使われるタイミングで参照xの参照先へのアクセスが他のスレッドと競合しないことが保証されていなければならない
とゆー2条件をクリアする必要がある。
コピーキャプチャだと（オブジェクトがディープコピーなら）どっちの配慮も不要
参照キャプチャして(1)、(2)を満たして安心できるのは、イミュータブルなオブジェクトだけ……！
528(1): 2021/10/10(日)11:14 ID:qGt3mQky(5/7) AAS
>>526
ラムダ式、が含意する事柄について不十分な理解なレスktkr、
危険プログラマー認定のレベル3ぐらいやな；；；
529(2): 2021/10/10(日)11:18 ID:B/tc3JZb(2/3) AAS
>>527
ラムダ式をスコープ外に持ち出すなんてレアケースを「一般に」とか言われましても
530: 2021/10/10(日)11:28 ID:2ZvzU42q(2/7) AAS
遅延評価されるものはよくコンテナに入れて後でぶん回されるから・・・
531(1): 2021/10/10(日)11:28 ID:qGt3mQky(6/7) AAS
>>529
定義するのと使う（評価する）のを同じスコープ内でやるならラムダ式使うまでもないじゃん？
ていうか使うまでもないんですよ
>>529はｱﾚな人？
532: 2021/10/10(日)11:38 ID:QniiN4Lz(1) AAS
スコープ内の変数をキャプチャする処理をスレッドで動かす場合は普通にラムダ式を使うと思うが。
533(1): 2021/10/10(日)11:39 ID:B/tc3JZb(3/3) AAS
>>531
はぁ？お前これしないの？ラムダ式のユースケースって9割方この類だろ
std::functionに突っ込んではるか遠くにぶん投げたりコンテナに詰め込んだりするのだけがラムダ式の使い道だと思ってるの？
std::sort(v.begin(), v.end(), [](int a, int b){/*...*/});
534: 2021/10/10(日)11:57 ID:tv4afNG+(1) AAS
みなさんスレッドセーフにしたいときはスレッドセーフになる様に書きましょう
535: ハノン ◆QZaw55cn4c 2021/10/10(日)12:13 ID:KKHdhYPj(1) AAS
>>522
11以前でも
536: 2021/10/10(日)12:21 ID:Ld3aFVRt(1) AAS
任意のスレッド安全性を実現するのはゼロコストでは不可能だから
必ずシングルスレッドで実行される保障がある場合などはあえてスレッド安全性を捨てることもある
537: 2021/10/10(日)12:31 ID:6/7jGiIK(1) AAS
std::conj() に double を渡したら std::complex<double> にキャストされるのが嫌なので、double を渡したら何もしないで double を返し、std::complex<double> を渡したら std::conj() と同じ動作をするオーバーロード関数 conj() を作ろうかと思うのですがアリですか？
なぜ std::conj() がそういう動作じゃないのか不思議で、何か見落としてたら教えてください
538(1): 2021/10/10(日)12:36 ID:2ZvzU42q(3/7) AAS
こここ・・こういうこと？
(A)キャプチャが必要でスコープ内で実行までされるケース
(B)キャプチャが必要でスコープ外まで実行が遅延されるケース
(B-1)ラムダ式生成時と実行スレッドが同じケース
(B-2)ラムダ式生成時と実行スレッドが違うケース
(A)なら全員「[&]で問題があるケースはない」と考えている
(B-1)は好みが別れているところ
(B-2)は好みが別れているところで、さらにキャプチャされる変数側をスレッドセーフにするかどうも好み
[&]と[=]がよく分からない人はコチラ
外部ﾘﾝｸ:ideone.com
省3
539: 2021/10/10(日)14:46 ID:lWUpu20f(4/8) AAS
>>528
日本語でおｋ
540(1): 2021/10/10(日)16:03 ID:lWUpu20f(5/8) AAS
>>538
おまえさんの論法では同時並行はすべて別プロセスにすべきってことだな
541: 2021/10/10(日)16:49 ID:2ZvzU42q(4/7) AAS
>>540
う〜ん、伝わらないですね・・・
共有リソースに競合するアクセスがなければ排他制御の必要がなく、スレッドセーフにする必要がないってことです
そもそもコピーして共有しないことで排他制御が必要なくなれば、スレッドセーフにしなくていいという考え方ですよ
542(1): 2021/10/10(日)16:51 ID:lWUpu20f(6/8) AAS
だから共有＝リスクなんだろ？
もうマシンも別の実機にすれば最強防御じゃん
543(1): 2021/10/10(日)17:01 ID:2ZvzU42q(5/7) AAS
>>542
残念ですが理解してもらうことは諦めます
544: 2021/10/10(日)17:32 ID:qGt3mQky(7/7) AAS
>>533
頭の中がgdgdな人が話をgdgdにしようとしていまつね……
std::sort()の呼び出しと同じスコープが終わった後に
[](int a, int b)が呼び出されないということは、単にstd::sort()がreturnするまでにラムダ式を忘れてくれる作りだから（たまたま）担保されているだけであって、
[](int a, int b)のスコープが限定されるために担保されているわけではないし、
[](int a, int b)がラムダ式だから担保されているわけでもないの。
つまり、>>533は
>ラムダ式をスコープ外に持ち出すなんてレアケース（>>529）
の根拠に全くなっていないワケ
545: はちみつ餃子 ◆8X2XSCHEME 2021/10/10(日)17:47 ID:cCUvKLuJ(1) AAS
レアケースがどうこういったところでレアケースなら考えなくていいってわけでもない。
そんなの個別の事例ごとに考えるしかしょうがないだろう。
546(1): 2021/10/10(日)17:56 ID:lWUpu20f(7/8) AAS
>>543
無理筋の主張ってことがわかってもらえたならいいよ
547: 2021/10/10(日)18:04 ID:2ZvzU42q(6/7) AAS
>>546
無理筋ではありませんよ
スレッド以前から並列処理で共有される実行コンテキストを分けることは大昔からやられてきました
今更その手法自体を想像できない人に、こんなところで説明するのは困難なだけです
548(1): 2021/10/10(日)18:11 ID:lWUpu20f(8/8) AAS
おまえさんの言う「大昔」がどのくらいか知らんが
俺が若手の頃はRENT,REUSなんてやってたよ
549: 2021/10/10(日)18:25 ID:Euz3vWgQ(1) AAS
ラムダ式によって作られたオブジェクトがキャプチャされたオブジェクトより長生きする可能性があるならコピーキャプチャ
そうでなくともレジスタに乗ると思われるならコピーキャプチャ
そうでない場合に初めて参照キャプチャ
排他に関してはshared_ptr<mutex>とshared_ptr<なかみ>をメンバに持たせてコピー可能にしつつ、メンバ関数経由で排他制御するのが筋だと思う
RustのArc<Mutex<T>>パターンに影響されすぎかもしれないが……
いずれにせよキャプチャと排他制御の問題とは切り離して考えることができるし、そうすべき
550(1): 2021/10/10(日)21:19 ID:MbdCJRMe(2/2) AAS
ラムダ式関連でいうと参照とかコピーをデフォルトだけで指定したときも実際に使ったものの分しかクロージャオブジェクトのサイズに乗ってこないと思ってるんだけどヤバい？
551(1): 2021/10/10(日)23:42 ID:9PtWfEC6(1) AAS
>>550
むしろ他に何が乗ると思っているのか？
気になるなら生成コード見て確認すればいいだろうとも思うし。
552(1): 2021/10/10(日)23:58 ID:2ZvzU42q(7/7) AAS
>>548
大昔とは1990年頃の話です
COBOLなのか知りませんが、reentrantとreusableは今回の話と直接関係ありません
上下前次1-新書関写板覧索設栞歴
あと 450 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.040s