X
C++相談室 part153
■ このスレッドは過去ログ倉庫に格納されています
0292デフォルトの名無しさん
垢版 |
2020/10/18(日) 21:36:12.84ID:OvLc2vD2
>>287

> ソフトウェアの良い設計というのは
> 結果的に破綻も漏れも無く抽象化できていればおk

そうだね。ただ、具体的にどんなノウハウを与えれば、>>288の言うスーパーマンを生み出すかってのが次の疑問だろうな。

自分はOOP、TDDあたりのノウハウが身につけば余裕だと思っているが。
0293デフォルトの名無しさん
垢版 |
2020/10/18(日) 21:42:13.49ID:e/dVAB4j
OOPは物事を整理する仕組みは提供してくれるが
どう整理をつけるかはやっぱ設計者のセンスに委ねられたままやんけ
実際>>287にゼロベースで的確に答えることは難しい
TDDは設計を検証する仕組みは提供してくれるが以下略

んまーテストケースをいっぱい書くというのは
物事簡潔に済ませる習慣が身につく良い経験かも試練、
0294デフォルトの名無しさん
垢版 |
2020/10/18(日) 22:21:54.75ID:OvLc2vD2
>>293

> OOPは物事を整理する仕組みは提供してくれるが
> どう整理をつけるかはやっぱ設計者のセンスに委ねられたままやんけ

その通り。だからこそ、そのセンスを磨かせるためにTDDもセットで紹介してみた。
まず、自分の設計が正しいか妥当性確認する手段も無いと間違ったオブジェクト指向が身に付く恐れがあるからね。

結局のところ、個々のセンスを磨かせないと駄目だが...センスを磨かせる環境を整えるのはリーダーの役割だと思う。
何もない状態でセンスで何とかせよ、よりは改善が期待できるよ。
0295デフォルトの名無しさん
垢版 |
2020/10/19(月) 00:20:11.11ID:lLBStDOZ
コンパイラの都合というよりかはcとの互換性とランタイム速度優先のための仕様によるものだろう。
てかむしろもっとコンパイラの都合考えたらもう少しまともな仕様になっとるわ。
0296デフォルトの名無しさん
垢版 |
2020/10/19(月) 05:23:08.92ID:f5AfjsGE
スーパーマンはある種の天才で、体系的に天才を教育する方法はないと思う。特に今現在の教育は全体の平均値を上げる事に主眼を置いているから。

大多数がほどほど幸せになる方法としてある程度うまくいってたけど、極少数が全体に絶対的な影響を及ぼすソフトウェアの世界だと効率の悪さが目立ってくるよね。

天才を見つけておいて必要な時に協力してもらうしかないんじゃないかな。全てにおいて天才はいないし来てもくれないので、得意分野では天才的みたいな奴と仲良くしておくぐらいか
0297デフォルトの名無しさん
垢版 |
2020/10/19(月) 11:06:36.21ID:4f6/Swqm
体系的に天才を教育する方法
ってのは実は簡単で、C++をやらせればいい
0300デフォルトの名無しさん
垢版 |
2020/10/19(月) 12:11:42.92ID:0OpHGeV7
プログラムの才能のある人材を発掘する方法は、以前だとLispかHaskellをやらせるのが定番だったけど今はどうなのかね？
0301デフォルトの名無しさん
垢版 |
2020/10/19(月) 12:44:51.59ID:QMGC8XAt
まずクソ企業で天才が居座るメリット無くね？
誰かが頑張ってくれるだろうみたいな雑魚集団と仕事したくねーわ。
0302デフォルトの名無しさん
垢版 |
2020/10/19(月) 13:49:59.16ID:asy7wTux
>>296
天才とは言っていない
ttp://equallove-2017.blog.jp/archives/24499215.html
ttp://equallove-2017.blog.jp/archives/24508935.html
ttps://star.programming-study.com/
2020年10月17日放送分
TK-80の産みの親？
元マイクロソフトでwindows95の開発に参加？
良く判らんけど
Windows95の生みの親に直撃!開発秘話やプログラミングの裏話、子どもたちに伝えたい思いを告白
0306デフォルトの名無しさん
垢版 |
2020/10/20(火) 03:00:21.68ID:C47XLKZf
deleteで解放しようとするとたまに落ちるバグがあるのですが
try〜catchで囲っても、やっぱ落ちます。
これって例外で処理することはできないんでしょうか？
それともやばいバグ過ぎてつかまえられないだけなのでしょうか？
0307デフォルトの名無しさん
垢版 |
2020/10/20(火) 03:05:40.63ID:U9bI1hKI
投げない例外は捕まえられないのでは？
0308デフォルトの名無しさん
垢版 |
2020/10/20(火) 03:09:48.67ID:C47XLKZf
>>307
これじゃダメなんでしょうか？
すみませんC++よくわかってなくて…

