C++相談室 part136

2018/06/07(木) 23:40:12.36

次スレを立てる時は本文の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

2018/06/08(金) 00:54:25.36

2get

2018/06/08(金) 01:28:54.52

STLつかうと一気に実行ファイルサイズが10倍に?！

環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない

すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？

#include <stdafx.h>
後死ね。

言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。

---- テンプレここまで ----

**デフォルトの名無しさん** · 2018/06/08(金) 02:27:58.00

C++解ると豪語していた人が後日茂みで戉だらけの死体で発見される例が後を絶ちません
C++解るは何か宗教的禁忌の呪詛なのだと思います

2018/06/08(金) 06:48:58.71

青い鳥に「C++を完全に理解した」と語りかけると
もれなく狂人が群がってきて引き裂かれます

2018/06/08(金) 07:17:06.89

構文、ライブラリ、パラダイム毎のテクニック、イディオムの一部を覚えて解った気になるなはどの言語でも同じね

2018/06/08(金) 15:02:53.87

>>3
このテンプレ貼り付けるの面白いんか

2018/06/08(金) 17:51:21.81

C++を完全に理解するには40年の下積みが必要

2018/06/08(金) 19:54:55.67

C++77をやっと理解しました

2018/06/09(土) 15:22:59.44

c++11とか14とか17って何ですか？

2018/06/09(土) 15:30:37.98

ggrks

2018/06/09(土) 16:23:33.39

C++完全に理解したわ。

◆QZaw55cn4c (ﾜｯﾁｮｲ d360-EqDK) · 2018/06/09(土) 16:34:50.30

>>12
おお凄いですね！
初学者が手をつけるといい分野を教えてください

2018/06/09(土) 17:23:15.68

C++完全理解ってすげー
入門本ですら辞書の様に分厚いのに

2018/06/09(土) 17:26:24.12

覇王になれます

2018/06/09(土) 17:43:50.55

コンパイラの中の人や
規格票の中の人なんかね

2018/06/09(土) 17:49:33.99

C++界のラオウ

**デフォルトの名無しさん** · 2018/06/09(土) 18:49:15.24

>>12の家に江添が向かうぞー！

2018/06/09(土) 18:51:01.10

12による攻略本を待てば良いのか？

2018/06/09(土) 19:33:13.71

最近は規格を完全に満たしたコンパイラって存在するの？

2018/06/09(土) 19:46:23.57

C++11は結構「満を持して」って感じだったけど、その後14だ17だとアップデートサイクルが
短くなるならCfrontに回帰してもらった方がハッピーな気がしてきた。
今のC++で技術的にどのくらいしんどいのかはわからないけど、TypeScriptやBabelなんかの
JS界隈でうまくいってるエコシステムがうらやましい。

2018/06/09(土) 19:59:17.07

>>21
> JS界隈でうまくいってるエコシステムがうらやましい。
それはお前がJSを知らず、隣の芝が青く見えるだけ。
あれは完全に屋上架屋で糞だ。C++のノリで動くと思ったら大間違い。

2018/06/09(土) 20:08:13.77

ラムダとか型推論とか
やわらか言語のお遊びだと思ってたのにいまじゃこの有り様だよ

2018/06/09(土) 20:09:30.83

コンパイラを駆動するためのプログラミングと、実行可能形式を駆動するためのプログラミングを一度にできる、一粒で二度おいしい言語がC++である。
つまり、ビールとワインを混ぜたらとてもまずかったというお話。

2018/06/09(土) 20:11:55.73

>>22
？
TypeScriptもBabelも普通に使ってるけど？
それがうまくいってるのを見てるからこそC++もそうできたらいいと思ったんだが。
まぁ、コンパイルに時間がかかるのとデバッグがちょっと隔靴掻痒気味ってのはある。

2018/06/09(土) 20:19:03.73

>>21
つーかC++11って、みんなもう待ちくたびれて
C++0xという期限も守れなくて、
一部でC++オワコン？とか言い出してる雰囲気の中、
ああ、やっぱりあるのかという復活祭的なもんだったろ

2018/06/09(土) 20:19:57.28

>>25
C++にそれらがないのは、C++にはそれらが必要とされてないからだよ。
要するに全てはJavaScriptが糞すぎるから始まったことでしかない。
それがいいと思うのも自由だが。

2018/06/09(土) 20:22:20.01

>>27
何を言うか！
Javascriptが最強の完成された言語だからこそ、Typescriptが誕生できたんじゃないか！！！

2018/06/09(土) 20:23:02.20

金箔貼っても糞は糞

2018/06/09(土) 20:25:24.52

C++がこっち方向→に糞だとすると、Javascriptは←あっち方向に糞。

2018/06/09(土) 20:25:28.19

>>25
要するに、自分が慣れている環境を持ち込みたいだけだろ。
ならJavaScript流に言えば、お前が作れ、でしかないだろ。
ご自由にOSSにすればいい。誰も使わないと思うけど。

2018/06/09(土) 20:29:08.98

歯糞耳糞を笑うというが、本物のウンコには誰も勝てなかったというお話。

2018/06/09(土) 20:34:01.02

>>26
結構印象が違うもんだね。
C++03が失敗気味でオワコン視された雰囲気はわかるけど、だからこそ次は失敗できない
C++11はそれなりの完成度になったと思うんだが。逆に14や17は蛇足気味のような。

2018/06/09(土) 20:34:26.33

しかしJavascriptとC++を完全に理解した俺が最強ってことだろうな。

**デフォルトの名無しさん** · 2018/06/09(土) 20:49:52.86

同じ糞なら書かなきゃソンソン

◆QZaw55cn4c (ﾜｯﾁｮｲ d360-EqDK) · 2018/06/09(土) 20:54:24.20

>>33
＞C++03が失敗気味でオワコン
え…それは本当ですか？
C++03 で生きていこうと思っていたんですが…

2018/06/09(土) 21:28:50.56

>>33
いや14は重要なバグ直しでautoが安心して使えるようになったし
17はfilesystemやstring_viewにexecution（これすげー）が入って名実共にメジャー
やっぱC++03からの沈黙が異常すぎたんだよ

2018/06/09(土) 21:39:20.39

>>36
常に最新を使えとまでは思わんが、さすがに C++11 は人権だと思うぞ。

C++14 や C++17 はユーザ視点では重要なものも含まれるとは思うが、
C++11 に間に合わなかったりミスがあったりしたのを補った、
マイナーアップデートという印象は有るな。

◆QZaw55cn4c (ﾜｯﾁｮｲ d360-EqDK) · 2018/06/09(土) 21:48:34.35

>>38
スマートポインタの恩恵は享受しようと思いますが、右辺値参照はよく理解できません…

2018/06/09(土) 21:51:27.43

>>39
テンポラリ＝constと短絡されていたが
実はそうではなかった
禿すらも気付くのが遅れた
それが&&

2018/06/09(土) 21:52:38.94

キーワードclassは結局いらなかった
newは忌み子だった

禿がどういう方面で過ちを犯したか
何となく察することができるだろう

2018/06/09(土) 22:02:43.49

newで帰ってくるのがunique_ptrにならねえかなあ

2018/06/09(土) 22:05:12.82

>>39
えっ、それって重要な機能のひとつじゃね？

