[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/24 15:41 / Filesize : 321 KB / Number-of Response : 1024
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

C++相談室 part137



1 名前:デフォルトの名無しさん [2018/08/27(月) 16:02:00.94 ID:vY3QDx2y0.net]
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

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

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

■長いソースを貼るときはここへ。■
 codepad.org/
 https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレ ここまで -----
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

263 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 13:53:20.00 ID:c/F3wcvdM.net]
>>256
それはお前の間違った理解であって一般とは言わない
だいたい呼び出し側も含めて反論されてんのになにぼけたレスしてんだよ

お前の理屈だとレジスタの返しが無用となるじゃないか
x64ならraxでaarch64ならx0で返り値を返す
32bitのレガシーならいざしらず64bitでもabiはそう決められてるわけ
お前の興味のない低いレイヤーではそういうのを最大限活用して効率的にcpu回してんだよ

264 名前:はちみつ餃子 mailto:sage [2018/09/06(木) 14:06:16.01 ID:IzfX8EX20.net]
>>258
> だいたい呼び出し側も含めて反論されてんのになにぼけたレスしてんだよ

それは >>254 のことだろ?
それは特定の命令セットや ABI でないと成り立たないから、
そうでない一般論としてはどうともなりうると私は言っているので論点が違うし、
私はそっちの論点は気にしてなかったという話じゃないか。

265 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 14:09:29.47 ID:c/F3wcvdM.net]
>>259
現実のはなししようぜ
成り立たないシステムあげてみなよ

266 名前:はちみつ餃子 mailto:sage [2018/09/06(木) 14:11:05.68 ID:IzfX8EX20.net]
>>255
知らんな。
関心は無い。

267 名前:はちみつ餃子 mailto:sage [2018/09/06(木) 14:27:25.26 ID:IzfX8EX20.net]
>>255
前者については & の脱字だと仮定して答えるけど、
その脱字が無ければ、前者でも後者でも最終的な結果に差はないと思う。
特にメモリリークにつながりそうな要素もない。

ただ、単純に、局所的に考えるならば後者の方が効率的と言えると思う。
前者だと呼出し側では結果を受け取るための cv::Mat 型の変数を用意しなければならないが、
そのときにデフォルトコンストラクタが走ってから結果は operator= で格納するという形になる。
後者だとコピーコンストラクタ一発で済むので簡単。 場合によっては RVO が適用されるかもしれない。

一度作った変数を何度も結果格納用に使いまわすのならば、
前者の方がメモリアロケーションの回数を抑制できる (効率的になる) 可能性も有るけど、
Mat の実装次第ではそうならないかもしれないし、
そこらへんは実際にやってみないとわからない。

ところでメモリリークが起きていると判断したのは何かツールを使って検証したの?

268 名前:はちみつ餃子 mailto:sage [2018/09/06(木) 14:31:00.99 ID:IzfX8EX20.net]
あっ、 >>261>>255 にアンカーを付けちゃったけど、これは >>260 の間違いね。

現実の話というなら、インライン化や最適化が入れば ABI もクソもねぇし、
そんなの考えたらキリがないやろ。

269 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 18:25:26.14 ID:c/F3wcvdM.net]
>>263
関数内の最適化のみで考えればいいだけなんだからきりはあるだろ
つまりインライン展開なし、LOTなし

ABIを意識するのは全然特殊じゃない
言語間のよびだしはざらだし、
クラッシュダンプにスタックトレース残すためにあえてインライン抑制したりする
お前が経験不足なだけだよ

270 名前:はちみつ餃子 mailto:sage [2018/09/06(木) 18:41:01.02 ID:IzfX8EX20.net]
>>264
そっちの脳内でどんな前提を置いてるかなんて知らんがな。

271 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 19:48:52.61 ID:c/F3wcvdM.net]
>>265
コテハンの割に薄いやつだ