try{
delete p;
}catch(...){
std::cerr << "error!" << std::endl;
}
0309デフォルトの名無しさん
垢版 |
2020/10/20(火) 03:14:10.05ID:U9bI1hKI
>>308
pのデストラクタの中で何かが起きていて、そこで例外が投げられないから補足できないのでは？

それと経験的に、再現性の無いバグは、十中八九、未定義の記憶域を読むことで発生する。
0311デフォルトの名無しさん
垢版 |
2020/10/20(火) 03:27:44.66ID:C47XLKZf
>>309
デストラクタは何もないので
どこかでメモリ処理がおかしくなってるんでしょうね…
一旦、動くようにしてみたかったのですが、もうちょっと調べてみます。
ありがとうございました。
0312デフォルトの名無しさん
垢版 |
2020/10/20(火) 03:36:12.53ID:NaQDrxzK
そういうときに役に立つのがprintfデバッグだろ
どの工程で起こったのかある程度目星がつく
0313デフォルトの名無しさん
垢版 |
2020/10/20(火) 04:45:58.59ID:C47XLKZf
>>321
継承元の親クラスを何個も辿ってよく調べたら
コンストラクタの中で怪しいポインタにアクセスしている個所がありました。
おそらくこれが原因だと思います。
皆さん有難うございました。
0316デフォルトの名無しさん
垢版 |
2020/10/20(火) 08:40:05.01ID:OBwoowsU
いや、今回の問題の解決のために書いたわけではなくて、
>>308のように書いても無駄だと伝えるために書いた。
そのあたり明示せずに書き込んですまん。
0317デフォルトの名無しさん
垢版 |
2020/10/20(火) 11:34:12.27ID:pHiz9StD
atexit()
exit()
で捕捉出来ないかな
0319デフォルトの名無しさん
垢版 |
2020/10/20(火) 11:56:25.10ID:pHiz9StD
プロは logger 使うし
百歩譲っても使うのは fprintf の方
0320デフォルトの名無しさん
垢版 |
2020/10/20(火) 13:10:32.17ID:wzOsKsv0
printfが使える環境ならな
そうでない場面がごまんとあるから
選択肢は多いに越したことはない
0322デフォルトの名無しさん
垢版 |
2020/10/20(火) 13:21:52.61ID:vcQhkuUZ
基本的にprintfデバッグの延長
制度化体系化されたprintfデバッグがログ取り

loggerはより高度なprintfデバッグであり、その基本がprintfデバッグになる
この変数を眺めりゃ万事OK　という直感が涵養される