ライブラリは標準になくてもなんとかなるけど、
基礎的な機能で大事なトピックがてんこ盛りなのが C++11 でしょ。

最低でも

auto
decltype
constexpr
可変長引数テンプレート

あたりは無いとつらすぎるんですけど！

2018/06/09(土) 22:20:04.89

>>38
> 常に最新を使えとまでは思わんが、さすがに C++11 は人権だと思うぞ。
そりゃ人に依るだろ。今でもCは現役なんだし。

>>43
ちなみに他言語を使わない理由は何だ？
おそらく君はインラインアセンブラとか全く使わない人だろ？

2018/06/09(土) 22:26:37.24

C++17はDoxygenを凄いことにする。
ひどい奴だ。

2018/06/09(土) 22:30:21.93

std::unique_ptrはユニポと読むんだよな？

2018/06/09(土) 22:31:54.21

>>44
> ちなみに他言語を使わない理由は何だ？

Scheme スレが私の巣だと思ってるくらいには Scheme 派なんだけど、
話題が少なくて暇だからこっちに出てきてる感じ。

> おそらく君はインラインアセンブラとか全く使わない人だろ？

使わないに越したことは無いというのが基本姿勢ではあるけど、使う必要があるので使うよ。

どういう意図で言ってんのかよくわかんないんだけど、
C++11 以降に加わった機能がスゲー大事という気持ちとこれらが何か関係あるの？

2018/06/09(土) 22:44:45.79

人は皆生まれながらにC++が好きだけど、その気持ちに気づくかどうかに違いが出るんだよね。

**デフォルトの名無しさん** · 2018/06/09(土) 22:49:33.71

がしゃーん
　　　　　がしゃーん

　　　△ ￥ ▲
　　( Ｃ＋＋Ｃ )
　　(　　　　　)
　／│　肉　 │＼
＜　＼＿＿＿／　＞
　　　┃　　┃
　　　＝　　＝
C++17だよ
自動で Doxygenを凄いことにしてくれる
ひどいやつだよ

2018/06/09(土) 22:50:39.46

よく知らないのだけど、いったいC++17でDoxygenに何が起こるんだ・・・

2018/06/09(土) 23:00:19.02

>>47
俺はC++を使う利点は

・高位から低位まで同一言語でカバー出来る点

だと思っていて、逆に言えば、
高位でしか組まないのなら他高位言語を使った方がいいと思ってるんだよ。
だからC++の利点を生かす為には、

・高位の機能と低位の機能を混ぜて使う
　＝スマポもラムダもナマポもインラインアセンブラも『同時に』使う

事が必要で、逆に、このスレに巣くっているナマポ禁止な連中には若干懐疑的なんだよ。
それなら他言語の方が生産性が高いから。
必要ならその部分だけCのDLLにすれば済む話だし。

そして最近の新機能は高位向けの物が多いから、聞いてみたわけだ。
Schemeは知らんが、他高位言語を使っているのなら済まんかった。

2018/06/09(土) 23:16:26.11

>>51
高から低をカバーしてるのが良いというのは私もまったく同意見だよ。
だから、高から低をカバーと言っておきながら、高水準の部分は他言語に任せた方がいいというのはなんか矛盾してないか？

俺は「(現代の水準では) 足りてないからもっと (少なくとも C++11 で追加された分くらいは) 欲しいよな」って気持ちなわけ。

2018/06/09(土) 23:38:56.87

>>52
矛盾してない。

高水準の部分はC++は他言語に対して後れているから、
C++がそれを追加するのは妥当ではある。

ただ、俺なら他言語で組んで、CのDLLを呼ぶようにする。
それだと、他言語の進んでいる高水準機能を使えるから。
わざわざ遅れているC++に対して文句を言いながら使う意味がない。

例えば、C#がその作りになってるでしょ。
マーシャルがウザイか、C++の機能的周回遅れがウザイかってだけ。
勿論、インラインアセンブラを使いたいならC++しか解がない。
で、ナマポ禁止派はいったい何がしたいんだ？ってのが疑問で、
それだったら俺と同じでC#＋CのDLLで良いじゃん、と思うわけ。

2018/06/10(日) 00:22:20.01

C#やってるとテンプレート欲しくなるじゃん

2018/06/10(日) 00:27:04.31

ナマポが本当に必要な所では存分に使えばいいと思うよ
ただし普通は99.9%くらいはそうじゃないからスマポを使え

2018/06/10(日) 00:35:42.54

99.9%がスマポなら、最初からスマポがデフォの言語を使った方が捗るでしょ。
Rustでもいいし、C#やJava等のGC言語でもいいし、PythonやRubyのようなスクリプト言語でもいい。
残り0.1%をマーシャルなりしてCのDLLで。

2018/06/10(日) 00:42:34.12

話をぶった切ってすんません。

複数のスレッドで

thread_local int* p;

p=new int [1000];

で確保したヒープ領域はやっぱりスレッドセーフ、じゃない、データ競合が
おきるんですか？

2018/06/10(日) 00:59:52.96

>>53
まー、生ポインタは一箇所たりとも許さんってほどの原理主義は過激だとは思うよ。
俺も生ポインタを使わないことはないし、 goto を使うことだってあるし。

ただ、「低レイヤから高レイヤまでをひとつの言語の中で扱える」というのは
「高レイヤな機能で低レイヤを隠蔽可能だ」ということであって、
低レイヤを低レイヤのままで扱うスタイルを是とするものではない。
直接的な部分ではインラインアセンブラを使うことが有っても、
その上のレイヤに持ち上げるときには必ずスマートポインタを使えってくらいの主張なら真っ当だと思う。

C++ なんてそもそもがクソなんだから、
解決のために追加された機能は積極的に使わないとやっとれんわ。
(でも好き。)

2018/06/10(日) 01:03:04.42

>>57
起きないです。

2018/06/10(日) 01:06:27.33

>>57
thread_local で宣言した変数は名前が同じだけでスレッドごとに違う存在だし、
それぞれのスレッドで new したならそれぞれのスレッドで配列が確保されてる。

別のスレッドの p (やそれが指す先の配列) にアクセスすれば競合が起こることは有りうるが、そうじゃないんだよね？

2018/06/10(日) 01:11:48.03

>>59

ありがとうございます。これが本当ならホッとします。

でも、これって規格書に明確に記述されているのか、コンパイラがそういう仕様の
アセンブラコードを吐き出しているだけなのかわかりません。

データ競合がおきたら修羅場ですｗ

2018/06/10(日) 01:14:17.08

>>60

ありがとうございます。

>別のスレッドの p (やそれが指す先の配列) にアクセスすれば競合が起こることは有りうるが、そうじゃないんだよね？

それはないです。

2018/06/10(日) 01:21:34.27

>>61
明確です。
newで確保される領域はダイナミックストレージに属します。
これは他のスレッドと同時に読み書きを行えば競合します。

thread_localで確保されたint* pはスレッドストレージに属します。
これは複数のスレッドで別のページに属します。
従って、pに対して読み書きしている分には競合しません。

2018/06/10(日) 01:24:48.36

>>58
> 低レイヤを低レイヤのままで扱うスタイルを是とするものではない。
そう。で、俺は、低位はDLLで切り出しても大して問題なく、
高位だけなら他言語を使った方が効率的、という見方。