もとの質問は関数から値の返し方についてどちらが速いかという質問なんだから、
関数のインライン展開がないと仮定すれば、定性的に答えられる問いだ
かつその仮定は別に現実ばなれしてるわけでもない

それをお前はその知識が有用であることも知らずに考えるだけ無駄とかぶったぎってるわけだ

このスレは相談室
無駄なのはそういうお前の存在ではとおれは思うわけ



272 名前:デフォルトの名無しさん [2018/09/06(木) 20:12:24.70 ID:64ZwjQvb0.net]
malloc()したヒープはfree()解放するのは当然
ウンコしたあと水で流さないぐらい行儀が悪い

273 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 20:23:27.14 ID:itCyrIVk0.net]
メモリーリークは基本的に自分でNEWすることで起こる。
最近のC++では基本的に自分でNEWすることはほとんどない。
動的なメモリが欲しければvectorを使う。
後は、ポインタにインスタンスを確保しないで関数に投げるとかもやってはいけない。メモリを破壊することになる。
あと、どうしてもnewが必要だったりGCが必要な時はスマポを使う。

そういう作法でやると、ユーザーコードでnewすることはほぼない。

274 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 20:47:20.81 ID:itCyrIVk0.net]
えーっと、関数にポインタを投げる時はその関数の仕様を精査して扱わないとほんとやばい。

275 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:04:04.33 ID:bw6Oo6uj0.net]
newとdeleteを使いこなせない補助輪付C++グラマってのも問題だけど

276 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:10:02.71 ID:iyjSCMca0.net]
スマポはGCじゃねえよ ぼけ

277 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:14:09.31 ID:itCyrIVk0.net]
shared_pointerは参照カウントっていうGC機構ですよ?

278 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:17:21.85 ID:itCyrIVk0.net]
>>270

279 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:18:00.66 ID:itCyrIVk0.net]
おっと。
>>270
補助輪があろうがバグ出すよりマシだと思うよ。それと保険的な意味もあるし。

280 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:18:22.90 ID:iyjSCMca0.net]
CGってそもそも何だ?
アプリが「今、解放しろ」というタイミングで動くのをGCというならfreeもGCだぞ

281 名前:デフォルトの名無しさん [2018/09/06(木) 21:20:24.16 ID:64ZwjQvb0.net]
いつ解放されるか分からないとか
そもそもオブジェクトの外部でポインタの生存期間を制御できてないコードがヤバイわ



282 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:24:58.09 ID:itCyrIVk0.net]
>>275
そういう、広義解釈は話題が滅茶苦茶になるのでやめましょう。
GCはガベージコレクションだよ。freeは解放関数だよ。
シェアードポインターの解放タイミングは普通コントールしないのでGCだと思ってます。
というか、開放タイミングが未定だからシェアードポインタ使うんじゃないですか?

283 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:27:59.96 ID:itCyrIVk0.net]
それは全能でないとバグが出ちゃうのでこういう機構が発明されました。
書くときは大まかには寿命は把握しているとは思うのですが、細部までは精査しないことが多いんじゃないでしょうか。
自分のクローンに共有オブジェクトを持たせるときとか普通に書くと滅茶苦茶大変ですよ?

284 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:37:24.49 ID:iyjSCMca0.net]
>>277
広義解釈してるのはおまえだよ
シェアードポインタの解放タイミングはデストラクタだろうがよ
freeと何がどこが違うんだよ
おまえどこまでオレオレ空想してるんだ?

285 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:38:17.39 ID:itCyrIVk0.net]
>>276
それはある程度アクセス権の範囲を考えれば何とかなりそうな予感。
それと開放した後のメモリ叩かれた時とどっちがいいか相談ってことで。

286 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:41:02.92 ID:itCyrIVk0.net]
>>279
複数の共有がある場合、一個のデストラクタが走った程度では解放されませんよ?
freeは別にデストラクタに仕込む必要ないじゃないですか。
それと、複数の共有がある場合適切にfreeできますか?

