C++相談室 part135

2018/03/31(土) 20:20:06.25

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

前スレ
C++相談室 part134
http://mevius.5ch.net/test/read.cgi/tech/1516406742/

このスレもよろしくね。
【初心者歓迎】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/05/30(水) 18:55:49.81

強引にスレッドを殺すと、
そのスレッドが確保してたリソースが解放されないかもしれないぞ
メモリであったりセマフォだったりハンドルだったり

ちゃんと終了処理を追加しないとダメだよ

2018/05/30(水) 19:05:49.61

そのスレッドが使用するメモリ等のリソースを全て
スレッド終了まで保持していても

>>897
＞メモリを破壊しているようで全然別の箇所で色々なエラーが出てきます。system_errorは送出されていません。

となるなら、そもそもそのライブラリがスレッドセーフじゃないのかもしれない。

>>904式に別プロセス化するのが一番なのかもね

2018/05/30(水) 22:01:02.21

ぷぅうううううううううりいいいいいいいぃいいいいいいいいいずへーーーーーーーるぷみーーーーーーーーーー。

2018/05/31(木) 16:11:24.94

関数の中にif(cancel)return;みたいなのを大量に仕込んで外からフラグを立てて止めろ

2018/05/31(木) 19:02:31.60

基本的にはフラグで止めるか別プロセスで実行するのが定石だが
質問者は

>CPUは複数コアあるのでサブスレッドが走り続けてリソース開放が遅れるのは
>構わないのですがjoinするとそこで処理終了まで待ってしまうのでdetachしたいわけです。

と言ってるからなぁ

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-667V) · 2018/05/31(木) 20:27:20.65

join なんて、カラクリが良く分からないものを、よく使う気になるなぁ
私なら、チャイルドプロセスが自爆するように、陽に記述するなぁ

2018/05/31(木) 20:40:15.15

joinが嫌ならdetachすればいいのよ
パンがなければお菓子をたべればいいのよ

2018/05/31(木) 20:53:09.91

世の中には信じられないメンタリティの人がいるもんだなあ

2018/05/31(木) 21:03:58.91

join のカラクリは何も難しいことないと思うが

2018/05/31(木) 21:13:34.61

標準ライブラリが嫌ならpthread使えばいいのよ

**897** (ﾜｯﾁｮｲ bdab-b3FY) · 2018/05/31(木) 21:49:57.28

いろいろアドバイスありがとうございます。
どうもdetachした後に局所変数が確保されるとスタックを破壊してしまうようで、
局所変数を確保する前に>>911氏のいうようにif(cancel)return;入れるとLinuxでは落ちなくなりました。
ですが、windowsでは改善せず諦めました。atomicにするのものも面倒ですし。

結局キャンセルするときは結果を回収せず、さらに別スレッド立ち上げてjoinすることで
メインスレッドのGUIに制御が戻るようにしました。長期的には別プロセス化するしかなさそうですね。
ありがとうございました。

2018/05/31(木) 21:53:20.51

> 既存ライブラリなのでそうはいかず
って書いてあるのに>>905,>>907-908,>>911とかバカなら黙っとけよ...

2018/05/31(木) 22:35:57.56

913はスレッドを自爆させた後joinしないのであろう…

**デフォルトの名無しさん** · 2018/05/31(木) 22:51:40.57

子スレッドが一つならjoinで待っててもいいけど、複数個になったら無限ループで待つよね

2018/05/31(木) 22:52:12.55

ていうか「重い処理かつ終了に時間が要するスレッド」複数個を所有するサーバみたいなスレッドを一発噛ませて、
パラメータを変えたくなったら「現行スレッド停止」と「新しいパラメータでのスレッド起動」をサーバに対して指令するつくりにすれば
良い
この場合は「重い処理かつ終了に時間が要するスレッド」が終了するまで誰も待つ必要はなく（※サーバ終了時は除く
、サーバみたいなスレッドは、クライアントから「新しいパラメータでのスレッド起動」コマンドを受けたときおもむろに
「死んでる（再利用できる）スレッドはどれかいな～、」とタイムアウト0秒のjoinでポーリング式にサーチすれば良い

現行スレッドが死ぬまでの間現行スレッドと新たに起動するスレッドが並列に動くことになるが
>CPUは複数コアあるのでサブスレッドが走り続けてリソース開放が遅れるのは構わない
ということですしおすし、

2018/05/31(木) 22:56:14.51