> その上のレイヤに持ち上げるときには必ずスマートポインタを使えってくらいの主張なら真っ当だと思う。
ちなみにそもそも俺はスマポ自体に懐疑的で、

・スマポじゃないとやってられないのはシャローコピーを永続化させるときくらいで、
　C++でこの使い方をすることはほぼない。
　（部分的シャローコピーでオブジェクト毎の生存期間に差が出て、
　さらにそれがデータ依存しており、プログラム側で確定させるのが面倒なとき。
　(半分満たす)例：このスレのレス配列があったとして、
　特定のIDのみ、ポップアップ用にシャローコピーで抜き出す場合。
　ただしこの場合はポップアップ後も次のポップアップ用に全体配列を保持する為、
　シャローコピーの永続化はせず、寿命管理は全体配列単位となり、スマポじゃなくても苦労しない。
　というより、正直、該当ケースを思いつけない）

なんだな。
要は、オブジェクトの生存期間をコード上で静的に確定させられないときにはスマポは強力だが、
俺には該当ケースがないんだな。
というか、お前ら何に使ってるんだ？
面倒なだけなら、GC言語の方が楽だしいいと思うんだが。

2018/06/10(日) 01:30:29.54

で結局ユニポでいいんだよな？

2018/06/10(日) 02:24:33.75

俺には分からない日本語をみんなが喋ってる

2018/06/10(日) 02:32:04.25

そんな柔な理解力ではこのC++の壁に傷一つ残すことはできんわ！

2018/06/10(日) 06:46:40.00

>>64
スマポ＝シャローコピーって意味わからん
unique_ptrを使わずにナマポでpimplとか今となっては考えられんのだが

2018/06/10(日) 08:41:18.45

>>50
DoxygenがC++17の新構文に対応してないだけでしょ
まだ仕様が確定してないから対応してないよってどっかに書いてあったような気がする

2018/06/10(日) 08:52:18.24

>>64
所有権を移転*しない*ということを表現できるのもスマートポインタの使い方のひとつだよ。

2018/06/10(日) 10:19:31.72

>>68
はぁ？？？
pimplてあんなもん生存期間がシンプルすぎて
スマートポインタなんか要らない例だろキチガイかお前

2018/06/10(日) 11:21:03.09

ナマポでもpimplはできるが
毎度毎度わかりきったコードを書く
無駄な手間がちょっとイヤ

2018/06/10(日) 11:29:19.92

pimplに限らないが、メンバーにunique_ptrを使ったときの空のデストラクタが悲しい。

2018/06/10(日) 12:03:34.83

JSはES6でｽｹﾞｰ良くなった希ガス
もはやC++やPerlみたいな工業用言語として十分逝ける

2018/06/10(日) 12:11:11.02

>>74
つ http://jsgirl.jp

2018/06/10(日) 12:43:11.84

URLから連想出来る署名は
IQ110のJS先輩と学ぶ関数型プログラミング14日間

2018/06/10(日) 12:48:50.28

工業用言語でperl w

2018/06/10(日) 13:10:58.73

何を以て「工業用」と言っているんだろう

2018/06/10(日) 13:26:42.87

>>71
生存期間がシンプルすぎるからunique_ptrが入らないっていうのは賛同できないわー。
将来デストラクタが複雑になって誰かがdeleteする経路をすっ飛ばしてreturnしてしまうかもしれんし、使えるところは使っておけばいいじゃない。
何を気にしてunique_ptrさけてるの？

2018/06/10(日) 13:28:20.49

>>70
それで何が嬉しいんだ？

ついでに質問しておこう。
君はCのような自前でリソース管理をしなければならない言語でリソース管理をしたことがあるか？

あと、これはC++er全般に対してだが、
shared_ptrが絶対に必要なケースってのは何だ？
unique_ptrで後述A,B以外の使い方Dがあるか？(なおCは予約語)

2018/06/10(日) 13:29:15.80

Cでのリソース管理戦略は非常に単純で、おそらく以下の２つしかない。

A. 作成者が責任を持って破棄する。
B. 投げ捨て。基本的に所有権を渡し、末端（付近）で破棄する。

Aが基本パターンになる。
Bは例えば描画用の一時データ等の場合で、
この場合、使用するのは「描画ルーチン『だけ』」であり、それ以降は不要だと自明だから、
・「描画ルーチン」までの途中経路での使用は原則禁止
　（厳密には、「描画ルーチン」呼び出し以降の使用は禁止で、
　呼び出し以前は改変等を加えてもいい＝この例なら、描画スケールの改変等）
・「描画ルーチン」内で必ず破棄
となる。
ただしあまり気にしないのならBも使わず、Aだけで組んでも問題ない。(というか多分そっちが主流か？)
描画の例であれば、描画終了後は普通はかなり速やかに親関数まで帰ってくるので、
親関数側でfreeするA方式でも大差ないからだ。

対して、OOP的に実装した場合、例えばゲームの敵キャラの生成/消滅を管理するとして、
この場合は「描画ルーチン」のように
「静的に明示的に生成/消滅の両方を内包する親関数」が規定出来ないので、
A方式は事実上使えず、Bで対応するしかない。だから上記を書き直せば、以下となる。

A. 「作成/使用の両方を静的に管理下に持つ親関数」を規定出来る場合、（＝構造化プログラミング）
　その親関数内で確保し、親関数のスコープ終了と共に破棄する。
B. 上記親関数を規定出来ず、「作成」「使用」場所が明示的な場合、（＝OOP）
　「作成」後は基本的に所有権を譲渡し、「使用」後に破棄する。

2018/06/10(日) 13:29:42.93

既に言ったように、Cの戦略は多分この２つだ。というか、正確に言うと、これ以外での管理は無理だ。
そしてこれはC++では以下のようになる。

A. 自動変数上のunique_ptrに確保、関数呼び出しでは所有権の移転はしない
　＝生成場所のスコープ終了と共に破棄、それ以外の破棄はない
B. unique_ptrに確保し、自関数を抜ける前に『必ず』誰かに所有権を移転する
　自関数が対象関数（上記例なら描画関数）であれば、移転相手がいないので破棄する