287 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:42:45.15 ID:JT+LXegNM.net]
コレクションしてないのになんでgcなんだよ。アホすぎる

288 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:43:23.10 ID:bw6Oo6uj0.net]
シェアードはマルチタスクには不向きだし

289 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:49:40.12 ID:itCyrIVk0.net]
コレクションサイズが1のコンテナはないのですね。まぁ、冗談は置いといて。
物事を知ってるなら後は任せました。無知でごめんなさい。

290 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:51:04.10 ID:itCyrIVk0.net]
>>283
マルチスレッドならアトミックにできた気がしますけど、どうでしたっけ。
マルチプロセスならそもそもメモリ空間が違うのでお門違いですね。

291 名前: mailto:sage [2018/09/06(木) 22:00:46.00 ID:N2ZzCqNY0.net]
>>272
参照カウンタは普通GCに含めないのでは?



292 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 22:02:22.60 ID:itCyrIVk0.net]
https://ja.wikipedia.org/wiki/参照カウント
こういう記事を見つけました。

293 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 22:04:19.65 ID:itCyrIVk0.net]
ホントお前ら人殺すことばっか考えてるよな。
そういうのは良いから初心者殺すのマジやめて。

294 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 22:04:41.28 ID:vgkXomJH0.net]
gcの一実装として参照カウンタ方式があるだけで、スマポはgcじゃない。

295 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 22:06:33.66 ID:itCyrIVk0.net]
それならそれでいいです。

296 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 23:18:28.17 ID:8cSq8zHP0.net]
>>288
横からでスマン

297 名前:ェ、他の初心者に偉そうに大嘘教えてるやつを初心者とは普通呼ばない
都合のいいときだけ初心者ヅラはだめよ
[]
[ここ壊れてます]

298 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 23:34:23.61 ID:3bNAvGWPM.net]
>>262
ありがとうございます
forの中で何回も関数呼び出すので前者が良さそうですね

299 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 23:34:43.07 ID:itCyrIVk0.net]
>>291
嘘の範囲を限定しないと俺大罪人じゃないですか。
まぁ、いいや。

メモリーエラーで落ちろ。

300 名前: mailto:sage [2018/09/06(木) 23:34:53.93 ID:N2ZzCqNY0.net]
>>289
スマートポインターのうち std::shared_ptr は参照カウンタを内蔵しているのだから
@参照カウンタが GC、故に、std::shared_ptr も GC
A参照カウンタが GC でない、故に、std::shared_ptr は GC でない
@Aのどちらかしかない
参照カウンタが GC なのにスマートポインタが GC でない、というのは矛盾しているのでは?

私は「参照カウンタは GC じゃない」と思う

301 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 23:48:27.91 ID:8cSq8zHP0.net]
>>293
>>251
もちろんインライン展開される場合は除く(展開されたら多分同じコードになると思うが

あと
>>255の質問に対して>>268は不適切、>>268から話が変な方向に行ってる
OpenCV使ってるって言ってるし、間違った使い方してリーク(>>255がnewしたのではない部分)
の可能性の方が高いと思うけどね



302 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 23:52:47.61 ID:HW23dE280.net]
>>294
なにも矛盾してないよ。

GCの一実装として参照カウント方式を使ったものがある。
スマホの中に参照カウントを使ったものがある。
だからといってGC=スマポじゃない。

エンジンで走る車があって、エンジンで飛ぶ飛行機があっても、車は飛行機じゃないのと一緒

303 名前: mailto:sage [2018/09/07(金) 00:04:30.19 ID:WaHB6+zk0.net]
>>296
>エンジンで走る車があって、エンジンで飛ぶ飛行機があっても、車は飛行機じゃないのと一緒
is-a の話の例えに has-a の話を使うのは論理的ではありませんね
「車 has エンジン、飛行機 has エンジン」の話と「参照カウンタ is GC、スマポ is GC」の話は別ですよ