>>921
ウィンドーズならWaitForMultipreObjects()とかその亜種で複数の終了待ちができうる
そうでなくともイベントフラグの同時待ちはだいたいどんなマルチタスクOSでもできるから
それを使って類似のしくみを作れうる、。

2018/05/31(木) 23:21:33.93

>>923
できうる、作れうるって日本語的におかしいだろう

2018/06/01(金) 04:04:16.74

ウインドーズとか何か別物感あるし、multipleのスペルもおかしいし大丈夫か

2018/06/01(金) 04:08:40.92

色々なところで糞が露呈している
それがWindows

2018/06/01(金) 04:11:32.11

デザインとしては Windows の方が現代的なんだけど、
色んなものが POSIX を基本にしたデザインになってるから噛み合わないんよなぁ。

2018/06/01(金) 04:16:04.83

POSIXに準拠できないWindowsがどうかしている

2018/06/01(金) 04:22:16.25

>>928
昔は POSIX 準拠にしてたよ。
アメリカの政府が採用するのに POSIX を要求してたみたいで、仕方なくやったって話。
だけど、基本的なモデルが違うものに API だけ接ぎ木してもなぁ。

2018/06/01(金) 04:43:45.31

windowsでpthread使うたびにトラブル起こってつら

2018/06/01(金) 08:14:44.74

>>921
他に条件があるならともかく、普通にjoinで待てばよくね？

2018/06/01(金) 08:27:54.49

>>922
joinしたら再利用できないだろ

**デフォルトの名無しさん** · 2018/06/01(金) 08:30:22.24

>>931
別に、joinで済むならjoinでいいんじゃね

2018/06/01(金) 09:15:20.19

キャンセルしたくなるほど長い処理ならスレッドキューイングする利点はない
もちろんしたいならしてもいい

2018/06/01(金) 09:35:53.16

C++を使うなら、Windowsでいいんじゃないの。
Clang、gcc、clと主要なコンパイラが動く貴重な環境だし。
文書を残さないといけないからアプリも必要。
図を描くのにvimでSVG書くって人もいるけど、流石にそれは労力の使い方を間違えてる。

2018/06/01(金) 10:01:00.93

サブスレッドでjoinして結果を使わない、というのとデタッチするのとどう違うんやろな。デタッチってなんのメリットあるんやろか。

2018/06/01(金) 10:15:36.25

自分で書いてる通り結果を使わなくて終了も待ちたくないなら join せずデタッチ。
メリットはリソース(スレッドハンドルなど待ち合わせ用リソース)の自動的な解放くらいか。

2018/06/01(金) 11:41:29.12

連結リストのクラス list があります。
addFirst
removeFirst

などのメンバ関数があります。

この list を継承して、 stack クラスを作ります。

stack クラスにはメンバ関数 push と pop があります。

push の中で addFirst を呼んでいます。
pop の中で removeFirst を呼んでいます。

stack クラスのインスタンスからは、 list クラスの addFirst, removeFirst などを
利用不可としたいのですが、どうすればいいのでしょうか？

: public list と継承するともちろんダメです。
: private list と継承すると push の中で呼んでいる addFirst が使えなくなってしまいます。

どうすればいいのでしょうか？

2018/06/01(金) 11:47:52.19

protect

**デフォルトの名無しさん** · 2018/06/01(金) 11:55:31.26

friend

2018/06/01(金) 11:55:48.39

・stack : protected listとして、必要なメンバをstackで明示的に公開する。
　　・listとstackのポインタに互換性がなくなる。

2018/06/01(金) 11:58:45.22

・assert、throw等で警告するだけのaddFirst、removeFirstをstack側に作りオーバーライドし、規約で使うなと言っておく。
　　・非常にダサい。

2018/06/01(金) 12:00:33.78

・基底クラスbasic_listを設け、そこからlistとstackを別に派生する。

2018/06/01(金) 12:12:54.27

>>935
釣りか？
MSYSがあるからなんとか我慢して作業できるが
仕事以外でそんな苦痛を受けながらプログラミングなんかしたくはない

2018/06/01(金) 12:31:43.05

>>944
wslでおｋ。

2018/06/01(金) 12:33:20.56

wslを有効にしてコルタナにウブンツと言えばすぐ使えます。

2018/06/01(金) 12:41:08.30

wslでWindowsネイティブなバイナリ作れんの？

2018/06/01(金) 12:43:01.01

>>944
> 仕事以外でそんな苦痛
でもどんな苦痛なのかは書けない w

2018/06/01(金) 12:44:36.05