loggerの出力先が10万キロ離れたプリンタなこともある
0327デフォルトの名無しさん
垢版 |
2020/10/20(火) 14:27:50.64ID:Y3GT62kx
C#を作ったアンダース・ヘルスバーグもデバッガのステップ実行よりもprintfを使うってインタビューで言ってたな
0329デフォルトの名無しさん
垢版 |
2020/10/20(火) 17:41:32.21ID:AdA8N6MK
C++23のdraftが公開されてた
http://wg21.link/n4868
0331◆QZaw55cn4c
垢版 |
2020/10/20(火) 22:08:32.52ID:glKVTYwZ
>>300
C のポインタ、特に関数ポインタ、とか
リカーシブ、とかで十分でしょう
0333デフォルトの名無しさん
垢版 |
2020/10/21(水) 11:15:30.61ID:xBgAWF1Y
シッタカブリ
0334デフォルトの名無しさん
垢版 |
2020/10/21(水) 11:18:26.05ID:F4fghCXJ
printfデバッグなんてあり得んけどな。
0335◆QZaw55cn4c
垢版 |
2020/10/21(水) 11:45:48.97ID:SYSvovlW
>>334
でも最初のうち、プログラムが小さいうちは、それが一番手っ取り早いですね
0336デフォルトの名無しさん
垢版 |
2020/10/21(水) 11:52:32.13ID:xBgAWF1Y
printf デバッグは完成後に printf の行を消すと動かなくなったりするω
0337デフォルトの名無しさん
垢版 |
2020/10/21(水) 12:15:19.02ID:EPxGxCCv
関数化やクラス化でプログラムを小さくするわけで、あんまり関係ないな
assertを使うときもそうだが、デバッグ用のコードに副作用を入れちまうのはヘボ以下
0338デフォルトの名無しさん
垢版 |
2020/10/21(水) 12:41:52.63ID:BgzupaSs
デバッグOffして弊害残すヤツは動作の仕組み把握出来てないだけだろ
>>336、まず貴様のコーディングセンスを磨いてから出直してこい青二才
0339デフォルトの名無しさん
垢版 |
2020/10/21(水) 23:09:27.50ID:oE8Yb73v
非同期で動くブツ同士の通信はprintfデバッグ大活躍なのでは…
誰がいつ何を呼んで何を渡したのかと呼ばれたほうが本当に受け取ったのかがすぐﾜｶﾙ

printf消去忘れについては条件コンパイルを使えば良いし、
Ad-hocな追加ならいかに大量にやってもソースコード管理システムで安全に消すこともできるわけやし、
0340デフォルトの名無しさん
垢版 |
2020/10/22(木) 00:49:05.87ID:VEHOj23m
未定義動作踏んでるときとかにprintfを呼び出すことでたまたま動くようにできたりする
ということか
0341デフォルトの名無しさん
垢版 |
2020/10/22(木) 10:43:36.11ID:vPWH9GQz
>本当に受け取ったのかがすぐﾜｶﾙ

