C++相談室 part153
■ このスレッドは過去ログ倉庫に格納されています
>>309
デストラクタは何もないので
どこかでメモリ処理がおかしくなってるんでしょうね…
一旦、動くようにしてみたかったのですが、もうちょっと調べてみます。
ありがとうございました。 そういうときに役に立つのがprintfデバッグだろ
どの工程で起こったのかある程度目星がつく >>321
継承元の親クラスを何個も辿ってよく調べたら
コンストラクタの中で怪しいポインタにアクセスしている個所がありました。
おそらくこれが原因だと思います。
皆さん有難うございました。 デストラクタとdelete演算子はデフォルトでnoexceptなんで、
例外発生時点で異常終了してしまい、try〜catchじゃ捕まえられないそうだ。
https://cpprefjp.github.io/lang/cpp11/noexcept.html そういう問題じゃねえよ
不定のポインタは検出不能だ いや、今回の問題の解決のために書いたわけではなくて、
>>308のように書いても無駄だと伝えるために書いた。
そのあたり明示せずに書き込んですまん。 atexit()
exit()
で捕捉出来ないかな デバッガに頼るのは甘え
プロはprintfだけで正しくデバッグする! プロは logger 使うし
百歩譲っても使うのは fprintf の方 printfが使える環境ならな
そうでない場面がごまんとあるから
選択肢は多いに越したことはない 基本的にprintfデバッグの延長
制度化体系化されたprintfデバッグがログ取り
loggerはより高度なprintfデバッグであり、その基本がprintfデバッグになる
この変数を眺めりゃ万事OK という直感が涵養される
loggerの出力先が10万キロ離れたプリンタなこともある C#を作ったアンダース・ヘルスバーグもデバッガのステップ実行よりもprintfを使うってインタビューで言ってたな >>300
C のポインタ、特に関数ポインタ、とか
リカーシブ、とかで十分でしょう >>334
でも最初のうち、プログラムが小さいうちは、それが一番手っ取り早いですね printf デバッグは完成後に printf の行を消すと動かなくなったりするω 関数化やクラス化でプログラムを小さくするわけで、あんまり関係ないな
assertを使うときもそうだが、デバッグ用のコードに副作用を入れちまうのはヘボ以下 デバッグOffして弊害残すヤツは動作の仕組み把握出来てないだけだろ
>>336、まず貴様のコーディングセンスを磨いてから出直してこい青二才 非同期で動くブツ同士の通信はprintfデバッグ大活躍なのでは…
誰がいつ何を呼んで何を渡したのかと呼ばれたほうが本当に受け取ったのかがすぐワカル
printf消去忘れについては条件コンパイルを使えば良いし、
Ad-hocな追加ならいかに大量にやってもソースコード管理システムで安全に消すこともできるわけやし、 未定義動作踏んでるときとかにprintfを呼び出すことでたまたま動くようにできたりする
ということか >本当に受け取ったのかがすぐワカル
buffer flush しないと判らんし
flush すると勝手に改行する環境とかあるし
そこまで便利ってほどでもなくね
nonbuffered しろってか ここまでの話をまとめると
やはりprintfデバッグが最強、ということですね #ifdef DEBUG
#define PUTCHAR(a) (putchar(a), fputc(a, _fpDbg))
#else
#define PUTCHAR(a) (putchar(a))
#endif
PUTCHAR(*ptr++);
みたいなことをやれば デバッグ時だけ*ptr++ が二回評価されて結果は変わってしまう。 >>343
インライン関数に置き換えられるだろ
少しは頭使え >>344
そんなことは当たり前。
IQが低い人と話すとこれだから困る。 >>347
駄目な例を敢えて書いたんだ。
どうしてそれが分からないの、あなた達には?
IQが高い人には駄目な例が単なる例として出されたのだと分かるのに
ここの人達にはそれがわからない。 >>339
非同期なアプリでprintf使うとタイミングが変わることがあるから安心できんな
デバッガよりは遥かに良いけど >>336 が
「printf デバッグは完成後に printf の行を消すと動かなくなったりするω」
と書いていたが、>>340が指摘した理由だけではないので、
そうなる他の理由の1例を>>343で書いた。 これが考える力なんだよ。
マスコミを含めて「知識知識」と言う人が多いが、生まれつきの頭が悪いと
>>344 >>347 のような馬鹿な発想しか出来ないのでどうにもなら無い。
俺に比べれば、おまえが池沼の癖に。 マクロを使う必要性が全く感じられなくてリアリティがない >>351
おまえ自分のこと頭おかしいと思わないならかなり進んだ病気だな >>350
たぶんみんなは
そりゃマクロ使えば何でもありありだろ
そんなことでドヤるとかバカじゃねーの
って思ってる… >>335
printfデバッグを肯定するとは
ロートルの吹きだまり感かなりある printfごときで騒いでる方が精神いかれてんだろ。。 今はJTAGがあるので、そんなにお金がかからない。
それでも、プロセッサごとにデバッグ環境を用意できるわけないだろ!!というのが日本企業の現状なら、中韓に任せて野菜でも育てる道が効率よい。
中韓は用意できるし、売り切ることが出来る。
printfデバッグなんてインパール作戦と同じ。
物量が違いすぎる。 >>360
私のマザーボードの JTAG/IEEE1149.1 はどれですか? >>362
OS開発の場合は、専用のボードを用いることを視野に入れる。
それが無理なら、中韓に任せて撤退するべし。 #ifdef DEBUG
#define PUTCHAR(a) do{auto b=a;putchar(b), fputc(b, _fpDbg);}while(0)
#else
#define PUTCHAR(a) (putchar(a))
#endif
死ねザコw 教師が「こういうやり方はしてはなりません」と言っただけなのに、
生徒「そういう場合は、inline使えよ馬鹿教師」
という馬鹿生徒の集まり。
学級崩壊。 教師が「こういうやり方はしてはなりません」と言っただけなのに、
生徒A「そういう場合は、inline使えよ馬鹿教師」
生徒B「こういうやり方ならいいんだよ、死ねザコw」
教師「」 inline関数や、>>364のやり方が分かった上で教師は言っている。
それとも、おまえらの通った学校の教師はそんなことも分からない
くらい程度が低かったのか?
どこの学校だよ。 俺が通った学校の教師か
化学のおじいちゃん先生だったな
当時C++はまだ世に出てなかったから
マクロの使い方は知らなかっただろうな >>372
#define マクロはありますが、lisp 様仕様マクロはありません c++の文句をいって
cの話を延々はじめる
そしてどっちも言い尽くされた話
printfデバッグやってるじじいの特徴 >>372
C++が世に出る前っていつ頃かわかってる?
その頃のCを化学のおじいちゃん先生がやってると思ったの?
おまえさんでさえK&R Cなんか使えるのか? DxLib は printfDx で printf 推奨ω >>371 ではC++はまだ世に出てなかったからマクロの使い方は知らなかっただろうと言ってるのに
>>375 では化学のおじいちゃん先生がCなんてやってるわけないだろうと言っている
それではC++が世に出ててもその頃のC++なんておじいちゃん先生はやらなかったのでは。
だとすると >>371 はいったい何が言いたかったのか… >>377
同一人物なんだが君は何に見えたのかな?? >>379
K&R1 か K&R2 かを指定してください もちろん1よ
2なんて馬鹿言うわけねえだろ
何が言いたいの? おまえさんは >>341
>nonbuffered しろってか
別に
非同期要素同士のハンドシェークがうまく行っているかは
callerとcallerの呼び出し順序に崩れが無いことをメッセージの中身とともに確認できればほぼほぼ十分なので
printf()を呼んでから出力されるまでの時間はあんま拘る意味は無い 非同期な処理を観察するってのは非同期な処理が「失敗しているかもしれない」のを見つけ出さなきゃいけないってことだよね。
複数のスレッドが競合したりする場合もあるってことだよね。
printf は歳入可能でもないし、問題があるときは printf の処理も信用できないと思うんだけど。
信用できないけどバッファに溜まったまま吐き出されないということはなるべくないようにしたいって話でしょ。 printfが再入可能でないってどゆこと? strtokみたいに状態を持つのか? 単一スレッドでも再帰なんかで再入は発生しうる
関数内でクリティカルセクションなどを使ってスレッド同期するようにしていても状態を持つ作りだと同一スレッドからの再入で異常になることはある Cランタイムは通常スレッドセーフだよね
だから複数スレッドでprintfを読んだりerrnoを参照してもよい
Windowsの場合、_beginthreadで作成したスレッドはCランタイム安全、CreateThreadで作成したスレッドはCランタイム安全ではないとかいう話もあった >>385
今、リエントラント(再入可能)という言葉は余り聞かなくなっているが、
ハードウェアに密着したプログラムを書くときに、ハードウェア割り込みの
割り込みルーチンがまだ終わってないタイミングで、同じ割り込みが生じ、
同じルーチンが再帰的に呼び出されることがあり、そのような呼び出しに
対応しているものを「リエントラント」と呼ぶことがあった。
ただし、そのようなプログラムは複雑になりがちなので、ハードウェア
割り込みが生じ、割り込みルーチンがまだ終わってないタイミングで、
同じ割り込みを発生させる原因がもう一度発生しても、割り込みルーチン自体を
呼び出さないようにする手法が使われることが多かった、というか、
その様にプログラムすることが標準とされ、そのためにプログラマブル割り込み
コントローラなるものが、その役割を果たすモードを持っており、それが通常、
有効な状態にされていた。 >>388
一方、単一スレッドプログラムの場合、mallocの中からmallocが再帰的に呼び出される
ことはそもそもない。printfも同様。
なので、複数スレッドが動作している場合でも、各スレッドにおいては、
mallocやprintfが再帰的に呼び出されることはない。
そして、mallocを作る場合、Heapに関する重要データを読み書きする時、クリティカルセクション
のようなもので囲って、1つのスレッドだけが読み書きできるようにするような手法が使われる。
この場合、その区間を実行しているのは、最大で1スレッドのみであり、複数スレッドが
同時に実行することはない。
もちろん、malloc自体は同時に複数のスレッドが呼び出しても良いが、malloc内部で重要データ
の読み書きが行なわれるのは、必ず1スレッドのみで、それ以外のスレッドは待機させられる。
割り込みハンドラをリエントラントにする場合には、このようなクリティカルセクション的な
やり方は絶対に使えない。
まず、割り込みハンドラは、実際に実行しているのは1スレッドと言えば1スレッド。
割り込み自体が、1コアしかなかったZ80などにおいても有った概念でもあるし、それは当然であるが。 >>388
多重割り込みの話と勘違いしてねーか?
同一割り込みなんて起きなくてもメインルーチンで使ってる関数を割り込みルーチンで使う可能性があるならリエントラントでないとおかしくなるよ
そもそもシングルスレッドで割り込み使ってなくてもある関数内で直接的もしくは間接的に自分自身が呼ばれる場合もリエントラントでないとおかしくなる
最近の言語だとグローバル変数とか静的変数使ってなきゃ(例外はあると思うが)リエントラントになるのであまりに気にする必要はなくなった ちゅうことはスレッドセーフなloggerが全部同じファイルにログを書き込むんだろ
これもうそのまんま出力に逐一印字させた方がいいんじゃね >>391
いや、厳密にはstd::coutデバッグというべき(ドヤ printf()はスレッドセーフ
複数スレッドから呼べる
規格のどこに書いてあるかは示せないが探せばあるはず
なぜなら、ファイルI/Oやからなあれ
もちろんこれは、printf(("ABC")とprintf("CDE")をそれぞれ別スレッドで呼んだ場合、
ABC、CDEという表示になるという保障にはならないが
実際にはたいていのケースで行単位で分かれてくれるからデバッグには困らない
行が頻繁に混じってしまってデバッグにならないようなら初めて行単位の排他の追加を検討する
みたいな ただしもちろん割り込みルーチンからprintf()を呼ぼうとするような猛者は知らん
火の粉がこっちに降りかからない限り
放っておいて差し上げなさい 保障にはならないが〜
実際にはたいていのケースで〜
こういうの一番困る printf使ってヘンになってるならまだ許せるが自前のクソloggerが全般的にクソ動作してると排除したくなる printf実行中に割り込みが発生して、なおかつそのhandlerでprintf使ってると
デッドロックが発生する(?)
※printfは内部でmallocを使ってるので、>>389に書いてあるようにheapの
操作時にロックを取得しようとするため
という感じかな? なら自前のprintf作ればいいだろ
標準に頼りきるバカが >>402
>自前のprintf作ればいい
こういう台詞は、その能力の欠けたものが得てして言いがちなことだよなあ‥‥と 己の道は己で切り開くものだ
貴様らジャップどもは文句たらたらと言ってるだけで行動に移そうとはしない
猿に退化する課程の獸だな >>404
ワイらがジャップだとしたら
お前はいったい何なんだよ >>404
無関係な問題まで何でもかんでも民族や国籍に結びつけて的外れな非難をしようとするとは、怒りに囚われて論理的思考力が壊滅的にダメージを受けてるんだろう。プログラマとしては致命的だなw 割り込みルーチンの中からprintfを読んだら危険なのは
一般にOS機能のうちクリティカルセクション(ロック)みたいな高級な機能が
ユーザーが勝手に定義した割り込みルーチンのコンテキストでは使えないからじゃわ;
OSはOSで割り込みを受けてスレッドのコンテキストを管理しているので、
それとは非同期に起きたOSのあずかり知らない割り込みで
OSの高級な機能が呼ばれたらOSの管理情報の排他が崩れる 割り込みルーチンから呼んでも安全なprintf()を自力で実装するとしたら
メインのOSとコードベースをまったく異にする必要があるのでOSの自力実装に近くなってくる
やっぱ割り込みルーチンからはprintf()呼ばないというのが一番スマート 聞くんじゃなかった
printf( → fprintf(stdout,
みたいなもんでstdoutが静的記憶域期間とか
そういう説明が聞けるのかと思いきや
なんだこりゃ・・・ ■ このスレッドは過去ログ倉庫に格納されています