だからはっきり言えば、Cのナマポは事実上C++のunique_ptrの使い方しか出来ないし、してない。
C++erがスマポ(ｷﾘｯなのは、上記C流のリソース管理を知らない＝無知だからでしかない。
繰り返すが、Cは最初からunique_ptrしかないのと等しい。
ここがC->C++の連中と、C++しか知らない馬鹿との違いだ。

これに対して、shared_ptrは上記制限を解除するものだ。
だからshared_ptrを使えば新しいプログラミングパラダイムを発見出来る可能性はある。
これは何だ？
俺にはこれがイマイチ思いつかない。

いわゆる構造化プログラミングで、関数を入れ子で呼んでいく場合、必ずAは適用可能だ。
これがCが今までのさばっている理由でもある。
OOP的に組む場合はBが基本戦略となり、必ず誰かが明示的に「生成」し、
同様に、必ず誰かが明示的に「破棄」するので、これまた問題ない。

だから今のところCで間に合っているのも事実だ。
リソース管理が「面倒だ」というのは分かるとしても、
「難しい」というのは根本的に組み方を間違っているからだ。
GC言語しか知らない馬鹿共が知らないのは当たり前だとしても。

shared_ptr等が必要なプログラミングパラダイムが発見され、
それに対応する方法がなければ、お前らの望み通り、Cも死ぬしかない。何かないのか？
或いは上記A,B以外のunique_ptrの使い方Dがあるか？(なおCは予約語)

2018/06/10(日) 13:30:26.90

例外安全性の確保でウッカリさんするくらいなら使った方が良い。

2018/06/10(日) 13:33:28.96

>>79
誰かがdeleteする経路をすっ飛ばしてreturnってどゆこと？
スタック巻戻しを破綻させるものってstd::exitくらいじゃね

2018/06/10(日) 13:34:40.25

>>80
>それで何が嬉しいんだ？
お前さんが大好きなC言語の関数にポインタを渡す場合

2018/06/10(日) 13:35:21.57

>>68,79
そもそもpimpl自体が要らんだろ。
あれはC++のコンパイラが単純に仕様変更

・ヘッダにはprivate関数は書く必要がありません

すればいいだけの話で、そもそも「名前空間は開いていますが、クラスは閉じています(ｷﾘｯ」を、
「ヘッダのクラスは開いていますが、実装のクラスは閉じています(ｷﾘｯ」にすればいいだけ。

編集上の都合でソースが汚れるとか、全く馬鹿な話だろ。
気づけよ。

2018/06/10(日) 13:35:48.50

>>84
コンストラクタ内で例外発生とか
？

a (ﾜｯﾁｮｲ f36d-ExzQ) · 2018/06/10(日) 13:37:37.76

http://somn9.xyz/4

2018/06/10(日) 13:37:46.22

pimplに近いテクニックとしてC言語の頃から絶縁テクニックというものがあるが
それをやると大概静的解析ツールが横暴な量の警告メッセージを吐いてきやがるので却下
pimplも多分同じ結果に…

2018/06/10(日) 13:39:41.44

Javascriptを使って感じるC++の有利な点は仕様の明確さだろう。
Javaは重いと言われユーザーに嫌われる言語のひとつだが、開発者はベンチマークを提示しC++の20倍速いと言う。
しかしユーザーは実際に重くて困っているだろう。
ブラウザも同じ問題を抱えていて、当然Javascriptも重いとユーザーは感じている。

2018/06/10(日) 13:45:01.51

Microsoft社はソフトウェアの使用状況を監視させてほしいとユーザーにお願いする。
IMEの誤変換データや、プログラムのクラッシュ時の情報などだ。
これらは、開発者とユーザーの間の意識の乖離を埋める可能性がある。
ユーザーの重いと開発者の軽いのような。
オープンソースに対するアドバンテージがここにあるのかもしれない。

2018/06/10(日) 13:45:20.24

>>90
慣れたらJQueryなど使わずとも複数プラットフォーム対応逝ける！

2018/06/10(日) 13:46:17.65

>>91
Microsoftはつい先日GitHubを買収したから
ソースコード自体を監視に乗り出すようや

2018/06/10(日) 13:49:25.02

Visual StudioはCMakeに対応したし、Microsoft社はオープンソースとの付き合い方をやっと学んだようだ。

2018/06/10(日) 13:54:11.99

>>84
たいしたこといってないです。
~dtor() {
. if (...) {
. return;
. }
. delete ptr;
}

>>86
pmplがバッドノウハウに属するものであることは同意だけどprivateメンバ変数はどうするつもり？

2018/06/10(日) 13:54:17.23

pimplを多用するライブラリの一つにQtがある。
C++はテンプレートによって拡張性を担保できる言語だ。
一方、拡張性はライブラリのユーザーにとってわかりやすさを損なう。
IDEとの結合において、pimplによる公開は一つのテクニックかもしれない。

2018/06/10(日) 13:55:31.45

ところでpimplってぽいんぷるって読むんだよな？

2018/06/10(日) 13:59:01.60

ピーいんぷるって呼んでた

2018/06/10(日) 14:01:14.71

RAIIは？

2018/06/10(日) 14:03:24.78

>>82
cで参照カウント使ってる例なんていくらでもあると思うけど。例えばキャッシュとか。
参照カウントを自前で書けばいいからshared_ptrはいらないって言ってるわけではないよね？

2018/06/10(日) 14:25:32.87

キャッシュは不意のアクセスに備える目的のやつだから
今誰もアクセスすなくなったからといって即開放（例：キャッシュラインをinvalidate）したら意味半減くね…？
というわけで、参照カウントの使用例としては不適切くね…？？

それはそうとして、
資源の開放タイミングをスマポに頼るのは負けというC言語スキー氏には概ね同意だが
プログラマーが後始末タイミングをどうしても決められないｼﾁｭは存在するからスマポは要る
GCのように、開放タイミングを決めるのが未来のプログラマーなケースがそれ

2018/06/10(日) 14:32:47.18

>>95
いい突っ込みだ。
今の実装だと、最低限プライベートの全サイズは要るのか。
Javaとかどうしてんだろうな？

現実的な解としては、
privateフィールドについてはコンパイラが自動的にpimpl的に間接参照に切り替えだな。
どうせpimplにする気だったのなら速度的にも大差ない。

いずれにしても、今の時代、コンパイラに合わせてコードを書くのは間違いで、
人間に合わせてコンパイラが努力するのが正しい。

2018/06/10(日) 14:34:08.96

>>80
ワイはオッサンやで。 C++98 が出来る前から C も C++ も使ってるというか、
マイコンで BASIC とアセンブラが主流だった時代の人だで。

そのときは何にも疑問に思わなかったけど、
今どきのモダンな仕組みを知ってしまったら、
昔の牧歌的なリソース管理なんて本当にしたくねぇという気持ちなんだよ。
(かといって使い慣れたパラダイムから離れるのも面倒くさい。オッサンなので。)

>>81-82
そこで unique_ptr を使うことに疑問を持つことが意味わからんのだが。
まさにそういう風に使うためのもんだし、
その例で unique_ptr への懐疑を説明されてももう俺には何にも言えねぇ。

2018/06/10(日) 14:36:19.12

>>101
参照されている間も消していいキャッシュなら参照カウント不要だけれども、そっちのほうが稀じゃね？

2018/06/10(日) 14:45:42.60

>>100
> 参照カウントを自前で書けばいいからshared_ptrはいらないって言ってるわけではないよね？
そういうわけではない。
ただ、参照カウントを自前で書いても大して苦労しないのも事実だが。

> 例えばキャッシュとか。
これはいい例に見えるが、実はちょっと違う。

まず、これは「生存期間にデータ依存性がある為、上位関数からではde.lete出来ない」例ではある。
ただ、実際にキャッシュを実装すると、

1. non_sharedのキャッシュの場合、要するにLRU判定で捨てるときにそのままdeleteすれば良いだけ。
2. shared_cacheの場合、例えばCPUのキャッシュのエミュレーションを行う場合、
　書き込みで他CPUのキャッシュを無効化するとか、その手の上位側の制御が必ず必要で、
shared_ptrだけでサクッと実装、ってことにはならない。

だから、Cで実装してもC++のスマポで実装しても、実は手間があまり変わらない。
それではおいしくないんだよ。
勿論、「書き込み無し」とかだと、破棄の制御をしなくていい分C++の方が楽に実装出来るが。
つまるところ、shared_ptrは、
手抜きデタラメ実装する場合は凄く便利だが、ガチで実装する場合にはあまり恩恵がないんだ。
とりあえず、キャッシュの場合はそう。

ってのが>>101の意見でもあると思うが。

2018/06/10(日) 14:47:27.38

>>104
キャッシュは、存在すればアクセスのレイテンシーが短縮されるというラッキーをクライアントに提供するだけのしくみ
よって、キャッシュ上のデータというのは基本いつ消してもシステムにとって致命傷にはならず、
かつ可能な限りキャッシュ上に残存するように普通は設計する
参照カウンタが0より大きいからキャッシュ上のデータを消してはいけないという法は無い

一方、仮に>>104で言いたいのがアクセスしている最中に消したらアカン、という話なのであれば、
それは排他制御の話題であってそれも参照カウントとは関係無く言える話やし…

2018/06/10(日) 14:48:15.03

>>101
スマポは未来のプログラマーが解放することを「文法的に」示す意味しかない。

例えば、mallocも同様だが、
当然ナマポが返ってきて、それを解放するのは未来のプログラマー責任になっている。
要するに「そういう使い方」を規定すれば済むだけなんだよ。

2018/06/10(日) 14:56:39.55

unique_ptrが必要ないというのは、C++を使ったことがないってことだから、C++を使ってる人に対して、unique_ptrを使うべきでないと意見しても意味がない。
必要だから使ってるんだし。

2018/06/10(日) 15:01:32.09

>>103
俺はunique_ptrは「C的リソース管理を文法的に示す」意味しかないと見てる。

反対する意味もないが、積極的に使う意味もない。
元々そうとしか組めないし、既にコードはそうなってるから。
だからunique_ptrに書き換えろってのは、相当にウザイ。
他言語だとforeachをforに書き換えろとか、あれと同じじゃないかな。

たぶんLinusもこれなんだよ。
C++の奴は新しい文法でやることに意義を感じているようだが、
それによってソースコードの構造が改善されるかというと、全くそうじゃない。
むしろ、おかしくなることの方が多いわけでね。pimplとかもそうでしょ。

> 昔の牧歌的なリソース管理なんて本当にしたくねぇという気持ちなんだよ。
これがよく分からん。
というか俺はリソース管理したくないから当然のごとくGC言語を使っているわけで、
そこまでしてC++に拘る理由が分からん。
スマポ使えというなら、うるせえGC言語使え、と返したい。

2018/06/10(日) 15:08:27.48

Cより開発効率が高く、Javaよりユーザーにベネフィットを提供できる。
そういった観点から、広く使われるソフトウェアの開発にC++を採用するのは理にかなっている。
JavaにしろC#にしろ、GUIライブラリがころころ変わるのは、エンドユーザーが受け入れないからだろう。
そう、馬鹿なユーザーはJavaやC＃の利点を気にかけないのだ、自分のことしか考えない利己主義め！
なぜ重いソフトウェアを使うべきなのか、ユーザーをキチンと教育する必要がある。
あるいはC++を選ぶ。

2018/06/10(日) 15:19:42.39

>>107
>スマポは未来のプログラマーが解放することを「文法的に」示す意味しかない。
スマポでできて、free()ではできないことがあるからその言い分は違うくね？
いやまあ>>101でGCとしか言わなかったのは言葉足らずだったので今条件を追加するが、
こちらが実装上の都合で用意するオブジェクトの数と、未来のプログラマーに対して見せかけるオブジェクトの数が相違するケースでは
どうしてもスマポ的な手段に訴える（オブジェクト自身に開放タイミングを決めさせる）必要があるんじゃー！

例えば画像データみたいに巨大故に必要無い限りコピーしたくないんだけどそんな事情をライブラリ利用者から隠蔽したいケース
あるいは、やっぱGC自体が行う本来のガベージコレクション業務タイミングを決める方法とか、
（GCがシステムに1個しか無いのに対して、ユーザーは潜在的に多数でありGCの存在を関知せずに使ってくれる

一方、「必ずfree()せよ」という仕様には、malloc()したヒープ1個の開放以上の意味を持たせられない

2018/06/10(日) 15:24:27.83

std::unique_ptrを使用したくない局面では、テンプレート仮引数Allocatorを用意するべきである。
つまり、ほとんどの場合、std::unique_ptrが有用である。

2018/06/10(日) 15:28:05.51

>>111
> 例えば画像データみたいに巨大故に必要無い限りコピーしたくないんだけどそんな事情をライブラリ利用者から隠蔽したいケース
なるほど理解した。
ここでshared_ptrを渡して多数に見せかけ、実は中身は一つ、という話か。

となると、当然インミュータブルでないと話にならないわけだが、
逆に言えば、今時のインミュータブルな世界にはshared_ptrが大活躍する余地があるのか？
すぐにはピンと来ないが。

2018/06/10(日) 15:33:13.30

>>113
△：当然インミュータブルでないと話にならないわけだが、
○：当然インミュータブルなインターフェースでないと話にならないわけだが、

実装は別にミュータブルでもクラスで覆うならやりようはいくらでもあるんじゃ…
画像の書き換えを専用メソッドでやるか、あるいは速度優先でcheckout/checkin式にcheckout中だけ直接アクセスを許すとか、
（もちろんcheckout時にコピーを行う

で、内部ではshared_ptr（的な、「オブジェクト自身に開放タイミングを決めさせる」）ロジックが大活躍！！１１１！！！！１！

2018/06/10(日) 15:33:15.61

>>111
いや待てよ、コピーオンライトなスマポがあればミュータブルな世界にも適用可能だが、
今の所、これはないよな？

いずれにしても適用事例はすぐには思いつかないが。

2018/06/10(日) 15:35:49.57

訂正；
×：あるいは速度優先でcheckout/checkin式にcheckout中だけ直接アクセスを許すとか、
○：あるいは書き換え速度優先でcheckout/checkin式にcheckout中だけ画像への直接アクセスによる書き換えを許すとか、

2018/06/10(日) 15:36:25.37

C++を解った気になった奴らがアンチパターンを量産する

2018/06/10(日) 16:02:15.14

>>114,116
まあ分かった。
多分shared_ptrは『ほぼ』インミュータブルな世界とは相性がいい。
(ミュータブルにする必要がほぼなく、その場合は明示的に別メソッドを呼んでもいい場合）

つっても適用事例はWebサーバーくらいしか思いつかない。
ある画像が人気でユーザーが一斉にダウンロードしたとして、
鯖内部に30秒間だけキャッシュする場合とか。

ナマポで渡した場合、各ユーザーのダウンロード完了でカウントを減らし、０になるまで破棄出来ない。
shared_ptrで渡した場合、30秒の期限が過ぎればキャッシュから破棄しても問題ない。
この辺は確かに楽に組めるようになる。

2018/06/10(日) 16:07:24.50

>>118
キャッシュにstd::shared_ptrを使用するのは愚策すぎるのではないか。
実のところstd::shared_ptrはほとんど出番がない。
設計を練れば練るほど出番は失われていく。

2018/06/10(日) 16:15:05.15

いやすまんインミュータブルなインターフェースといいつつ>>114では画像を書き換えるインターフェースの話をしてしまったｽﾏﾝorz
「画像の書き換えを専用メソッドでやる」は、「加工後の画像を専用メソッドで生成する」、と読み替えてﾎｽｲ

で、ライブラリが画像Aを生成し、その画像がライブラリのユーザーによって不特定多数のクライアントとのセッションスレッドに渡されるｼﾁｭを考える
セッションスレッドの具体的な数は事前にはわからない。（接続してくるクライアント次第
また、何らかのタイミングでクライアントに提示すべき画像Aは、別の画像A'に差し変わる。

ライブラリのユーザーとしてはスレッド間の排他制御に関して面倒な問題を抱え込むのは嫌なので、
メインスレッド（セッションスレッドを起こす）から、画像Aのコピーを、所有権を譲渡する形でセッションスレッドに渡す、という使い方をする。・・・(1)

ライブラリ内部では、(1)の使い方をされるときにいちいち画像Aをコピーしたりしない。

画像Aの開放は、画像AがA'に差し変わるタイミングで行いたい。
ただし、画像Aを使っているセッションスレッドが居る間は開放するわけにはいかない。
しかし、当該スレッドがセッションを終えるのを待っていたら、新規につないで来るクライアントへの画像A'の提示が遅れる

→画像Aの開放タイミングはスマポで解決！

2018/06/10(日) 16:27:25.23

>>118
ちょっまだキャッシュ言いますかキャッシュと参照カウントは原理上無関係なので（>>106）忘れてよろしいかと、
（参照カウンタが0より大きいからキャッシュ上のデータを消してはいけないという法は無いし、
　参照カウンタが0になったからといってキャッシュ上のデータを消さなければいけないという法も無い

Webサーバというのは適用事例として好適だがダウンロード中かダウンロード完了か、という区分でしか考えないのはｲｸﾅｲ
ダウンロード中にも新規のクライアントがつないでくるかもしれない
そのときダウンロード完了時に画像を破棄すればいいやという単色の思考だと、新規のクライアントが繋いで来つづける限り
画像を永久に開放できないことになり、そればかりか>>120のように、画像をAからA'に差し替えることもできない

これは画像Aの開放を、画像Aのオブジェクト自身に面倒をみさせるしかない（自身を参照するセッションスレッドが0になったとき開放させる
サーバはそれとは並行して画像A'を新規のセッションスレッドに展開できる。
こんな芸当ができるのはスマポだけ！

2018/06/10(日) 17:11:42.47

>>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を使っても大して楽にはならない）

2018/06/10(日) 17:28:14.89

一応簡単に俺の主張を纏めておくと、

・unique_ptrは従来C方式を文法的に強制させるだけで、コードの改善には繋がらない。
・shared_ptrの使いどころはWebサーバーしか思いつかない。

GC言語は基本的にshared_ptrなわけだが、あれって基本的に手抜き専用で、
GCがないと本質的に辛いって構造はあんまりない。
Rustも今更GC無しですかー、とも思うが、実際、無しなら無しでもいいか、程度ではある。

◆QZaw55cn4c (ﾜｯﾁｮｲ d360-EqDK) · 2018/06/10(日) 17:41:05.68

>>123
その GC が大問題
現状 GC の最終手段は mark and sweep なので、これが嫌だ、という価値観はありだとおもう

2018/06/10(日) 17:56:24.27

>>109
> 俺はunique_ptrは「C的リソース管理を文法的に示す」意味しかないと見てる。

その意味がすごく重要やん？
漠然としてたものに区別を与えてくれる最高の機能じゃんね。

2018/06/10(日) 18:04:27.80

std::enable_ifを使いこなそう。

2018/06/10(日) 18:04:47.47

>>95
期待して損した
そんな自殺コードを書かれるのを防ぐのは
スマポじゃなく人事部の仕事だ

2018/06/10(日) 18:05:45.54

「バカよけ」機能に価値はない、無駄だから使わないしコードが長くなるから使わせない
っていう老害いるよね
そういう奴に限ってバグや脆弱性作り込むんだけど決して反省しない

2018/06/10(日) 18:06:37.55

std::unique_ptrを導入すると人事部から一人削減できるってことじゃないか。

2018/06/10(日) 18:09:53.52

まともな知的生命体なら迷わずユニポを使うだろう。

2018/06/10(日) 18:21:28.47

>>128
まあ俺も老害とか言われることのある世代だが
価値がないのは「バカよけ」ではなく「バカ用」な
バカなふりをする達人をニヤリとさせるのではなく、
どうしようもない真性バカを延命する機能は有害なだけ

2018/06/10(日) 19:04:58.32

>>127
期待するも何も、スタック巻き戻したらどうしてヒープ開放されると思ったのさ？

2018/06/10(日) 19:11:21.01

>>132
デストラクタが実行されるからさ
スタック巻戻しとは何たるかわかってる？

2018/06/10(日) 19:42:24.37

混乱を避ける為に先に質問しておきたいんだが、
上記A(82)の場合、つまり、
親関数から子関数にポインタを渡したいが、所有権を移動しない場合には、どう書くんだ？
ざっと探しても出てこないんだが。

引数に値渡ししたらムーブ、これは分かる。
ムーブしたくないが子関数に渡したい場合は？

2018/06/10(日) 19:43:15.79

すまん、>>134はunique_ptrの場合。もう一度書き直すと、

親関数から子関数にunique_ptrを渡したいが、所有権を移動しない場合には、どう書くんだ？

2018/06/10(日) 19:45:27.08

>>124
それはありだ。

ただし、俺は「循環参照の場合に回収出来ないGC」であってもいいと思っている。
循環参照が必要なケースはほぼ無いので、明示的に切ってから解放でいい。
これはweak_ptrと同じで、C++erなら同意してもらえると思う。

ついでにいうと、「コンパクションが出来ないGC」でもいい。
これなら**ptrにする必要なく、*ptrで行けるから速度低下も起きない。

つまり、仕様はC++どおりでいいが、
プログラマにやらせるな、自動でやれ、ということ。俺的には。

2018/06/10(日) 20:15:37.49

>>135
なんだよ！所有権の複製もできないのかよ！？
やっぱりstd::unique_ptrダメじゃん！！！！

2018/06/10(日) 20:21:31.52

>>137
まあそのネタはさておき、マジで探しているのだが出てこない。
知ってたら教えてくれよ。

これ、もしかしてget()してナマポ渡すしかないとかいうオチ？
ならunique_ptrなんてマジでゴミだぞ。
さすがにそれはないと信じて探しているのだが、マジで出てこない。

2018/06/10(日) 20:22:18.03

>>138
参照で渡せばいいんじゃないのか？
そんなことして何の意味があるのか知らんが。

2018/06/10(日) 20:23:52.60

std::unique_ptrに対するweak_ptrは無いぞ。
だからゴミだという場合は、>>137。

2018/06/10(日) 20:24:48.73

>>139
俺も最初はそうかと思っていたんだが、実はそれも出てこないんだよね。

まあでもそれで、コンパイラが最適化をするのを期待する、というC++的オチか？
これはあり得るとは思うが。

2018/06/10(日) 20:28:59.72

>>141
当たり前すぎて出てこないだけでは？
auto result = my_func(*my_unique_);
とすればいいだけなんじゃないの？

2018/06/10(日) 20:31:55.61

std::unique_ptrを利用する主な動機は総称型を保持するためなんだよな。

2018/06/10(日) 20:33:45.13

>>140
そういう意味ではないが、
> std::unique_ptrに対するweak_ptrは無いぞ。
この表現は分かりやすい。

>>142
それは実体を値渡ししてしまうだろ。

2018/06/10(日) 20:37:44.47

>>144
lvalue_referenceだから仮引数側でどうにでもできるだろ。

2018/06/10(日) 20:49:11.93

https://ideone.com/SEcQKq

こういうことがしたいんじゃないのか？

2018/06/10(日) 21:01:59.63

参照だけするスマポ（と言いつつ何もしないアホの子スマポ）は次の規格で検討されてたでしょ
observer_ptrだかexempt_ptrだか名前コロコロ変わってるけど

2018/06/10(日) 21:22:56.11

>>146
だから違うっての

>>147
多分俺が欲しいのはそれだ。
https://en.cppreference.com/w/cpp/experimental/observer_ptr
要するに、「ナマポだがdelete出来ない物」が欲しい。
unique_ptrは値渡しすると所有権が移動してしまう。
関数にはポインタの場合値渡しが最速だし、自明だから、グダグダ書いて最適化を待つ、とかやりたくない。
生成は常にunique_ptrからの値コピー（所有権は移動しない）でいい。

寿命管理は他に任せるが、ナマポと完全に同パフォーマンスの物、これが欲しい。

まあ、検討中ならよかった。

2018/06/10(日) 22:03:51.04

deleteされたくないポインタと言えばこうだろ。
https://ideone.com/PvzDVY

2018/06/10(日) 22:50:21.29

>>125
> 漠然としてたものに区別を与えてくれる最高の機能じゃんね。
俺の理解が正しければ、これはダウト。表現力が足りない。
今のunique_ptrはB用のインタフェースしか持っておらず、Aを最速では記述出来ない。
足りてないのは、既に言ったとおり、「ナマポと同速だがdelete出来ないスマポ」。

だからやっぱイマイチなんだな。
とはいえ確実に拡充されてるから、最終的にどうなるかは見物だが。
高位機能も最終的には追いつくだろうし。

ただ、C++はプログラマの努力で何とかしようとしているが、
そもそもＡにしてもBにしてもコールグラフの解析でfree忘れとか抜けるはずなんだよね。
Cの連中はこの辺には興味ないみたいだけど、
人手でやってる分、スマポみたいにコーナーぎりぎりを攻められないから、
ある程度わかりやすいところでfreeされてる。
当然、ツールにもかかり易いはずで。

2018/06/10(日) 23:09:19.21

それ参照でいいだろ。
言ってる意味が全く分からない。

2018/06/10(日) 23:41:15.51

私もはやく皆さんとお話したいのですが、内容が全くわかりません。
C++でRPG作れる程度の知識なのですが、何から学べば良いでしょうか。
おすすめの本、サイトがあれば教えてくださいが

◆QZaw55cn4c (ﾜｯﾁｮｲ d360-EqDK) · 2018/06/10(日) 23:46:32.30

>>152
それならば
effective C++ / effective modern C++ がいいかと思います

2018/06/10(日) 23:47:37.76

そりゃC++使ってる人が読んだって全く分からないだろうな。

2018/06/11(月) 07:09:55.61

>>122
>1. インミュータブルなインタフェースで、
>2. 不特定多数がランダムに掴みに来て、
>3. 解放タイミングがユーザー依存で読めない場合
ちゃうねんそれでは表層的な観察にすぎなず、
shared_ptr（的な、「オブジェクト自身に開放タイミングを決めさせる」(>>114)）処理の必要性の1断面でしかないねん

>>121-122が言っているのは、
>こちらが実装上の都合で用意するオブジェクトの数と、未来のプログラマーに対して見せかけるオブジェクトの数が相違するケース(>>111)
において、未来のプログラマー（ユーザー）がオブジェクトをコピーしたつもりだが実装の内部ではコピーしていなくって、
ユーザー視点では自身のプログラムが保持する独立した1オブジェクトを開放したつもりが、実は内部の実装の都合において、
ユーザーまたはユーザー2のプログラムが保持する別のオブジェクトの開放と関係を持ってしまうケース（∵実体が同一）において
shared_ptr的な、「オブジェクト自身に開放タイミングを決めさせる」(>>114)）処理が必要ということなんじゃー

2018/06/11(月) 07:23:54.00

.>>122
>画像の差し替えはキャッシュ内の画像Aを無効化することにより行われる。
これは>>121のケースでは問題の解決にならない。
なぜなら、仮にキャッシュ上に画像Aを用意してあり、最後まで画像Aを掴むことになったセッションXに対して
セッション開始時にメインスレッドが渡したのがキャッシュ上の画像Aだったとしても、
渡した瞬間にセッションとキャッシュの関係は切れるからじゃわ！（半切れ

>>121は、セッションXは自身のローカル記憶（のつもり）であるところのオンメモリの画像Aを使い、
セッション終了時に開放する、ということしか言っておらず、
セッション中に2回3回とキャッシュ上の画像Aを取りにいくとは書いては
いない
キャッシュとセッションXの関係がセッション開始時の一瞬でしかない想定な以上、
画像Aの実体の開放に関してキャッシュの無効化機構をどう別実装しても無駄。問題に影響無し。

2018/06/11(月) 07:43:46.07

ちな「キャッシュの無効化機構」とは、新規セッションに見せかける画像をAで無くすしくみという意味であって（それ以外の読み方をせよというのは㍉）、
画像Aの実体の開放とは関係ありませんからぬ、
というわけで繰り返しになるが画像Aの実体の開放に関してキャッシュの無効化機構をどう別実装しても無駄で、
画像Aの実体の開放はshared_ptr的な、「オブジェクト自身に開放タイミングを決めさせる」(>>114)）処理の専任事項となる
（>>121の想定のように画像Aが複数に見えることもあるが実体は唯一、というときはそうする以外画像のAからA'への差し替えは㍉

2018/06/11(月) 22:46:31.97

>>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)
でしかない。
勿論それが許容されている世界であり、スループットを取っているだけだからそれでいいんだが。

2018/06/11(月) 22:47:47.00

が、とにかく君は、
> オブジェクト自身に開放タイミングを決めさせる
事が必要だと思っているらしい。これの他具体例はあるか？

君が挙げてきた別例はGCだが、現実問題として、ほぼunique_ptrで事足りるのも事実だろ。
shared_ptrは機能的にはunique_ptrの上位互換だから、GCではそれが用いられているだけであって。
「ナマポ禁止、スマポ使え」なC++宣教師は、
次は「漢ならunique_ptr。shared_ptrは甘え」と言うと思うぜ。

それともあれか？smalltalk的OOP或いはアクターモデル的に
> オブジェクト自身に開放タイミングを決めさせる
ってのか？だったらもうそれは流行らない、というか、
今のところ無駄が多すぎて普通に組んだ方がマシ、ってことになってる。

2018/06/11(月) 23:50:59.24

ワイ、低みの見物

2018/06/12(火) 00:05:51.50

ワイ、今表示されてる倉田まおの母音を見物中

2018/06/12(火) 00:38:01.99

長い独り言だ
いつ終わるんだ

2018/06/12(火) 05:08:46.11

オブジェクト開放ってどんな機能なんだろう:-P

2018/06/12(火) 06:07:09.64

「delete忘れないようにunique_ptr使いましょーね」「共有が必要ならshared_ptrがべんりだよー」
っていうだけの話の何がそんなに気に食わないのかさっぱりわからなくてついていけない

2018/06/12(火) 07:13:51.68

相手するなよ...

2018/06/12(火) 07:40:51.47

>>164
Q. 俺には必要性が分からない
A. 必要がないなら無理に使わなくていいよ
で済むお話。

2018/06/12(火) 14:16:45.83

>>164
俺は何言ってるか分かったけど、この人に説明するのは無理だろな。
使ったことがないものを批判したい感じだし、std:unique_ptrは必要になってから使えば良いよと言ってあげれば良いのかも。

2018/06/12(火) 14:21:27.71

まずムーブを活用して、総称性が必要になってから初めてunique_ptrを検討する感じがいいんじゃないのかな。
そしてshared_ptrは設計に時間をかけられないときに使うもので、ほとんど出番がないはず。

2018/06/12(火) 14:25:31.83

20世紀最大の発明はレーザーと言われてるけど、21世紀最大の発明はムーブと言われてるからね。
俺に。

2018/06/12(火) 14:41:13.61

なるべく (ポインタでなく) 値でやりとりすること、それを低コストで出来るようにムーブ対応にしておくというのは
上位レイヤを作るときに楽できる良い設計だとは思うけど、
実質的にはスマートポインタの機能をクラスに付け加えてるみたいなもんで、
それがクソ面倒くせえときに標準のスマートポインタを使うみたいな方針でやってた。

総称性を活用するときという観点は無かったけど、確かに必要な考え方だな。

2018/06/12(火) 17:40:26.92

unique_ptrで内蔵しておけばnoexceptにしやすいので、ムーブが使われやすくなるというのはありますね。
とまあ、C++を使っていれば自然に有効利用するものですが、使う前に理解するのは難しいのではないでしょうか。
使ってみればなるほどとなると思うんですよね。

2018/06/12(火) 17:41:11.05

机上の空論繰り返すより、使ってみればすぐわかるよ。
これがおじさんからのアドバイス。

2018/06/12(火) 18:51:59.08

総称性ってなんだ？

2018/06/12(火) 19:28:54.15

C++の基本概念ですかね。

2018/06/12(火) 20:48:00.50

>>174
説明してくれる？

2018/06/12(火) 20:57:02.36

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#のジェネリクスがある。

へー

2018/06/12(火) 21:16:18.28

総称型の説明は要らんよ
欲しいのは総称性って言う謎の言葉の方

2018/06/12(火) 21:34:08.94

謎なんだ。

2018/06/12(火) 21:37:14.01

個々のクラスの実装を工夫して値渡しとムーブで解決できないかをまず考えて、
複数の型について類似のコードが出てくるようなら unique_ptr や shared_ptr (や自作スマートポインターテンプレートクラス) の利用を検討する、
というようなことでは。

2018/06/12(火) 21:45:06.18

シンシュンシャンソンショー

2018/06/12(火) 22:13:43.97

>>178
そりゃ誰も説明できないから謎でしかないわ w

2018/06/12(火) 22:15:46.28

なんかそれっぽく言っとけば暗黙の内にマウント取れるから

2018/06/12(火) 22:18:13.53

「オマエ知らないんだ～」「でも教えてやらなーい」ってのは
元手ゼロでもできる安上がりなマウンティング

2018/06/12(火) 22:38:18.73

悔しそうだねｗ

2018/06/12(火) 23:00:25.83

オマエ知らないんだ～
でも教えてやらなーい

2018/06/12(火) 23:22:34.41

>>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万通りぐらい即答できるはず

2018/06/12(火) 23:42:22.02

通知メカニズムを持つ画像より、通知メカニズムを持つリソースハンドルのほうが便利に違いないので、あまり使いどころがなさそう。

2018/06/12(火) 23:47:32.67

>>187
リソースハンドルは味噌も糞も一緒のHANDLE型で型安全の観点から不安があるが
画像クラスでwrapすれば型安全になる
行いが良ければ空も飛べるはず

2018/06/13(水) 00:06:22.45

>>188
禿4はSTLコンテナの類もリソースハンドルと呼んでるけどな。
std::shared_ptrに通知メカニズムをプラスしたようなものが実際に必要になるのではないだろうか。
オジサンはATL風の通知メカニズムを備えたコンテナを作りましたぞ。

2018/06/13(水) 00:09:01.46

リソースを共有するということは、通知もセットで必要になると思うんだよなあ。

2018/06/13(水) 00:25:29.19

>>170
お前、ﾜｯﾁｮｲ 81b3-8neNが一度もまともなことを言ってないのを理解出来ないのはヤバいぞ。
そもそもお前、>>125ってことは、observer_ptrの使いどころも理解してないだろ。

2018/06/13(水) 01:34:41.54

まだ標準にも入ってないもんなんか使ったこともないし知らんわ。

2018/06/13(水) 18:27:25.89

唐突にphoenix_shared_ptrとか言ってみる　解る人おるやろか
Lokiに始まるメタテンプレートプログラミング狂騒時代も15年以上昔か…

2018/06/13(水) 19:47:43.91

>>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に冷めている理由だろうよ。無知な馬鹿にしか見えないから。

2018/06/13(水) 21:32:55.86

>194
> 正しくCを使っている連中は、そのナマポがunique/shared/weak/observerのどれなのかは明確に意識してる。
> ただそれを書いてないだけだ。だから馬鹿には使っていないようにしか見えない。

ああ、馬鹿にはわかんないよ。
だから書いてくれっての。

人間は度し難いほど馬鹿なので、クソみたいな間違いをする。
意識していたとしても間違う。
知っていても何度でも間違う。

そんなの当たり前だろ？

2018/06/13(水) 21:37:20.42

で、おめぇは一流のC++erと自称したいのかい。

ほんとに糞な爺だわ。早く棺桶の中で寝ろ。この河童虫が

2018/06/13(水) 23:13:52.35

>>195
まあ俺は書くこと自体には反対ではないんだが、

1. 足りないんだから書きようがない(observerが)
2. そもそも書くほどバリエーションがない

Cで使われているのはunique/observerで、shared/weakはほぼあり得ない。
制御が煩雑すぎてバグる。
だからこそsharedが生きる構造があればC++が勝ちきる可能性があったが、
shared撲滅みたいな今の風潮じゃあねぇ。

そして既に書いたが、大概は方式Ａだから、
ローカルのナマポはuniqueで、それ以外は全部observerでしかない。
わざわざ分けて書くほどバリエーションがないんだよ。

Cの連中は書くのが嫌なわけではなく、書く意味を見いださないのだと思うよ。
書いたところでコード構造が改善されるわけでもなく、速度が上がるわけでもない。
書かずともどうせＡ方式だし。

2018/06/13(水) 23:25:33.47

shared撲滅の風潮ってどこ界隈の話なの？

2018/06/13(水) 23:41:19.62

sharedはリファレンスカウンタがからんでくるからね

◆QZaw55cn4c (ﾜｯﾁｮｲ d360-EqDK) · 2018/06/13(水) 23:55:17.48

shared は循環参照には無力だからね…