buffer flush しないと判らんし
flush すると勝手に改行する環境とかあるし
そこまで便利ってほどでもなくね
nonbuffered しろってか
0343デフォルトの名無しさん
垢版 |
2020/10/22(木) 12:25:12.96ID:QhFI+vyp
#ifdef DEBUG
　#define PUTCHAR(a) (putchar(a), fputc(a, _fpDbg))
#else
　#define PUTCHAR(a) (putchar(a))
#endif
PUTCHAR(*ptr++);
みたいなことをやれば デバッグ時だけ*ptr++ が二回評価されて結果は変わってしまう。
0348デフォルトの名無しさん
垢版 |
2020/10/22(木) 12:38:34.09ID:QhFI+vyp
>>347
駄目な例を敢えて書いたんだ。
どうしてそれが分からないの、あなた達には？
IQが高い人には駄目な例が単なる例として出されたのだと分かるのに
ここの人達にはそれがわからない。
0349デフォルトの名無しさん
垢版 |
2020/10/22(木) 12:39:39.22ID:3l9/RVrp
>>339
非同期なアプリでprintf使うとタイミングが変わることがあるから安心できんな
デバッガよりは遥かに良いけど
0350デフォルトの名無しさん
垢版 |
2020/10/22(木) 12:41:58.22ID:QhFI+vyp
>>336 が
「printf デバッグは完成後に printf の行を消すと動かなくなったりするω」
と書いていたが、>>340が指摘した理由だけではないので、
そうなる他の理由の1例を>>343で書いた。
0351デフォルトの名無しさん
垢版 |
2020/10/22(木) 12:45:00.97ID:QhFI+vyp
これが考える力なんだよ。
マスコミを含めて「知識知識」と言う人が多いが、生まれつきの頭が悪いと
>>344 >>347 のような馬鹿な発想しか出来ないのでどうにもなら無い。
俺に比べれば、おまえが池沼の癖に。
0357デフォルトの名無しさん
垢版 |
2020/10/22(木) 18:56:55.19ID:N0tQIHiY
>>350
たぶんみんなは
そりゃマクロ使えば何でもありありだろ
そんなことでドヤるとかバカじゃねーの
って思ってる…
0360デフォルトの名無しさん
垢版 |
2020/10/22(木) 19:11:08.49ID:dQkQeqlj
今はJTAGがあるので、そんなにお金がかからない。
それでも、プロセッサごとにデバッグ環境を用意できるわけないだろ！！というのが日本企業の現状なら、中韓に任せて野菜でも育てる道が効率よい。
中韓は用意できるし、売り切ることが出来る。
printfデバッグなんてインパール作戦と同じ。
物量が違いすぎる。
0361デフォルトの名無しさん
垢版 |
2020/10/22(木) 19:15:22.48ID:dQkQeqlj
お前たちは農民に戻れ。
ハイ解散。
0362◆QZaw55cn4c
垢版 |
2020/10/22(木) 20:52:46.17ID:RiQFyYLu
>>360
私のマザーボードの JTAG/IEEE1149.1 はどれですか？
0363デフォルトの名無しさん
垢版 |
2020/10/22(木) 21:09:21.98ID:dQkQeqlj
>>362
OS開発の場合は、専用のボードを用いることを視野に入れる。
それが無理なら、中韓に任せて撤退するべし。
0364デフォルトの名無しさん
垢版 |
2020/10/22(木) 23:42:23.12ID:PrgepFj3
#ifdef DEBUG
　#define PUTCHAR(a) do{auto b=a;putchar(b), fputc(b, _fpDbg);}while(0)
#else
　#define PUTCHAR(a) (putchar(a))
#endif
死ねザコw
0367デフォルトの名無しさん
垢版 |
2020/10/23(金) 12:34:55.69ID:wQpWPNJn
教師が「こういうやり方はしてはなりません」と言っただけなのに、
生徒「そういう場合は、inline使えよ馬鹿教師」
という馬鹿生徒の集まり。
学級崩壊。
0368デフォルトの名無しさん
垢版 |
2020/10/23(金) 12:38:30.14ID:DuAJkWLf
教師が「こういうやり方はしてはなりません」と言っただけなのに、
生徒A「そういう場合は、inline使えよ馬鹿教師」
生徒B「こういうやり方ならいいんだよ、死ねザコw」
教師「」
0369デフォルトの名無しさん
垢版 |
2020/10/23(金) 12:48:55.12ID:wQpWPNJn
inline関数や、>>364のやり方が分かった上で教師は言っている。
それとも、おまえらの通った学校の教師はそんなことも分からない
くらい程度が低かったのか？
どこの学校だよ。
0371デフォルトの名無しさん
垢版 |
2020/10/23(金) 13:52:00.54ID:DuAJkWLf
俺が通った学校の教師か
化学のおじいちゃん先生だったな
当時C++はまだ世に出てなかったから
マクロの使い方は知らなかっただろうな
0373◆QZaw55cn4c
垢版 |
2020/10/23(金) 16:10:04.88ID:HRhvOpQY
>>372
#define マクロはありますが、lisp 様仕様マクロはありません
0374デフォルトの名無しさん
垢版 |
2020/10/23(金) 16:52:36.06ID:GtGn5ZF1
c++の文句をいって
cの話を延々はじめる
そしてどっちも言い尽くされた話

printfデバッグやってるじじいの特徴
0375デフォルトの名無しさん
垢版 |
2020/10/23(金) 16:57:39.47ID:DuAJkWLf
>>372
C++が世に出る前っていつ頃かわかってる？
その頃のCを化学のおじいちゃん先生がやってると思ったの？
おまえさんでさえK&R Cなんか使えるのか？
0376デフォルトの名無しさん
垢版 |
2020/10/23(金) 17:12:38.69ID:2f10zgGH
DxLib は printfDx で printf 推奨ω
0377デフォルトの名無しさん
垢版 |
2020/10/23(金) 17:55:43.35ID:vvEFmscd
>>371 ではC++はまだ世に出てなかったからマクロの使い方は知らなかっただろうと言ってるのに
>>375 では化学のおじいちゃん先生がCなんてやってるわけないだろうと言っている