304 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 00:12:24.59 ID:YR0a2VfT0.net]
>>297
いやgc=参照カウンタなんて言ってないんだけど。
gcに参照カウント方式を使っているものがあるといってるの。はじめからhas_a関係しか言及してない。

305 名前: mailto:sage [2018/09/07(金) 00:15:18.97 ID:WaHB6+zk0.net]
>>298
>いやgc=参照カウンタなんて言ってないんだけど。
そこに「=」記号を使うのがおかしいのでは?
真偽は別として、記号を使うのなら ⊂ とか ∈ じゃないですか?

306 名前:はちみつ餃子 mailto:sage [2018/09/07(金) 00:17:33.32 ID:EL+7DMJm0.net]
参照カウンタは GC だろ。

307 名前:はちみつ餃子 mailto:sage [2018/09/07(金) 00:22:54.57 ID:EL+7DMJm0.net]
>>266
元々の質問はどちらが速いかではない。

308 名前: mailto:sage [2018/09/07(金) 00:53:47.67 ID:WaHB6+zk0.net]
>>300
では std::shared_ptr も GC でしょうか?

309 名前:はちみつ餃子 mailto:sage [2018/09/07(金) 01:28:57.33 ID:EL+7DMJm0.net]
>>302
私は std::shared_ptr を GC だと思ってるよ。
解放のタイミングがコンパイル時に確定しないようなのは GC だろってくらいのカジュアルな認識だけど。
基準の妥当性はともかくとして、とにかく私はそういう基準で考えてる。

QZ 氏の中で std::shared_ptr と GC を隔てるのは何だと思ってるの?

310 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 02:17:04.39 ID:obwFdGuS0.net]
Qt5触ってみてるけど生ポインタばっか使ってて気持ち悪い、これでいいのか?

311 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 07:52:15.03 ID:KDtg+GuV0.net]
GC ⊇ shared_ptr



312 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 08:31:14.42 ID:M/DU9wQ1M.net]
>>304
生は触って気持ちいいものしかないよ

313 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 11:18:53.99 ID:f8oqes6vH.net]
parentクラスがあってそれを継承したchildクラスがあります。
vector<parent*> getParentlist(){//省略}でこんな感じでparentクラスのポインタのリストを返す関数があります。
それでここからが質問なのですが、
vector<child*> childList = (vector<child*>)getparentlist();
こういうコードがあってびっくりしています。
機能はしているみたいですがこれ作法的にオッケーなんでしょうか。
ダウンキャストは良くないと聞いていたりそもそもこれダウンキャストなのかとかちょっと分からないんです。
よろしくおねがいします。

314 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 11:20:41.99 ID:/+XJI6DP0.net]
>>281
話が通じてないなあ。。。
デストラクタでuse_count見てるのは当たり前だろ
シェアードポインタの話だぜ?

解放のタイミングがアプリのロジックに従属してるかどうかって話なのに
何を言い出すかと思えば

315 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 12:35:44.17 ID:KEvh9jix0.net]
>>307
試せる限りのコンパイラではそもそもコンパイルエラーだったけどなぁ
vector<parent *> &getParentlist();
じゃなくて??
その上で
(vector<child *> &)getParentlist();
なら通るよ、通るし普通に使えるはず

316 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 13:23:59.20 ID:f8oqes6vH.net]
>>309
失礼しました。ポインタ抜けてました
vector<parent*>* getParentlist(){//省略}

vector<child*>* childList = (vector<child*>*)getparentlist();
こんな感じです

317 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 13:38:44.48 ID:KEvh9jix0.net]
おいおい・・・w

ポインタでも同じことだ、そのキャストをreinterpret_castだと考えたらわかるはず
それでわからないならC++の継承の仕組みを勉強すべき

318 名前:はちみつ餃子 mailto:sage [2018/09/07(金) 16:38:51.51 ID:EL+7DMJm0.net]
基底方向へのキャストの実態は
サブオブジェクトまでのオフセット分だけアドレスをずらす操作なので、
>>310 のような場合にはそれは実現できない。
単に無理やり型を合わせているだけになってしまっている。
C++ 的にはあかんやつ。

