C++相談室 part136
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part135
https://mevius.5ch.net/test/read.cgi/tech/1522495206/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1509780815/
■長いソースを貼るときはここへ。■
http://codepad.org/
https://ideone.com/
[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
----- テンプレ ここまで -----
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured キャッシュは不意のアクセスに備える目的のやつだから
今誰もアクセスすなくなったからといって即開放（例： キャッシュラインをinvalidate）したら意味半減くね…？
というわけで、参照カウントの使用例としては不適切くね…？？
それはそうとして、
資源の開放タイミングをスマポに頼るのは負けというC言語スキー氏には概ね同意だが
プログラマーが後始末タイミングをどうしても決められないｼﾁｭは存在するからスマポは要る
GCのように、開放タイミングを決めるのが未来のプログラマーなケースがそれ >>95
いい突っ込みだ。
今の実装だと、最低限プライベートの全サイズは要るのか。
Javaとかどうしてんだろうな？
現実的な解としては、
privateフィールドについてはコンパイラが自動的にpimpl的に間接参照に切り替えだな。
どうせpimplにする気だったのなら速度的にも大差ない。
いずれにしても、今の時代、コンパイラに合わせてコードを書くのは間違いで、
人間に合わせてコンパイラが努力するのが正しい。 >>80
ワイはオッサンやで。 C++98 が出来る前から C も C++ も使ってるというか、
マイコンで BASIC とアセンブラが主流だった時代の人だで。
そのときは何にも疑問に思わなかったけど、
今どきのモダンな仕組みを知ってしまったら、
昔の牧歌的なリソース管理なんて本当にしたくねぇという気持ちなんだよ。
(かといって使い慣れたパラダイムから離れるのも面倒くさい。 オッサンなので。)
>>81-82
そこで unique_ptr を使うことに疑問を持つことが意味わからんのだが。
まさにそういう風に使うためのもんだし、
その例で unique_ptr への懐疑を説明されてももう俺には何にも言えねぇ。 >>101
参照されている間も消していいキャッシュなら参照カウント不要だけれども、そっちのほうが稀じゃね？ >>100
> 参照カウントを自前で書けばいいからshared_ptrはいらないって言ってるわけではないよね？
そういうわけではない。
ただ、参照カウントを自前で書いても大して苦労しないのも事実だが。
> 例えばキャッシュとか。
これはいい例に見えるが、実はちょっと違う。
まず、これは「生存期間にデータ依存性がある為、上位関数からではde.lete出来ない」例ではある。
ただ、実際にキャッシュを実装すると、
1. non_sharedのキャッシュの場合、要するにLRU判定で捨てるときにそのままdeleteすれば良いだけ。
2. shared_cacheの場合、例えばCPUのキャッシュのエミュレーションを行う場合、
書き込みで他CPUのキャッシュを無効化するとか、その手の上位側の制御が必ず必要で、
shared_ptrだけでサクッと実装、ってことにはならない。
だから、Cで実装してもC++のスマポで実装しても、実は手間があまり変わらない。
それではおいしくないんだよ。
勿論、「書き込み無し」とかだと、破棄の制御をしなくていい分C++の方が楽に実装出来るが。
つまるところ、shared_ptrは、
手抜きデタラメ実装する場合は凄く便利だが、ガチで実装する場合にはあまり恩恵がないんだ。
とりあえず、キャッシュの場合はそう。
ってのが>>101の意見でもあると思うが。 >>104
キャッシュは、存在すればアクセスのレイテンシーが短縮されるというラッキーをクライアントに提供するだけのしくみ
よって、キャッシュ上のデータというのは基本いつ消してもシステムにとって致命傷にはならず、
かつ可能な限りキャッシュ上に残存するように普通は設計する
参照カウンタが0より大きいからキャッシュ上のデータを消してはいけないという法は無い
一方、仮に>>104で言いたいのがアクセスしている最中に消したらアカン、という話なのであれば、
それは排他制御の話題であってそれも参照カウントとは関係無く言える話やし… >>101
スマポは未来のプログラマーが解放することを「文法的に」示す意味しかない。
例えば、mallocも同様だが、
当然ナマポが返ってきて、それを解放するのは未来のプログラマー責任になっている。
要するに「そういう使い方」を規定すれば済むだけなんだよ。 unique_ptrが必要ないというのは、C++を使ったことがないってことだから、C++を使ってる人に対して、unique_ptrを使うべきでないと意見しても意味がない。
必要だから使ってるんだし。 >>103
俺はunique_ptrは「C的リソース管理を文法的に示す」意味しかないと見てる。
反対する意味もないが、積極的に使う意味もない。
元々そうとしか組めないし、既にコードはそうなってるから。
だからunique_ptrに書き換えろってのは、相当にウザイ。
他言語だとforeachをforに書き換えろとか、あれと同じじゃないかな。
たぶんLinusもこれなんだよ。
C++の奴は新しい文法でやることに意義を感じているようだが、
それによってソースコードの構造が改善されるかというと、全くそうじゃない。
むしろ、おかしくなることの方が多いわけでね。pimplとかもそうでしょ。
> 昔の牧歌的なリソース管理なんて本当にしたくねぇという気持ちなんだよ。
これがよく分からん。
というか俺はリソース管理したくないから当然のごとくGC言語を使っているわけで、
そこまでしてC++に拘る理由が分からん。
スマポ使えというなら、うるせえGC言語使え、と返したい。 Cより開発効率が高く、Javaよりユーザーにベネフィットを提供できる。
そういった観点から、広く使われるソフトウェアの開発にC++を採用するのは理にかなっている。
JavaにしろC#にしろ、GUIライブラリがころころ変わるのは、エンドユーザーが受け入れないからだろう。
そう、馬鹿なユーザーはJavaやC＃の利点を気にかけないのだ、自分のことしか考えない利己主義め！
なぜ重いソフトウェアを使うべきなのか、ユーザーをキチンと教育する必要がある。
あるいはC++を選ぶ。 >>107
>スマポは未来のプログラマーが解放することを「文法的に」示す意味しかない。
スマポでできて、free()ではできないことがあるからその言い分は違うくね？
いやまあ>>101でGCとしか言わなかったのは言葉足らずだったので今条件を追加するが、
こちらが実装上の都合で用意するオブジェクトの数と、未来のプログラマーに対して見せかけるオブジェクトの数が相違するケースでは
どうしてもスマポ的な手段に訴える（オブジェクト自身に開放タイミングを決めさせる）必要があるんじゃー！
例えば画像データみたいに巨大故に必要無い限りコピーしたくないんだけどそんな事情をライブラリ利用者から隠蔽したいケース
あるいは、やっぱGC自体が行う本来のガベージコレクション業務タイミングを決める方法とか、
（GCがシステムに1個しか無いのに対して、ユーザーは潜在的に多数でありGCの存在を関知せずに使ってくれる
一方、「必ずfree()せよ」という仕様には、malloc()したヒープ1個の開放以上の意味を持たせられない std::unique_ptrを使用したくない局面では、テンプレート仮引数Allocatorを用意するべきである。
つまり、ほとんどの場合、std::unique_ptrが有用である。 >>111
> 例えば画像データみたいに巨大故に必要無い限りコピーしたくないんだけどそんな事情をライブラリ利用者から隠蔽したいケース
なるほど理解した。
ここでshared_ptrを渡して多数に見せかけ、実は中身は一つ、という話か。
となると、当然インミュータブルでないと話にならないわけだが、
逆に言えば、今時のインミュータブルな世界にはshared_ptrが大活躍する余地があるのか？
すぐにはピンと来ないが。 >>113
△： 当然インミュータブルでないと話にならないわけだが、
○： 当然インミュータブルなインターフェースでないと話にならないわけだが、
実装は別にミュータブルでもクラスで覆うならやりようはいくらでもあるんじゃ…
画像の書き換えを専用メソッドでやるか、あるいは速度優先でcheckout/checkin式にcheckout中だけ直接アクセスを許すとか、
（もちろんcheckout時にコピーを行う
で、内部ではshared_ptr（的な、「オブジェクト自身に開放タイミングを決めさせる」）ロジックが大活躍！！１１１！！！！１！ >>111
いや待てよ、コピーオンライトなスマポがあればミュータブルな世界にも適用可能だが、
今の所、これはないよな？
いずれにしても適用事例はすぐには思いつかないが。 訂正；
×： あるいは速度優先でcheckout/checkin式にcheckout中だけ直接アクセスを許すとか、
○： あるいは書き換え速度優先でcheckout/checkin式にcheckout中だけ画像への直接アクセスによる書き換えを許すとか、 C++を解った気になった奴らがアンチパターンを量産する >>114,116
まあ分かった。
多分shared_ptrは『ほぼ』インミュータブルな世界とは相性がいい。
(ミュータブルにする必要がほぼなく、その場合は明示的に別メソッドを呼んでもいい場合）
つっても適用事例はWebサーバーくらいしか思いつかない。
ある画像が人気でユーザーが一斉にダウンロードしたとして、
鯖内部に30秒間だけキャッシュする場合とか。
ナマポで渡した場合、各ユーザーのダウンロード完了でカウントを減らし、０になるまで破棄出来ない。
shared_ptrで渡した場合、30秒の期限が過ぎればキャッシュから破棄しても問題ない。
この辺は確かに楽に組めるようになる。 >>118
キャッシュにstd::shared_ptrを使用するのは愚策すぎるのではないか。
実のところstd::shared_ptrはほとんど出番がない。
設計を練れば練るほど出番は失われていく。 いやすまんインミュータブルなインターフェースといいつつ>>114では画像を書き換えるインターフェースの話をしてしまったｽﾏﾝorz
「画像の書き換えを専用メソッドでやる」は、「加工後の画像を専用メソッドで生成する」、と読み替えてﾎｽｲ
で、ライブラリが画像Aを生成し、その画像がライブラリのユーザーによって不特定多数のクライアントとのセッションスレッドに渡されるｼﾁｭを考える
セッションスレッドの具体的な数は事前にはわからない。（接続してくるクライアント次第
また、何らかのタイミングでクライアントに提示すべき画像Aは、別の画像A'に差し変わる。
ライブラリのユーザーとしてはスレッド間の排他制御に関して面倒な問題を抱え込むのは嫌なので、
メインスレッド（セッションスレッドを起こす）から、画像Aのコピーを、所有権を譲渡する形でセッションスレッドに渡す、という使い方をする。・・・(1)
ライブラリ内部では、(1)の使い方をされるときにいちいち画像Aをコピーしたりしない。
画像Aの開放は、画像AがA'に差し変わるタイミングで行いたい。
ただし、画像Aを使っているセッションスレッドが居る間は開放するわけにはいかない。
しかし、当該スレッドがセッションを終えるのを待っていたら、新規につないで来るクライアントへの画像A'の提示が遅れる
→画像Aの開放タイミングはスマポで解決！ >>118
ちょっまだキャッシュ言いますかキャッシュと参照カウントは原理上無関係なので（>>106）忘れてよろしいかと、
（参照カウンタが0より大きいからキャッシュ上のデータを消してはいけないという法は無いし、
参照カウンタが0になったからといってキャッシュ上のデータを消さなければいけないという法も無い
Webサーバというのは適用事例として好適だがダウンロード中かダウンロード完了か、という区分でしか考えないのはｲｸﾅｲ
ダウンロード中にも新規のクライアントがつないでくるかもしれない
そのときダウンロード完了時に画像を破棄すればいいやという単色の思考だと、新規のクライアントが繋いで来つづける限り
画像を永久に開放できないことになり、そればかりか>>120のように、画像をAからA'に差し替えることもできない
これは画像Aの開放を、画像Aのオブジェクト自身に面倒をみさせるしかない（自身を参照するセッションスレッドが0になったとき開放させる
サーバはそれとは並行して画像A'を新規のセッションスレッドに展開できる。
こんな芸当ができるのはスマポだけ！ >>121
言いたいことは分かるが、
> 画像をAからA'に差し替えることもできない
これはない。
この場合はどのみちキャッシュを別実装するしかなく、
・キャッシュ内に画像Aへの参照が残っているか
・画像Aを掴んでいるセッションが存在しているか
が別問題になり、
画像の差し替えはキャッシュ内の画像Aを無効化することにより行われる。
だから、普通に差し替えは出来る。このとき、
それ以前のセッションは画像Aのまま、それ以降の新規セッションは画像A'になる。
ただまあ、これは本筋ではないし、内容見る限りそちらも分かっているようだからもういい。
多分、shared_ptrの使いどころは、
1. インミュータブルなインタフェースで、
2. 不特定多数がランダムに掴みに来て、
3. 解放タイミングがユーザー依存で読めない場合
なのだろう。アプリはWeb鯖はそうだが、それ以外に何があるかだな。
1,3はさておき、2がね。
少数しか来ないのならunique_ptrでいいし、
演算等CPUジョブなら結局は順に処理するだけなのでこちらもunique_ptrでいい。
I/O等の他要因で引っかかってスレッドが参照を掴んだまま待機させられることが必要になる。
ファイルサーバーも近いが、こちらの場合はロック機構が必要な為、
「どのファイルが今何人にどういった権限で捕まれているか」の管理が必要であり、該当しない。
（shared_ptrを使っても大して楽にはならない） 一応簡単に俺の主張を纏めておくと、
・unique_ptrは従来C方式を文法的に強制させるだけで、コードの改善には繋がらない。
・shared_ptrの使いどころはWebサーバーしか思いつかない。
GC言語は基本的にshared_ptrなわけだが、あれって基本的に手抜き専用で、
GCがないと本質的に辛いって構造はあんまりない。
Rustも今更GC無しですかー、とも思うが、実際、無しなら無しでもいいか、程度ではある。 >>123
その GC が大問題
現状 GC の最終手段は mark and sweep なので、これが嫌だ、という価値観はありだとおもう >>109
> 俺はunique_ptrは「C的リソース管理を文法的に示す」意味しかないと見てる。
その意味がすごく重要やん？
漠然としてたものに区別を与えてくれる最高の機能じゃんね。 >>95
期待して損した
そんな自殺コードを書かれるのを防ぐのは
スマポじゃなく人事部の仕事だ 「バカよけ」機能に価値はない、無駄だから使わないしコードが長くなるから使わせない
っていう老害いるよね
そういう奴に限ってバグや脆弱性作り込むんだけど決して反省しない std::unique_ptrを導入すると人事部から一人削減できるってことじゃないか。 >>128
まあ俺も老害とか言われることのある世代だが
価値がないのは「バカよけ」ではなく「バカ用」な
バカなふりをする達人をニヤリとさせるのではなく、
どうしようもない真性バカを延命する機能は有害なだけ >>127
期待するも何も、スタック巻き戻したらどうしてヒープ開放されると思ったのさ？ >>132
デストラクタが実行されるからさ
スタック巻戻しとは何たるかわかってる？ 混乱を避ける為に先に質問しておきたいんだが、
上記A(82)の場合、つまり、
親関数から子関数にポインタを渡したいが、所有権を移動しない場合には、どう書くんだ？
ざっと探しても出てこないんだが。
引数に値渡ししたらムーブ、これは分かる。
ムーブしたくないが子関数に渡したい場合は？ すまん、>>134はunique_ptrの場合。もう一度書き直すと、
親関数から子関数にunique_ptrを渡したいが、所有権を移動しない場合には、どう書くんだ？ >>124
それはありだ。
ただし、俺は「循環参照の場合に回収出来ないGC」であってもいいと思っている。
循環参照が必要なケースはほぼ無いので、明示的に切ってから解放でいい。
これはweak_ptrと同じで、C++erなら同意してもらえると思う。
ついでにいうと、「コンパクションが出来ないGC」でもいい。
これなら**ptrにする必要なく、*ptrで行けるから速度低下も起きない。
つまり、仕様はC++どおりでいいが、
プログラマにやらせるな、自動でやれ、ということ。俺的には。 >>135
なんだよ！所有権の複製もできないのかよ！？
やっぱりstd::unique_ptrダメじゃん！！！！ >>137
まあそのネタはさておき、マジで探しているのだが出てこない。
知ってたら教えてくれよ。
これ、もしかしてget()してナマポ渡すしかないとかいうオチ？
ならunique_ptrなんてマジでゴミだぞ。
さすがにそれはないと信じて探しているのだが、マジで出てこない。 >>138
参照で渡せばいいんじゃないのか？
そんなことして何の意味があるのか知らんが。 std::unique_ptrに対するweak_ptrは無いぞ。
だからゴミだという場合は、>>137。 >>139
俺も最初はそうかと思っていたんだが、実はそれも出てこないんだよね。
まあでもそれで、コンパイラが最適化をするのを期待する、というC++的オチか？
これはあり得るとは思うが。 >>141
当たり前すぎて出てこないだけでは？
auto result = my_func(*my_unique_);
とすればいいだけなんじゃないの？ std::unique_ptrを利用する主な動機は総称型を保持するためなんだよな。 >>140
そういう意味ではないが、
> std::unique_ptrに対するweak_ptrは無いぞ。
この表現は分かりやすい。
>>142
それは実体を値渡ししてしまうだろ。 >>144
lvalue_referenceだから仮引数側でどうにでもできるだろ。 参照だけするスマポ（と言いつつ何もしないアホの子スマポ）は次の規格で検討されてたでしょ
observer_ptrだかexempt_ptrだか名前コロコロ変わってるけど >>146
だから違うっての
>>147
多分俺が欲しいのはそれだ。
https://en.cppreference.com/w/cpp/experimental/observer_ptr
要するに、「ナマポだがdelete出来ない物」が欲しい。
unique_ptrは値渡しすると所有権が移動してしまう。
関数にはポインタの場合値渡しが最速だし、自明だから、グダグダ書いて最適化を待つ、とかやりたくない。
生成は常にunique_ptrからの値コピー（所有権は移動しない）でいい。
寿命管理は他に任せるが、ナマポと完全に同パフォーマンスの物、これが欲しい。
まあ、検討中ならよかった。 deleteされたくないポインタと言えばこうだろ。
https://ideone.com/PvzDVY >>125
> 漠然としてたものに区別を与えてくれる最高の機能じゃんね。
俺の理解が正しければ、これはダウト。表現力が足りない。
今のunique_ptrはB用のインタフェースしか持っておらず、Aを最速では記述出来ない。
足りてないのは、既に言ったとおり、「ナマポと同速だがdelete出来ないスマポ」。
だからやっぱイマイチなんだな。
とはいえ確実に拡充されてるから、最終的にどうなるかは見物だが。
高位機能も最終的には追いつくだろうし。
ただ、C++はプログラマの努力で何とかしようとしているが、
そもそもＡにしてもBにしてもコールグラフの解析でfree忘れとか抜けるはずなんだよね。
Cの連中はこの辺には興味ないみたいだけど、
人手でやってる分、スマポみたいにコーナーぎりぎりを攻められないから、
ある程度わかりやすいところでfreeされてる。
当然、ツールにもかかり易いはずで。 それ参照でいいだろ。
言ってる意味が全く分からない。 私もはやく皆さんとお話したいのですが、内容が全くわかりません。
C++でRPG作れる程度の知識なのですが、何から学べば良いでしょうか。
おすすめの本、サイトがあれば教えてくださいが >>152
それならば
effective C++ / effective modern C++ がいいかと思います そりゃC++使ってる人が読んだって全く分からないだろうな。 >>122
>1. インミュータブルなインタフェースで、
>2. 不特定多数がランダムに掴みに来て、
>3. 解放タイミングがユーザー依存で読めない場合
ちゃうねんそれでは表層的な観察にすぎなず、
shared_ptr（的な、「オブジェクト自身に開放タイミングを決めさせる」(>>114)）処理の必要性の1断面でしかないねん
>>121-122が言っているのは、
>こちらが実装上の都合で用意するオブジェクトの数と、未来のプログラマーに対して見せかけるオブジェクトの数が相違するケース(>>111)
において、未来のプログラマー（ユーザー）がオブジェクトをコピーしたつもりだが実装の内部ではコピーしていなくって、
ユーザー視点では自身のプログラムが保持する独立した1オブジェクトを開放したつもりが、実は内部の実装の都合において、
ユーザーまたはユーザー2のプログラムが保持する別のオブジェクトの開放と関係を持ってしまうケース（∵実体が同一）において
shared_ptr的な、「オブジェクト自身に開放タイミングを決めさせる」(>>114)）処理が必要ということなんじゃー .>>122
>画像の差し替えはキャッシュ内の画像Aを無効化することにより行われる。
これは>>121のケースでは問題の解決にならない。
なぜなら、仮にキャッシュ上に画像Aを用意してあり、最後まで画像Aを掴むことになったセッションXに対して
セッション開始時にメインスレッドが渡したのがキャッシュ上の画像Aだったとしても、
渡した瞬間にセッションとキャッシュの関係は切れるからじゃわ！（半切れ
>>121は、セッションXは自身のローカル記憶（のつもり）であるところのオンメモリの画像Aを使い、
セッション終了時に開放する、ということしか言っておらず、
セッション中に2回3回とキャッシュ上の画像Aを取りにいくとは書いては
いない
キャッシュとセッションXの関係がセッション開始時の一瞬でしかない想定な以上、
画像Aの実体の開放に関してキャッシュの無効化機構をどう別実装しても無駄。問題に影響無し。 ちな「キャッシュの無効化機構」とは、新規セッションに見せかける画像をAで無くすしくみという意味であって（それ以外の読み方をせよというのは㍉）、
画像Aの実体の開放とは関係ありませんからぬ、
というわけで繰り返しになるが画像Aの実体の開放に関してキャッシュの無効化機構をどう別実装しても無駄で、
画像Aの実体の開放はshared_ptr的な、「オブジェクト自身に開放タイミングを決めさせる」(>>114)）処理の専任事項となる
（>>121の想定のように画像Aが複数に見えることもあるが実体は唯一、というときはそうする以外画像のAからA'への差し替えは㍉ >>155-157
まず、俺の意図が正確に君に伝わっていることは分かった。
が、Webサーバーなんてそんなもんだろ。(…α)
画像『ファイル』Aを鯖からダウンロードしている最中に、鯖上で画像『ファイル』がA'に変更されたとしても、
ユーザーは画像Aをダウンロードし続ける。
それどころか、鯖は更新された画像A'に即座に対応することすら期待されていない。
2-3分の遅延なら許容されている。
この仕様においては鯖上のオンメモリキャッシュとファイルの同期は厳密にとる必要はなく、
俺の示した実装の通りであり、それは君にも正しく伝わっている。
この場合はshared_ptrでの実装の方が楽だ。(ただし厳密には問題があるが）
一方、ファイルサーバーはそうではない。(…β)
Webサーバほどの多人数が同じファイルを同時に掴みに来ることはほぼ無いが、
「どのファイルが今誰にどういった権限で捕まれているか」を完全把握しなければならず、
ファイルの更新、ファイルロックのリリースも即座に対応することが期待されている。
許容されるのは精々数秒でしかない。
この場合は上位の制御が必ず必要になり、shared_ptrが有ったところで大して恩恵はない。
違いは単純で、「厳密な同期が必要とされているか」だ。
だからもし、君がMMORPGのような多セッションでの
鯖上『オンメモリ』画像AからA'への切り替えを想定していたとしても、(…γ)
それはshared_ptrでの実装では楽にはならない。
画像A->A'への切り替えを同期させるなら、「誰が画像Aを掴んだままか」を鯖側が把握せねばならず、
上位の制御が必ず必要になる。shared_ptrを配って終わり、にはならない。
これは結局、Web鯖上の『ファイル』に対するキャッシュ条件がユルユルだから発生した特殊事例であり、
俺が言ったとおり、
> 手抜きデタラメ実装する場合は凄く便利だが、ガチで実装する場合にはあまり恩恵がない (105)
でしかない。
勿論それが許容されている世界であり、スループットを取っているだけだからそれでいいんだが。 が、とにかく君は、
> オブジェクト自身に開放タイミングを決めさせる
事が必要だと思っているらしい。これの他具体例はあるか？
君が挙げてきた別例はGCだが、現実問題として、ほぼunique_ptrで事足りるのも事実だろ。
shared_ptrは機能的にはunique_ptrの上位互換だから、GCではそれが用いられているだけであって。
「ナマポ禁止、スマポ使え」なC++宣教師は、
次は「漢ならunique_ptr。shared_ptrは甘え」と言うと思うぜ。
それともあれか？smalltalk的OOP或いはアクターモデル的に
> オブジェクト自身に開放タイミングを決めさせる
ってのか？だったらもうそれは流行らない、というか、
今のところ無駄が多すぎて普通に組んだ方がマシ、ってことになってる。 「delete忘れないようにunique_ptr使いましょーね」「共有が必要ならshared_ptrがべんりだよー」
っていうだけの話の何がそんなに気に食わないのかさっぱりわからなくてついていけない >>164
Q. 俺には必要性が分からない
A. 必要がないなら無理に使わなくていいよ
で済むお話。 >>164
俺は何言ってるか分かったけど、この人に説明するのは無理だろな。
使ったことがないものを批判したい感じだし、std:unique_ptrは必要になってから使えば良いよと言ってあげれば良いのかも。 まずムーブを活用して、総称性が必要になってから初めてunique_ptrを検討する感じがいいんじゃないのかな。
そしてshared_ptrは設計に時間をかけられないときに使うもので、ほとんど出番がないはず。 20世紀最大の発明はレーザーと言われてるけど、21世紀最大の発明はムーブと言われてるからね。
俺に。 なるべく (ポインタでなく) 値でやりとりすること、それを低コストで出来るようにムーブ対応にしておくというのは
上位レイヤを作るときに楽できる良い設計だとは思うけど、
実質的にはスマートポインタの機能をクラスに付け加えてるみたいなもんで、
それがクソ面倒くせえときに標準のスマートポインタを使うみたいな方針でやってた。
総称性を活用するときという観点は無かったけど、確かに必要な考え方だな。 unique_ptrで内蔵しておけばnoexceptにしやすいので、ムーブが使われやすくなるというのはありますね。
とまあ、C++を使っていれば自然に有効利用するものですが、使う前に理解するのは難しいのではないでしょうか。
使ってみればなるほどとなると思うんですよね。 机上の空論繰り返すより、使ってみればすぐわかるよ。
これがおじさんからのアドバイス。 https://ja.wikipedia.org/wiki/%E7%B7%8F%E7%A7%B0%E5%9E%8B
総称型（generic type）、あるいはパラメタ付型（parametric type）とは、
型付けされたプログラミング言語においてデータ型の定義と
それを参照する式（型式）の一部にパラメタを許すことによって
類似した構造を持つ複数のデータ型を一括して定義して、
それらを選択利用する仕組みである。
総称型は、暗黙の型変換（implicit type conversion）あるいは型強制（type coercion）、
多重定義あるいはオーバーロード（overload）、継承（inheritance）あるいは包含（inclusion）と並んで
プログラミング言語においてポリモーフィズムを実現するための一つの手段であると看做せる。
総称型が使われている言語の例としてC++のテンプレート、JavaやC#のジェネリクスがある。
へー 総称型の説明は要らんよ
欲しいのは総称性って言う謎の言葉の方 個々のクラスの実装を工夫して値渡しとムーブで解決できないかをまず考えて、
複数の型について類似のコードが出てくるようなら unique_ptr や shared_ptr (や自作スマートポインターテンプレートクラス) の利用を検討する、
というようなことでは。 >>178
そりゃ誰も説明できないから謎でしかないわ w なんかそれっぽく言っとけば暗黙の内にマウント取れるから 「オマエ知らないんだ～」「でも教えてやらなーい」ってのは
元手ゼロでもできる安上がりなマウンティング >>158
>この場合は上位の制御が必ず必要になり、std::shared_ptrが有ったところで大して恩恵はない。
この言い分はずんねんながら成立しない
「プログラム、呼び出されなければただのデータ」という諺（今漏れが作った）からわかるとおり、
画像Aや画像A'のいかに巧妙な中央集権的なリソース管理のロジックを組んだところで、
画像Aや画像A'の開放タイミングで呼び出されなければ機能しない
で、この呼び出しというのは、std::shared_ptr<画像>で極めて確実に（呼び忘れが無い形で）行うことが出来る
すわなち、画像Aのデストラクタで目的の中央集権コードを呼び出せば（注1）良い
よって、C言語スキー野郎（敬称略）がいうところの「std::shared_ptrの恩恵が少ない」例は、
そのまんま「std::shared_ptrを使えばより良い実装になる」例である
注1: ここでの呼び出しとは、実行権を渡すことを意味する。
直接CALL、メッセージの送付、レジスタにパラメータを積んでソフトウェア割り込み、
インスタンス固有の管理テーブルに情報をセットしてイベントで待ち解除、（同）タスク起床、etc.etc...
原液PGならやり方を100万通りぐらい即答できるはず 通知メカニズムを持つ画像より、通知メカニズムを持つリソースハンドルのほうが便利に違いないので、あまり使いどころがなさそう。 >>187
リソースハンドルは味噌も糞も一緒のHANDLE型で型安全の観点から不安があるが
画像クラスでwrapすれば型安全になる
行いが良ければ空も飛べるはず >>188
禿4はSTLコンテナの類もリソースハンドルと呼んでるけどな。
std::shared_ptrに通知メカニズムをプラスしたようなものが実際に必要になるのではないだろうか。
オジサンはATL風の通知メカニズムを備えたコンテナを作りましたぞ。 リソースを共有するということは、通知もセットで必要になると思うんだよなあ。 >>170
お前、ﾜｯﾁｮｲ 81b3-8neNが一度もまともなことを言ってないのを理解出来ないのはヤバいぞ。
そもそもお前、>>125ってことは、observer_ptrの使いどころも理解してないだろ。 まだ標準にも入ってないもんなんか使ったこともないし知らんわ。 唐突にphoenix_shared_ptrとか言ってみる 解る人おるやろか
Lokiに始まるメタテンプレートプログラミング狂騒時代も15年以上昔か… >>192
そう言うだろうとは思っていた。
そしてそれが今の君の、またC++erの限界なのだと思う。
君は>>103によると、世代的に、
C言語の前にアセンブラをやった連中は誰一人としてポインタで躓くことはなかった事実を知っているだろ。
これは単純に、ポインタの意味は既に知っており、
単に、インデックスレジスタの使い方をポインタと命名したんですね、で済んだからだ。
俺は同様の見方でC++を見てる。
C++のスマポはCのナマポを「分類/命名」しただけで、「追加」してないから。
だから記述能力が足りないことにも気づく。
unique_ptr(ｷﾘｯなんてやってるC++erは馬鹿丸出しだ。
君らはそれがCへの回帰な事にも気づけてない。
そしてここにきてobserver_ptrを追加するのは、完全に敗北だ。
あれはA方式用に他ならないから。
とはいえ、良いトライであったとは思うよ。そして失敗した。
ただ、それを修正して来れている点は素晴らしいが。
shared_ptrも結局使いどころがないだろ。
アセンブラの件からも分かるように、「理解していること」と「書いていること」は別なんだ。
正しくCを使っている連中は、そのナマポがunique/shared/weak/observerのどれなのかは明確に意識してる。
ただそれを書いてないだけだ。だから馬鹿には使っていないようにしか見えない。
君はobserver_ptrを知らないし、教えてもらわないと必要性に気づけない。
そこまで落ちぶれているって事だよ。
少なくともアセンブラ→Cの時のように、概念は理解しているがその言語での名前を知らないだけ、ではない。
対して、Cの連中は既にobserver_ptrを使っている。(ただし書いてない）
ここら辺の違いが、linusが一貫してC++erに冷めている理由だろうよ。無知な馬鹿にしか見えないから。 >194
> 正しくCを使っている連中は、そのナマポがunique/shared/weak/observerのどれなのかは明確に意識してる。
> ただそれを書いてないだけだ。だから馬鹿には使っていないようにしか見えない。
ああ、馬鹿にはわかんないよ。
だから書いてくれっての。
人間は度し難いほど馬鹿なので、クソみたいな間違いをする。
意識していたとしても間違う。
知っていても何度でも間違う。
そんなの当たり前だろ？ で、おめぇは一流のC++erと自称したいのかい。
ほんとに糞な爺だわ。早く棺桶の中で寝ろ。この河童虫が >>195
まあ俺は書くこと自体には反対ではないんだが、
1. 足りないんだから書きようがない(observerが)
2. そもそも書くほどバリエーションがない
Cで使われているのはunique/observerで、shared/weakはほぼあり得ない。
制御が煩雑すぎてバグる。
だからこそsharedが生きる構造があればC++が勝ちきる可能性があったが、
shared撲滅みたいな今の風潮じゃあねぇ。
そして既に書いたが、大概は方式Ａだから、
ローカルのナマポはuniqueで、それ以外は全部observerでしかない。
わざわざ分けて書くほどバリエーションがないんだよ。
Cの連中は書くのが嫌なわけではなく、書く意味を見いださないのだと思うよ。
書いたところでコード構造が改善されるわけでもなく、速度が上がるわけでもない。
書かずともどうせＡ方式だし。 sharedはリファレンスカウンタがからんでくるからね ■ このスレッドは過去ログ倉庫に格納されています