それではC++が世に出ててもその頃のC++なんておじいちゃん先生はやらなかったのでは。
だとすると >>371 はいったい何が言いたかったのか…
0381デフォルトの名無しさん
垢版 |
2020/10/23(金) 20:32:42.02ID:DuAJkWLf
もちろん1よ
2なんて馬鹿言うわけねえだろ
何が言いたいの？　おまえさんは
0382デフォルトの名無しさん
垢版 |
2020/10/24(土) 00:28:14.62ID:5I5noegP
>>341
>nonbuffered しろってか
別に
非同期要素同士のハンドシェークがうまく行っているかは
callerとcallerの呼び出し順序に崩れが無いことをメッセージの中身とともに確認できればほぼほぼ十分なので
printf()を呼んでから出力されるまでの時間はあんま拘る意味は無い
0383はちみつ餃子 ◆8X2XSCHEME
垢版 |
2020/10/24(土) 02:46:57.76ID:yf0wmlMH
非同期な処理を観察するってのは非同期な処理が「失敗しているかもしれない」のを見つけ出さなきゃいけないってことだよね。
複数のスレッドが競合したりする場合もあるってことだよね。
printf は歳入可能でもないし、問題があるときは printf の処理も信用できないと思うんだけど。

信用できないけどバッファに溜まったまま吐き出されないということはなるべくないようにしたいって話でしょ。
0386デフォルトの名無しさん
垢版 |
2020/10/24(土) 08:40:39.80ID:VP+yyMyu
単一スレッドでも再帰なんかで再入は発生しうる
関数内でクリティカルセクションなどを使ってスレッド同期するようにしていても状態を持つ作りだと同一スレッドからの再入で異常になることはある
0387デフォルトの名無しさん
垢版 |
2020/10/24(土) 08:44:50.93ID:VP+yyMyu
Cランタイムは通常スレッドセーフだよね
だから複数スレッドでprintfを読んだりerrnoを参照してもよい
Windowsの場合、_beginthreadで作成したスレッドはCランタイム安全、CreateThreadで作成したスレッドはCランタイム安全ではないとかいう話もあった
0388デフォルトの名無しさん
垢版 |
2020/10/24(土) 11:13:00.25ID:aZOaF4i3
>>385
今、リエントラント(再入可能)という言葉は余り聞かなくなっているが、
ハードウェアに密着したプログラムを書くときに、ハードウェア割り込みの
割り込みルーチンがまだ終わってないタイミングで、同じ割り込みが生じ、
同じルーチンが再帰的に呼び出されることがあり、そのような呼び出しに
対応しているものを「リエントラント」と呼ぶことがあった。
ただし、そのようなプログラムは複雑になりがちなので、ハードウェア
割り込みが生じ、割り込みルーチンがまだ終わってないタイミングで、
同じ割り込みを発生させる原因がもう一度発生しても、割り込みルーチン自体を
呼び出さないようにする手法が使われることが多かった、というか、
その様にプログラムすることが標準とされ、そのためにプログラマブル割り込み
コントローラなるものが、その役割を果たすモードを持っており、それが通常、
有効な状態にされていた。
0389デフォルトの名無しさん
垢版 |
2020/10/24(土) 11:21:13.53ID:aZOaF4i3
>>388
一方、単一スレッドプログラムの場合、mallocの中からmallocが再帰的に呼び出される
ことはそもそもない。printfも同様。
なので、複数スレッドが動作している場合でも、各スレッドにおいては、
mallocやprintfが再帰的に呼び出されることはない。
そして、mallocを作る場合、Heapに関する重要データを読み書きする時、クリティカルセクション
のようなもので囲って、1つのスレッドだけが読み書きできるようにするような手法が使われる。
この場合、その区間を実行しているのは、最大で1スレッドのみであり、複数スレッドが
同時に実行することはない。
もちろん、malloc自体は同時に複数のスレッドが呼び出しても良いが、malloc内部で重要データ
の読み書きが行なわれるのは、必ず1スレッドのみで、それ以外のスレッドは待機させられる。

割り込みハンドラをリエントラントにする場合には、このようなクリティカルセクション的な
やり方は絶対に使えない。
まず、割り込みハンドラは、実際に実行しているのは1スレッドと言えば1スレッド。
割り込み自体が、1コアしかなかったZ80などにおいても有った概念でもあるし、それは当然であるが。
0391デフォルトの名無しさん
垢版 |
2020/10/24(土) 12:29:55.83ID:+GevKgJx
coutデバッグと言うべきってか
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況