さあどうだろ？
Linux側からWindowsのファイルは読めるけど。
環境設定が大変そうだな。
逆にWindows側からLinuxのファイルを直接変更したらだめらしい。

2018/06/01(金) 12:47:41.68

俺のおすすめの使い方は、Windowsバイナリはcl、Linuxバイナリはwsl上のgccで作る。
開発環境はVisual Studio2017、CMakeプロジェクトを使う。
これだけでWindowsとLinux両方対応できる。

2018/06/01(金) 12:51:07.74

>>950
それ良さそうだな
今度試してみる

2018/06/01(金) 13:01:33.50

>>939-943

ありがとうございました。

Macを使っている人はいませんか？
コンピュータサイエンティストって大抵Macのノートパソコンを使っているイメージがあります。

2018/06/01(金) 13:11:39.88

>>952
mac使ったところでmacしか使えないだけ
本物になりたいならシェアが高いウインドゥスを使え
もしくはLinux

2018/06/01(金) 13:29:21.95

>>944
別に補陀落渡海しても良いのよ

2018/06/01(金) 13:30:34.27

>>952
Macの内部はUnixだから

2018/06/01(金) 16:26:14.37

>>952
念の為、標準ライブラリにlistもstackもあるからね。
あと標準ライブラリのlistは継承して使えるように設計されてないからね

2018/06/01(金) 18:47:58.65

リスト構造のスタックなんて簡単なんだからゼロから作っちゃえば？

2018/06/01(金) 18:52:33.22

push pop size
copy move swap constructor destructor
くらいでしょ使うの
片方向でもいいだろうし

2018/06/01(金) 19:38:34.27

stackはlistではないし継承は間違ってるわな

2018/06/01(金) 19:48:21.87

俺、リストツリーっていうの考えたんだけど、聞きたい？

2018/06/01(金) 19:58:07.59

>>959
頭が硬いやつはソフトに向いてない

2018/06/01(金) 20:19:59.69

>>953
>>955

ありがとうございました。

>>956-959

実は、

最近出版された岩沼宏冶他著『データ構造とアルゴリズム』（コロナ社）
という本にスタックとキューのそのような実装が書いてあるんです。
まず連結リストをテンプレートを使って実装しています。

その関係で質問しました。

まえがきに「本書の前半ではC++言語での実装コードを示すが、これは
初学者によいコードを読ませることが目的であり、Art of Programmingに
つながるような解説を付記するように努力する。」と書いてあります。

2018/06/01(金) 21:27:36.17

下手が伝染るから、クヌースを取り寄せしたほうが良いぞ

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-667V) · 2018/06/01(金) 21:36:56.16

>>938
私なら委譲を使います

2018/06/01(金) 21:52:15.80

>>933
どんな用途を想定してるの？

2018/06/02(土) 01:50:36.43

>>965
横レスだけど複数スレッドがあったとき
・どれかの終了を待つならjoinでは無理
・全ての終了を待つなら適当な順でjoin
というだけのことでは

2018/06/02(土) 07:25:22.85

>>938
そういうことをやるなっていうのが「リスコフの置換原則」

2018/06/02(土) 07:40:27.42

「外から見えるインターフェースが変わらなければ
内部の具体的な実装がまったくの別物に変わっても使うのに支障ない」
ていうオブジェクト指向のカプセル化だっけ、あのあたりの教材じゃなかろうか。

それと継承のアクセス制御の使い方。

2018/06/02(土) 11:23:31.53

派生クラスのアクセス制御、と書くべきだったかな。
意味は通じると思うけど、用語の使い方に厳しい人もいる故。

2018/06/02(土) 13:02:49.13

>>932
言葉足らずだったｽﾏﾝ
スレッドハンドルの配列があったとして、[i]についてjoinしたら[i]を再利用できる（再びスレッドをcreateしなおせば良い
、の意味

joinせずとも済むやり方もあるが、
（「重い処理かつ終了に時間が要するスレッド」の関数本体をそのままスレッドにするのではなしに、
普段イベントを待ち、イベントが来たら「重い処理かつ終了に時間が要するスレッド」の関数本体を普通にcallし、そいつがreturnしてきたら
　再びイベントを待つ、というループするスレッドとしてwrapすれば良い、等
結局「重い処理かつ終了に時間が要するスレッド」が使っていた資源が開放されたことを論理的に知る必要からは逃れられず、
一番簡単なのがjoinですよという意味で>>922ではjoinと言ったので察してﾎｽｲ、