ただ、実際に動いている理由をあえて考察するなら、
child が parent を単一継承した場合などには parent が child の先頭に配置されるようなメモリレイアウトにコンパイルされる可能性が高く、
アドレスをずらす量が 0 で済んでしまうので
型を読み替えるだけでも不整合が顕在化せずに動作してしまうということは有りうる。
あくまでも、処理系がやってることが偶然に組み合わさって動いているというだけなので、やめといた方がよい。

319 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 17:46:14.93 ID:KEvh9jix0.net]
そこまでご丁寧に説明してやるのなら、「Cスタイルのキャストは使うな」、を教えるべきじゃねーの?

320 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 18:34:49.58 ID:mMEjLB3K0.net]
parent * が child * なのかも分からないのに強引にキャストするのか
そこまで型無視するなら void * でいいんじゃない 知らんけど

321 名前:はちみつ餃子 mailto:sage [2018/09/07(金) 20:57:02.69 ID:EL+7DMJm0.net]
>>313
せやな。



322 名前:はちみつ餃子 mailto:sage [2018/09/07(金) 20:57:32.70 ID:EL+7DMJm0.net]
C++ スタイルのキャストを、特に入門者の内は static_cast だけ使っておけばまあまあ大丈夫。
static_cast でエラーになるような変換は C++ 的にはだいたいイケてないやつ。

323 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 20:59:50.93 ID:/+XJI6DP0.net]
アホか
dynamic_castが使えないくせに初心者皆伝なんぞやれん

324 名前: mailto:sage [2018/09/07(金) 22:12:33.50 ID:WaHB6+zk0.net]
>>303
>私は std::shared_ptr を GC だと思ってるよ。
…GC発祥の地 lisp の使い手のはちみつさんがそうおっしゃるのなら、私の中の定義も書き換えないといけませんね
mark and sweep GC って、プログラム本体とは関係のないところで、それこそメモリの死にビットをも使ったりして、ごそごそやる、というイメージがあります

>解放のタイミングがコンパイル時に確定しないようなのは GC だろってくらいのカジュアルな認識
>std::shared_ptr と GC を隔てるのは何

「解放のタイミングを図る機構が表のプログラムとは独立している」
くらいでしょうか?表のプログラムからの参照が途切れることと free() されることに直接の関係性がない mark and sweep とその発展型のみを GC とみなしています
といって、GC の本は一冊しか持っていません

325 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 22:36:10.40 ID:OXR/kEGJ0.net]
は○ち○餃子はLisperか

言語選びは慎重にな!
ttps://postd.cc/lisping-at-jpl/

326 名前:はちみつ餃子 mailto:sage [2018/09/07(金) 22:37:40.84 ID:EL+7DMJm0.net]
>>318
定義がひとつでなきゃならないとは思ってないよ。
だから自分なりに一貫した考え方があるのなら、それはそれでいいんじゃないかな。

ただ、「表の機構と分離されているか」という考え方だと、それは抽象化の仕方であって、メカニズム (アルゴリズム) の基準ではないね。
その基準だと std::shared_ptr が GC ではないとは言えても参照カウンタが GC ではないとは言えない。

327 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 22:45:54.86 ID:Gz5E8uWmd.net]
お返事遅れました>>213です
Overlappedの設定をCreateNamedPipe時点に引数として渡す構造体ことで同期制御を実現できました
ありがとうございました

メモリリーク探しきつい....

328 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 22:58:55.32 ID:nLV7kBrTa.net]
すみません質問があります

メインスレッドと通信スレッドがいて、
通信スレッドはメインスレッドのオブジェクトポインタ持ってます
メインスレッドはクラス化されており、スレッド用のstatic関数以外にもメンバ関数を持っています

通信スレッドがデータ受信して、メインスレッドの別のメンバ関数を呼び出した時、
メインスレッドで実行していた処理はどうなるのでしょうか?

