C++相談室 part135
レス数が1000を超えています。これ以上書き込みはできません。
次スレを立てる時は本文の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 重い処理の方を別プログラムのプロセスにしちゃって止めるときはブチ殺すのがシンプルで良さそうに見える >>903
async つかえ。
wait_forっていう関数がプロミスにある。 基本的にstd::threadでキャンセルは不可能。
自分でそういう機構を汲んでやらないといけない。
whileの実行をキャンセルするbool変数つっこむとか。
それでもクリティカルパスの実行は避けられない。 強引にスレッドを殺すと、
そのスレッドが確保してたリソースが解放されないかもしれないぞ
メモリであったりセマフォだったりハンドルだったり
ちゃんと終了処理を追加しないとダメだよ そのスレッドが使用するメモリ等のリソースを全て
スレッド終了まで保持していても
>>897
＞メモリを破壊しているようで全然別の箇所で色々なエラーが出てきます。system_errorは送出されていません。
となるなら、そもそもそのライブラリがスレッドセーフじゃないのかもしれない。
>>904式に別プロセス化するのが一番なのかもね ぷぅうううううううううりいいいいいいいぃいいいいいいいいいずへーーーーーーーるぷみーーーーーーーーーー。 関数の中にif(cancel)return;みたいなのを大量に仕込んで外からフラグを立てて止めろ 基本的にはフラグで止めるか別プロセスで実行するのが定石だが
質問者は
>CPUは複数コアあるのでサブスレッドが走り続けてリソース開放が遅れるのは
>構わないのですがjoinするとそこで処理終了まで待ってしまうのでdetachしたいわけです。
と言ってるからなぁ join なんて、カラクリが良く分からないものを、よく使う気になるなぁ
私なら、チャイルドプロセスが自爆するように、陽に記述するなぁ joinが嫌ならdetachすればいいのよ
パンがなければお菓子をたべればいいのよ 世の中には信じられないメンタリティの人がいるもんだなあ 標準ライブラリが嫌ならpthread使えばいいのよ いろいろアドバイスありがとうございます。
どうもdetachした後に局所変数が確保されるとスタックを破壊してしまうようで、
局所変数を確保する前に>>911氏のいうようにif(cancel)return;入れるとLinuxでは落ちなくなりました。
ですが、windowsでは改善せず諦めました。atomicにするのものも面倒ですし。
結局キャンセルするときは結果を回収せず、さらに別スレッド立ち上げてjoinすることで
メインスレッドのGUIに制御が戻るようにしました。長期的には別プロセス化するしかなさそうですね。
ありがとうございました。 > 既存ライブラリなのでそうはいかず
って書いてあるのに>>905,>>907-908,>>911とかバカなら黙っとけよ... 913はスレッドを自爆させた後joinしないのであろう… 子スレッドが一つならjoinで待っててもいいけど、複数個になったら無限ループで待つよね ていうか「重い処理かつ終了に時間が要するスレッド」複数個を所有するサーバみたいなスレッドを一発噛ませて、
パラメータを変えたくなったら「現行スレッド停止」と「新しいパラメータでのスレッド起動」をサーバに対して指令するつくりにすれば
良い
この場合は「重い処理かつ終了に時間が要するスレッド」が終了するまで誰も待つ必要はなく（※サーバ終了時は除く
、サーバみたいなスレッドは、クライアントから「新しいパラメータでのスレッド起動」コマンドを受けたときおもむろに
「死んでる（再利用できる）スレッドはどれかいな〜、」とタイムアウト0秒のjoinでポーリング式にサーチすれば良い
現行スレッドが死ぬまでの間現行スレッドと新たに起動するスレッドが並列に動くことになるが
>CPUは複数コアあるのでサブスレッドが走り続けてリソース開放が遅れるのは 構わない
ということですしおすし、 >>921
ウィンドーズならWaitForMultipreObjects()とかその亜種で複数の終了待ちができうる
そうでなくともイベントフラグの同時待ちはだいたいどんなマルチタスクOSでもできるから
それを使って類似のしくみを作れうる、。 >>923
できうる、作れうるって日本語的におかしいだろう ウインドーズとか何か別物感あるし、multipleのスペルもおかしいし大丈夫か 色々なところで糞が露呈している
それがWindows デザインとしては Windows の方が現代的なんだけど、
色んなものが POSIX を基本にしたデザインになってるから噛み合わないんよなぁ。 POSIXに準拠できないWindowsがどうかしている >>928
昔は POSIX 準拠にしてたよ。
アメリカの政府が採用するのに POSIX を要求してたみたいで、仕方なくやったって話。
だけど、基本的なモデルが違うものに API だけ接ぎ木してもなぁ。 windowsでpthread使うたびにトラブル起こってつら >>921
他に条件があるならともかく、普通にjoinで待てばよくね？ >>931
別に、joinで済むならjoinでいいんじゃね キャンセルしたくなるほど長い処理ならスレッドキューイングする利点はない
もちろんしたいならしてもいい C++を使うなら、Windowsでいいんじゃないの。
Clang、gcc、clと主要なコンパイラが動く貴重な環境だし。
文書を残さないといけないからアプリも必要。
図を描くのにvimでSVG書くって人もいるけど、流石にそれは労力の使い方を間違えてる。 サブスレッドでjoinして結果を使わない、というのとデタッチするのとどう違うんやろな。デタッチってなんのメリットあるんやろか。 自分で書いてる通り結果を使わなくて終了も待ちたくないなら join せずデタッチ。
メリットはリソース(スレッドハンドルなど待ち合わせ用リソース)の自動的な解放くらいか。 連結リストのクラス list があります。
addFirst
removeFirst
などのメンバ関数があります。
この list を継承して、 stack クラスを作ります。
stack クラスにはメンバ関数 push と pop があります。
push の中で addFirst を呼んでいます。
pop の中で removeFirst を呼んでいます。
stack クラスのインスタンスからは、 list クラスの addFirst, removeFirst などを
利用不可としたいのですが、どうすればいいのでしょうか？
: public list と継承するともちろんダメです。
: private list と継承すると push の中で呼んでいる addFirst が使えなくなってしまいます。
どうすればいいのでしょうか？ ・stack : protected listとして、必要なメンバをstackで明示的に公開する。
・listとstackのポインタに互換性がなくなる。 ・assert、throw等で警告するだけのaddFirst、removeFirstをstack側に作りオーバーライドし、規約で使うなと言っておく。
・非常にダサい。 ・基底クラスbasic_listを設け、そこからlistとstackを別に派生する。 >>935
釣りか？
MSYSがあるからなんとか我慢して作業できるが
仕事以外でそんな苦痛を受けながらプログラミングなんかしたくはない wslを有効にしてコルタナにウブンツと言えばすぐ使えます。 wslでWindowsネイティブなバイナリ作れんの？ >>944
> 仕事以外でそんな苦痛
でもどんな苦痛なのかは書けない w さあどうだろ？
Linux側からWindowsのファイルは読めるけど。
環境設定が大変そうだな。
逆にWindows側からLinuxのファイルを直接変更したらだめらしい。 俺のおすすめの使い方は、Windowsバイナリはcl、Linuxバイナリはwsl上のgccで作る。
開発環境はVisual Studio2017、CMakeプロジェクトを使う。
これだけでWindowsとLinux両方対応できる。 >>939-943
ありがとうございました。
Macを使っている人はいませんか？
コンピュータサイエンティストって大抵Macのノートパソコンを使っているイメージがあります。 >>952
mac使ったところでmacしか使えないだけ
本物になりたいならシェアが高いウインドゥスを使え
もしくはLinux >>952
念の為、標準ライブラリにlistもstackもあるからね。
あと標準ライブラリのlistは継承して使えるように設計されてないからね リスト構造のスタックなんて簡単なんだからゼロから作っちゃえば？ push pop size
copy move swap constructor destructor
くらいでしょ使うの
片方向でもいいだろうし stackはlistではないし継承は間違ってるわな 俺、リストツリーっていうの考えたんだけど、聞きたい？ >>953
>>955
ありがとうございました。
>>956-959
実は、
最近出版された岩沼宏冶他著『データ構造とアルゴリズム』（コロナ社）
という本にスタックとキューのそのような実装が書いてあるんです。
まず連結リストをテンプレートを使って実装しています。
その関係で質問しました。
まえがきに「本書の前半ではC++言語での実装コードを示すが、これは
初学者によいコードを読ませることが目的であり、Art of Programmingに
つながるような解説を付記するように努力する。」と書いてあります。 下手が伝染るから、クヌースを取り寄せしたほうが良いぞ >>965
横レスだけど複数スレッドがあったとき
・どれかの終了を待つならjoinでは無理
・全ての終了を待つなら適当な順でjoin
というだけのことでは >>938
そういうことをやるなっていうのが「リスコフの置換原則」 「外から見えるインターフェースが変わらなければ
内部の具体的な実装がまったくの別物に変わっても使うのに支障ない」
ていうオブジェクト指向のカプセル化だっけ、あのあたりの教材じゃなかろうか。
それと継承のアクセス制御の使い方。 派生クラスのアクセス制御、と書くべきだったかな。
意味は通じると思うけど、用語の使い方に厳しい人もいる故。 >>932
言葉足らずだったｽﾏﾝ
スレッドハンドルの配列があったとして、[i]についてjoinしたら[i]を再利用できる（再びスレッドをcreateしなおせば良い
、の意味
joinせずとも済むやり方もあるが、
（「重い処理かつ終了に時間が要するスレッド」の関数本体をそのままスレッドにするのではなしに、
普段イベントを待ち、イベントが来たら「重い処理かつ終了に時間が要するスレッド」の関数本体を普通にcallし、そいつがreturnしてきたら
再びイベントを待つ、というループするスレッドとしてwrapすれば良い、等
結局「重い処理かつ終了に時間が要するスレッド」が使っていた資源が開放されたことを論理的に知る必要からは逃れられず、
一番簡単なのがjoinですよという意味で>>922ではjoinと言ったので察してﾎｽｲ、 ほむほむ、ところでgtestとBoost.Testはどっちが良いですかな？ >>972
自分でこれまで勉強した範囲で疑問なり興味なり沸いてきて、あれこれコード書いて試して見ようとしたことは無かったの？
もし全くないのならもう諦めた方がいい。 >>972
純粋な言語部分
プリプロセッサ
標準ライブラリ
特定のOS, 特定のライブラリ
組み込み
どの辺の課題？ 「計算機プログラムの構造と解釈」（SICP）を読んで演習課題を解いたら良い >>975
まだ scheme 手習いが終わっていないのです（泣） リトルインディアン、ビッグインディアンも教えない職場があるんだな。
おっさん、びっくりしたわ。 >>977
周知のこととして扱われているのかもしれませんね。
私は学校で教わりました。 >>977
インディアンかー
俺も教わった覚えないな One little, two little, three little Indians エンディアンなのかインディアンだったかいつも忘れる
口語は混ざる 「リトル・エンディアン」「ビッグ・エンディアン」て用語は
『ガリバー旅行記』が由来、という情報が載ってるサイトで、
主人公が漂着した小人の国、巨人の国のエピソードから…、とか
書いてあるのを見たことがある。ネタだったのかも知れないけど。 >>985
それはほんと、小人国での卵の割り方にちなみます >>977
今どきバイトオーダー意識するようなプログラム書くような職場じゃなきゃ教えないよ
アライメントなんかも同様 SEなら尚更知っておかないと
日本はなんちゃってSEばっかだもんなｗ >>986 調べたら小人同士の戦争の原因なのね。巨人国は関係ないな。
実は空の国の「学者の無意味な論争」の一例だと思い込んでいたんだわ。
>>989 「ウチはCのコーディングスタイルとしてAT&T式を基本とします」
ってところはあるかも知れん。 何でもネットに繋がらなきゃならないこの時代にhtolやltohを避けて通れるもんなのか？
PHPしか触らないWeb屋ならともかくここC++スレだぞ 今時C++と言えどhtol()とかltoh()なんて低レイヤーの関数使うことなんて滅多にないだろ >>995
ソフトウェアがなんでもかんでもネットワークに繋ぐ必要があると思ってるの？ここC++スレだぞ C++使うくらいだからXMLとかJSON使うんだろ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 68日 2時間 56分 35秒 レス数が1000を超えています。これ以上書き込みはできません。