2018/06/02(土) 17:26:29.14

ほむほむ、ところでgtestとBoost.Testはどっちが良いですかな？

2018/06/03(日) 18:24:16.97

初心者脱出したいから課題くれ

2018/06/03(日) 20:26:24.96

>>972
自分でこれまで勉強した範囲で疑問なり興味なり沸いてきて、あれこれコード書いて試して見ようとしたことは無かったの？
もし全くないのならもう諦めた方がいい。

2018/06/03(日) 23:46:44.76

>>972
純粋な言語部分
プリプロセッサ
標準ライブラリ
特定のOS, 特定のライブラリ
組み込み

どの辺の課題？

2018/06/03(日) 23:58:49.35

「計算機プログラムの構造と解釈」（SICP）を読んで演習課題を解いたら良い

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-667V) · 2018/06/04(月) 19:13:33.43

>>975
まだ scheme 手習いが終わっていないのです（泣）

2018/06/06(水) 22:04:43.09

リトルインディアン、ビッグインディアンも教えない職場があるんだな。

おっさん、びっくりしたわ。

2018/06/06(水) 22:13:02.59

>>977
周知のこととして扱われているのかもしれませんね。
私は学校で教わりました。

**デフォルトの名無しさん** · 2018/06/06(水) 22:41:41.43

>>977
インディアンかー
俺も教わった覚えないな

2018/06/06(水) 23:17:12.31

One little, two little, three little Indians

2018/06/06(水) 23:33:53.26

エンディアンなのかインディアンだったかいつも忘れる
口語は混ざる

2018/06/06(水) 23:36:43.24

>>979
インディアンは習ったろ

**デフォルトの名無しさん** · 2018/06/06(水) 23:48:14.36

>>982
ネイティブアメリカンなら習ったけど🙄

2018/06/06(水) 23:48:33.17

ガリバー旅行記はいつどこで習うんだろう

2018/06/07(木) 06:56:59.11

「リトル・エンディアン」「ビッグ・エンディアン」て用語は
『ガリバー旅行記』が由来、という情報が載ってるサイトで、
主人公が漂着した小人の国、巨人の国のエピソードから…、とか
書いてあるのを見たことがある。ネタだったのかも知れないけど。

◆QZaw55cn4c (ﾜｯﾁｮｲ d360-EqDK) · 2018/06/07(木) 08:03:30.91

>>985
それはほんと、小人国での卵の割り方にちなみます

**デフォルトの名無しさん** · 2018/06/07(木) 08:17:13.03

>>986
ニホンゴムズカシイネ^^

2018/06/07(木) 11:07:30.43

>>977
今どきバイトオーダー意識するようなプログラム書くような職場じゃなきゃ教えないよ
アライメントなんかも同様

2018/06/07(木) 11:22:48.86

インディアンを教える職場って
どんな職場だよ

2018/06/07(木) 11:49:27.36

だってオラはSEだから

2018/06/07(木) 12:38:00.08

SEなら尚更知っておかないと
日本はなんちゃってSEばっかだもんなｗ

2018/06/07(木) 13:14:35.77

SEとインディアンの関係は？

**985** (ﾜｯﾁｮｲ d193-HI6s) · 2018/06/07(木) 13:15:06.93

>>986 調べたら小人同士の戦争の原因なのね。巨人国は関係ないな。
実は空の国の「学者の無意味な論争」の一例だと思い込んでいたんだわ。

>>989 「ウチはCのコーディングスタイルとしてAT&T式を基本とします」
ってところはあるかも知れん。

2018/06/07(木) 20:44:47.09

>>988
貴様が知る必要はない！

2018/06/07(木) 20:48:11.43

何でもネットに繋がらなきゃならないこの時代にhtolやltohを避けて通れるもんなのか？
PHPしか触らないWeb屋ならともかくここC++スレだぞ

2018/06/07(木) 21:46:11.03

今時C++と言えどhtol()とかltoh()なんて低レイヤーの関数使うことなんて滅多にないだろ

2018/06/07(木) 21:50:55.26

>>995
ソフトウェアがなんでもかんでもネットワークに繋ぐ必要があると思ってるの？ここC++スレだぞ

**デフォルトの名無しさん** · 2018/06/07(木) 22:31:28.79

C++使うくらいだからXMLとかJSON使うんだろ

2018/06/07(木) 23:10:47.05

>>998
utf16はどうしたらいいの？

2018/06/07(木) 23:16:41.18

続きはwebで

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 68日 2時間 56分 35秒