メインスレッドで実行していた処理はあくまでもstaticな関数の処理で、staticでない他のメンバ関数は別に処理されるのでしょうか?

329 名前:はちみつ餃子 mailto:sage [2018/09/07(金) 23:04:25.63 ID:EL+7DMJm0.net]
>>322
説明が分かり難いなぁ。

通信スレッドとやらから呼び出した関数は通信スレッド上で走っているし、
メインスレッドはメインスレッドで走っている。

330 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 23:21:53.12 ID:nLV7kBrTa.net]
>>323
分かりずらくて申し訳ありません..
もし通信スレッドで呼び出した別のメンバ関数内でメンバ変数を変更した場合、
メインスレッドでもメンバ変数の変更値を参照できるのでしょうか

331 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 23:22:52.89 ID:RvuhpJx80.net]
スレッドとメモリの関係がよく分かってないようだ



332 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 23:23:07.46 ID:OXR/kEGJ0.net]
微妙な質問キタ

333 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 23:23:45.59 ID:KDtg+GuV0.net]
解放のタイミングがコンパイル時に確定しないのは shared_ptr でも同じでしょ。
任意のshared_ptrインスタンスを別のインスタンスにコピーした場合、解放のタイミングはコンパイル時に確定できない。

334 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 23:25:23.60 ID:RvuhpJx80.net]
vectorがconstexpr対応できるならshared_ptrもできそう

335 名前:デフォルトの名無しさん [2018/09/07(金) 23:26:09.70 ID:B/yxkRYZ0.net]
staticなメンバ関数ではstaticなメンバ変数しか参照できない
staticでないメンバ関数はstaticな変数もstaticでない変数も参照できる

staticなメンバ関数とstaticでないメンバ関数が作用しあうのであれば、
当然staticな変数になる

はっきりいってな
staticな変数はグローバル変数と同じだからな
とうぜん同じ実体の変数を参照することになる

336 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 23:26:58.48 ID:OXR/kEGJ0.net]
>>329は視野が広い人じゃなかったのか!?

337 名前:デフォルトの名無しさん [2018/09/07(金) 23:29:06.23 ]
[ここ壊れてます]

338 名前: ID:B/yxkRYZ0.net mailto: > スレッド用のstatic関数以外にもメンバ関数を持っています

> 通信スレッドがデータ受信して、メインスレッドの別のメンバ関数を呼び出した
> 通信スレッドで呼び出した別のメンバ関数内でメンバ変数を変更した

まず低学歴知恵遅れは質問を読解する能力がない
[]
[ここ壊れてます]

339 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 23:35:54.69 ID:OXR/kEGJ0.net]
こりゃーもう>>324には>>331に回答してもらうしか

340 名前:はちみつ餃子 mailto:sage [2018/09/07(金) 23:38:50.05 ID:EL+7DMJm0.net]
>>324
出来るが、データ競合が起こらないように気を付けよう。

341 名前:はちみつ餃子 mailto:sage [2018/09/07(金) 23:41:24.38 ID:EL+7DMJm0.net]
質問者が状況を理解してない説明をしてるから本当に回答になってるのかイマイチわからぬ。
無理に言葉にしようとせずにコードを示してくれた方がいいんだがなぁ。



342 名前:デフォルトの名無しさん [2018/09/07(金) 23:41:30.87 ID:B/yxkRYZ0.net]
バカじゃなければ
普通にアドレスが固定されてるstaticなメンバ関数のアドレスを
スレッドを開始させるアドレスにしてると推定できるからな

343 名前:デフォルトの名無しさん [2018/09/07(金) 23:46:20.44 ID:B/yxkRYZ0.net]
このスレのバカどもはスレッドなんか
なんも分かってないからな

質問するヤツもバカになにを聞いてもムダだからな
そこの理解は必要

344 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 23:56:01.03 ID:OXR/kEGJ0.net]
>>335
>スレッドを開始させるアドレス
さすあに
スレッドを起こす質問に解釈しやがった;;

>>322
>メインスレッドはクラス化されており
>通信スレッドはメインスレッドのオブジェクトポインタ持ってます
と、>>324
>メインスレッドでもメンバ変数の変更値を参照できるのでしょうか
からすると通信スレッドで変更したメモリをメインスレッドでも参照できるのかという質問かとオモタわ;;;

345 名前:デフォルトの名無しさん [2018/09/07(金) 23:58:34.82 ID:B/yxkRYZ0.net]
> 通信スレッドはメインスレッドのオブジェクトポインタ持ってます

まず一番最初に書いてることが読めてない
致命的な頭のワルサといっていい

346 名前:デフォルトの名無しさん [2018/09/08(土) 00:00:18.18 ID:j/6nk0eH0.net]
普通にメインスレッドのメンバ関数呼び出して
メインスレッドのメンバ変数を変更すると読めるからな

こんだけコミュニケーションレベルが低いと
実生活でも支障があるレベルといっていい

347 名前:デフォルトの名無しさん mailto:sage [2018/09/08(土) 00:03:28.41 ID:VqyCCBP80.net]
>>330
半角クンは自分の見たいものしか見えない、すなわち常に半角クンの中ではすべてのものを見通している視野100%ということなのだろう

348 名前:デフォルトの名無しさん mailto:sage [2018/09/08(土) 00:04:14.21 ID:49ssh0n4a.net]
>>333
mutexしときます
いろいろアドバイスありがとうございます
>>329ですね

349 名前:デフォルトの名無しさん [2018/09/08(土) 00:06:40.10 ID:j/6nk0eH0.net]
まずなこのスレの低学歴知恵遅れたちは
自分たちがどんだけ低学歴知恵遅れかという自覚がない

致命的といっていい

350 名前:デフォルトの名無しさん mailto:sage [2018/09/08(土) 00:18:54.01 ID:6MRSNGru0.net]
低学歴知恵遅れなので質問の解釈に関する>>337>>339の違いがわからんが、

それはそうとして、当初の疑問に戻るが視野の広い>>342
>とうぜん同じ実体の変数を参照することになる
には一切注釈をつけなくて良かったの?

351 名前:デフォルトの名無しさん [2018/09/08(土) 00:20:24.81 ID:j/6nk0eH0.net]
また低学歴知恵遅れが負け惜しみ意味不明なこといってるしな
低学歴知恵遅れの負けず嫌いは異常だからな



352 名前:デフォルトの名無しさん [2018/09/08(土) 00:22:38.67 ID:j/6nk0eH0.net]
低学歴知恵遅れほど自尊心だけは高い
コレは底辺に多い

そして自分がゴミクズの低学歴知恵遅れである自覚もない

つまり救いようがない

353 名前:デフォルトの名無しさん [2018/09/08(土) 00:30:51.48 ID:j/6nk0eH0.net]
低学歴知恵遅れの底辺ゴミクズほど自己評価だけは高い

その根拠のない自己評価の高さは
どこからくるものなかははっきりとは分からない

低学歴知恵遅れの底辺ゴミクズほどそういう傾向がある
それは経験からかなり相関が高いと確信している

354 名前: mailto:sage [2018/09/08(土) 00:31:21.19 ID:t7GfMYxV0.net]
みなさん厳しいですね…
私は質問側ですが、そして今 schme スレで質問を丸投げしちゃっていますが、わからないときは、なにがわからないかわからない、という感じだったりしています

>>324
なにか断片的でいいからコード例をあげていただくと嬉しいです、例えば https://ideone.com/VvdMRl

355 名前:デフォルトの名無しさん [2018/09/08(土) 00:45:27.68 ID:j/6nk0eH0.net]
むしろこのスレの低学歴知恵遅れの底辺ゴミクズたちは
質問してるヤツのレベルにすら到達してない

356 名前: []
[ここ壊れてます]

357 名前:デフォルトの名無しさん mailto:sage [2018/09/08(土) 00:46:44.54 ID:49ssh0n4a.net]
>>347
pthread使ってる以外はほぼ同等な考え方です
実例作っていただきありがとうございます。

358 名前:デフォルトの名無しさん mailto:sage [2018/09/08(土) 01:03:30.65 ID:6MRSNGru0.net]
>>326で書いたとおりスレッドAで変更したメモリをスレッドBで正しく参照できるのか否かというのは
微妙な問題なんじゃ

>>347のコードでf::nの書き換えと参照が正しく動くのは
20行目のC::f()呼び出しで呼び出されたstd::coutがメモリバリア的な効果を果たしたに過ぎないかもしれん
(中でmutexとかcritical sectionとかなシステムコールを呼んでいるなら普通のOSならメモリバリアが効く

と自尊心だけは高い低学歴知恵遅れなので難癖をつけておく
実証はしない

359 名前:デフォルトの名無しさん mailto:sage [2018/09/08(土) 01:10:28.57 ID:6MRSNGru0.net]
>>347のコードがそもそもC::nがvolatile宣言されていないのに安全に動いている理由は…
と始めると荒れる…!

それはともかくスレッド間のメモリの読み書きを>>341のmutexでガードするというのは大変良い心がけです
多少遅いかもしれないが遵守する限り泥沼に踏み込まずに済む

360 名前:デフォルトの名無しさん mailto:sage [2018/09/08(土) 01:32:58.78 ID:LCjnyCTn0.net]
>>322
メインスレッドとサブスレッドで並列に起動して同じ変数を書き換えた場合、書き換えレースになる。
ロックっていう機構があるのでそれを参照。

361 名前: mailto:sage [2018/09/08(土) 01:41:37.02 ID:t7GfMYxV0.net]
>>351
よろしければ教えていただけますか?

>20行目のC::f()呼び出しで呼び出されたstd::coutがメモリバリア的な効果を果たした
メモリバリアって要するに x86 の lfence, sfence, mfence のことですか?
これはCPUキャッシュがメインメモリに吐き出されることを保証するものですか?
これらの命令は Pentiumu2 あたりにはなかったと思います、でも Pen2 とか特に Celeron-BP6(abit) で普通にデュアルプロセッサできていたのはどうしてでしょうか?



362 名前:デフォルトの名無しさん mailto:sage [2018/09/08(土) 02:36:49.43 ID:6MRSNGru0.net]
>>353
>これはCPUキャッシュがメインメモリに吐き出されることを保証するものですか?
ちげう
実行したコアのライトコマンドキューかリードコマンドキュー上の命令をその場で全部実行してしまうというもの
キャッシュのinvalidateやfillが起きるかどうかとは別の話(結果的に起きることもあるが常にではない
キャッシュと関係あるみたいな説明のページがあることは承知しているが苦情は漏れに言わないでホスイ

>これらの命令は Pentiumu2 あたりにはなかったと思います、でも Pen2 とか特に Celeron-BP6(abit) で普通にデュアルプロセッサできていたのはどうしてでしょうか?
古代の話は知らん
OoO(アウトオブオーダー実行)はすでにあったはずなので、ライトコマンドキューやリードコマンドキューもすでにあった
全くの推測だが、キャッシュのinvalidate操作が(invalidateを常に伴うため効率の悪い)メモリバリアと同じ効果があったとかではないかいや知らんけど

363 名前:デフォルトの名無しさん mailto:sage [2018/09/08(土) 02:52:26.13 ID:6MRSNGru0.net]
ちなIA(Intel Architecture)のうちでも常識的なコア数のやつは
コア間のキャッシュコヒーレンシをハードウェアで勝手に取ってくれるので、
コア間のメモリ参照の不整合はメモリバリアだけ注意したら逝ける(キャッシュの存在は透過的






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](;´∀`)<321KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef