C言語なら俺に聞け 158
レス数が1000を超えています。これ以上書き込みはできません。
そういう人物は確かにいる
システム障害時に、数分で原因を調べ上げ復旧する奴 >>900
その人なりのロジックがちゃんとあるけれども、凡人には理解できないのかもしれませんね…
まあ意識（ロジック）も無意識もフルに総動員しているとは思いますが
>>891
あくまでとある仮説に興味がある、といっているだけで、それですべてを説明しようとは思っていませんよ
それにしても「準備運動電位」、あなたはどう説明しますか？ 電位ってそれ以上でもそれ以下でもないな
喩え話でもしたいようだが、この世界では究極の最重度池沼ってだけｗ >>896
でかいシステムなら分割して調査することもあるからどこから調査するとかどうやって調査するかとか事前に決めるのは珍しくないぞ
そんなことも知らないのはお前の経験値が低いだけ >>903
そんなことはあたりまえでしょう？
手当たりしだいにしらみつぶしに見てバグが見つかるとでも？
でもね、凡人が見当もつかない糸口をたどって（バグつぶしに限らず）問題解決を行う現場を見てきましたよ
そういう人間の考え方が、単にロジック一辺倒ではないのでは？という切り口で話をしているものだと思っているのですが
あるいは自分のコーディングの最中に自分のミス・バグを見つけ出すのは、最初自分が正しいと考えているだけに、結構難しいことだと思っているのですが、
そういうときは非凡な人はどういう思考方法をとっているものなんでしょうか？ >>904
> 手当たりしだいにしらみつぶしに見てバグが見つかるとでも？
それでないと見つからないバグもある
> でもね、凡人が見当もつかない糸口をたどって（バグつぶしに限らず）問題解決を行う現場を見てきましたよ
そう言うのは経験値が違う
まあその考え方を文書化できるかどうかは別の話
> あるいは自分のコーディングの最中に自分のミス・バグを見つけ出すのは、最初自分が正しいと考えているだけに、結構難しいことだと思っているのですが、
> そういうときは非凡な人はどういう思考方法をとっているものなんでしょうか？
お前はテストもしないのかよ スレが活性化したようだな。
読む気が起こらんけど。 何でしらみつぶしが出てくるんだ
不具合の内容から疑われることを挙げて
排除できる項目を排除して疑う範囲を狭めていくにあたり
論理思考が得意なやつとそうでないやつの違いが出るってだけだ >>910
バグの排除にロジックが必要なのは当然ですが、それだけではないでしょう？
特に自分のバグを外すには、そもそも自分のロジックを疑うという能力は、ロジックを使うのはまず困難なのでは？ >>910
疑う範囲を狭めて最後はしらみつぶしとか普通にあるだろ
なぜ排他だと思った？ バグの排除とは言ってない
疑いが晴れたものを検査から除外するということだ
なぜ排他が出てくるのか脈絡がわからない >>913
> バグの排除とは言ってない
おれも言ってないけど？
> 疑いが晴れたものを検査から除外するということだ
検査の意味がわからんが調査のことならしらみつぶしは疑いを晴らす方法の一つ
> なぜ排他が出てくるのか脈絡がわからない
お前がしらみつぶしを排除しようとしてるから アホ検知用にわざとアンカー貼らなかったら見事に引っかかったなｗ なにを引っ掛けたつもりになってるのかさっぱりわからん
まあまともなレスを返せなくなったんだろうなw >>901
ただのDSPだろう
CPU(脳)が応答していては間に合わない用途のためにプログラマブルなDSPがある
ボールが見えてから打つかどうか決めていては間に合わない
このコースに来たらバットを振れと反射神経をプログラムできるようになっている
それがあたかも脳の判断に先行してるように見えるだけ >>921
レスできなくなって流れが読めてない～ってバカ？w はっきり言ってやらなきゃ解らんようだな
バグの排除と言ったのが誰なのか
おまえ読み間違えてんだよ >>924
だから>>911なんて俺には関係ないだろ
アンカーもまともに追えないのか？ ロジックは合っているがバグだ、というのは割とよくある（まれにではない） >>926
・仕様バグ
・非同期処理絡み
・限界値オーバー等
それ以外ってあったっけ？ 今は昔、DBが気軽に使えなかったシステムがあった。
プレーンファイルにデータが格納されていた。
お客の要求は、
「その中からキャンセルされたデータを見つけ、取り除いてくれ。件数は高々数十件のはず」
当時のSEは、キャセルデータ一覧から一つずつデータを取り出し、
格納されたファイルから見つけてはキャンセルフラグをセットしていく
という設計をした。スッキリした設計で、客のレビューも通った。
プログラマは仕様書通りにプログラムを作成した。
実運用に入ったところ、この処理がいつまで経っても（何時間も）終わらない事態になった。
原因調査を依頼され、調べて対処方法を提案し、
プログラムの手直しをした。
その結果、処理は10分程度で終わる様になった。
実データは、お客の想定よりは多かった（と言っても100件程度だったが）ことと
試験環境が貧弱で、性能評価が不十分だったことが挙げられた（公式見解）。 今は昔 ドラゴンボールというものありけり
7つ集めないと気軽に使えなかった 非同期やマルチスレッドなんかの 暗に平行に動いてるようなやつ
の想定順序外の順で進んでったとき 昔のプログラム系コラムで（うろ覚えなんで改変あり）
統計計算するコード書いて、
自分で用意したデータでは問題なかったが、
デバッガ―チームのデータでは誤差が酷いとの報告が。
変数をfloatからdoubleにしても改善せず、
使ったテストデータ見せてもらったら数値が10兆のや1/10兆のまであったとかなんとか。 >>928,931
件数や数値の範囲を規定してなかったんだろうな
規定してたらテストしてるだろうし
>>928の方はキャンセルする件数も重要だけど変更するプレーンファイルのサイズも重要 仕様通りに作ってあるってことで
どこもバグだと認めず、修正にかかれなかった 実行時間の上限も書いてなかったんでしょ？
ならバグじゃないからそりゃ誰も修正しないよね >>937
奈良仕様... 要人警護でバグるんだな。 >>920
それは条件反射ではない普通の「反射」
か、あるいは条件反射ですね
「準備運動電位」
https://ja.wikipedia.org/wiki/%E3%83%99%E3%83%B3%E3%82%B8%E3%83%A3%E3%83%9F%E3%83%B3%E3%83%BB%E3%83%AA%E3%83%99%E3%83%83%E3%83%88
1970年代に行われた実験により、ボタンを押す・指を一本曲げる、手首を曲げる等運動の先立って脳に変化が起こる、という観測結果が得られています
2008 年には、被験者が意思決定をするよりも最大 7 秒先立って脳活動が認められる、という＾報告がありました その生理現象を検知して価値を生み出すコードを書くならともかく
精神論や根性論の類いに持ち出す野郎はスレチ >>940
ええ、バグ取りに使えないものかと
異様にバグ取りがうまい人の頭の使い方について話題にしようと思ったんですよ そんなの経験の差でしょ
脳科学なんかを引くより経験積んだほうが実用的で合理的 >>942
いつまでも KKD ではねえ
もう少し精緻な話がしたいものです バグ取りの上手い人というか、発見が早い人は
アスペ気味の人が多い
これは悪い意味で言っているのではなく
天才肌というか、直感でものを把握出来る人という意味です >>944
それもアラアラな話だと思いますが
しかし、その直感でものを把握できる、ってのがどういう思考法なのか興味がありますね
もう少しそのタイプのプロフィールを教えていただけませんか？ そういうのは、誰もマネが出来ないから参考にするのは無理でしょう
脳細胞のシナプスからして違うかもしれないし プログラムの仕組みを完全に理解したいなら、ITパスポート、基本情報、コンピュータサイエンスの3つ。 プロの化学者つかまえて次亜塩素酸ナトリウムと塩酸を混ぜるなとドヤるアホ
みたいなもんだな >>945
直感って大抵は経験に基づくショートカット。
常人でも意識しながら年単位でデバッグ続けてりゃ多少は身につくんじゃねの？ >>953
身につくかどうか、ではなく、どんな考え方、思考法、そして可能であればその思考法に似た行動様式等がざっくばらんに出てくることを期待します >>954
鏡で自分の顔を観てバグを一覧にしてみ
良い訓練になる 組み込みの世界ってまだC言語が主流ですよね？
IoTも同じ？ IoT というのは広い概念なのでそれだけではなんとも言えん。
低レイヤもあれば高レイヤもある。 次のCの仕様が出てくるというのにこのスレでは全く話題にならないんだな tccで標準入力からソース読むプログラムに、さらにstdinからデータ読ませるのは無理ですかね？
(echo "ccode with stdin" | tcc -run - ) <file
みたいな感じで(fileまでソースと取られてコンパイルエラー)
一時ファイル作れば出来るけど、ちょっとワンライナー書くときに不便を感じる
echo "main(char*c, char**v){puts(v[0]);puts(__FILE__);}" | tcc -run -
は
-
<stdin>
を出力します、多分tccはプロセスを自己書き換えで置き換えるんでしょうか？ファイルハンドルが継承されてる？ >>958
高レイヤーだと普通にリッチな言語が使われたりするのかな
>>961
deferが入るかもって別スレで見かけたけど本当？ 組み込みと言ってもラズパイ環境では完全にPythonが主流でC/C++(gcc)はあまり利用されてないイメージがある >>964
C23 には defer は入らない見込み。 全体としては C++ の後追い的な変更が多い。
auto が型推論付きの変数定義になるだとか、constexpr や nullptr が導入されるだとか、
属性の表記法が C++ 風の [[ ]] を使った形になるだとか、そういう感じのやつ。
(ちなみに今回導入される constexpr は変数には付けられるが関数には付けられないので
コンパイル時プログラミングが C++ みたいに出来るわけではない。
定数式の成立要件が C と C++ で違うので C++ 寄りにする追加機能。)
思い切った変更ではあるが、根本的なプログラミングスタイルを変えない程度のバランスのとれたところだと思う。 >>966
もちろんそういう部分も大きいけど……。
リッチな組み込みは一昔前のパソコンを超えるくらいの性能はあるし Linux くらいは載るので、
デバイスドライバさえ用意すればあとはパソコンみたいに使えるという場合は普通にある。
かつては組み込みと言えばそのデバイスドライバの部分こそ大きかったと思うんだが、
IoT を意識するレベルの製品だとアプリケーションレイヤが巨大なので Python くらいは動くこともあるだろう。
主流かというとちょっと疑問ではあるが……。 それは組み込みと言うより、OS上で動かしている単なるアプリだろう パソコンで同じことやっても組み込みなんて言わないし 組み込みの開発はクロス開発が基本なのでパソコンはただの端末だけどね
プログラムはボード上のSoCで実行される IoTにはC言語は深く入り込んでないのか
>>967
型推論付くってマジ？
個人的には嬉しい >>964
> 高レイヤーだと普通にリッチな言語が使われたりするのかな
複合機などはWebサーバー程度は普通に入ってるから設定画面等は HTML, JavaScript, CSS, Python を使ってたりする
IWS (Internal Web Server：HTML, JavaScript, CSS, Python)
https://dsp.konicaminolta.jp/best-program
もちろんOS上で動いてるし、でかいシステムだとPCその物を内蔵してたりすることもある
なのでこんなものが売られてる
https://jpn.nec.com/fc/index.html IoTというよりはスタンドアローン環境か小規模な独自ネットワーク程度の組み込み分野の方がC/C++利用は多いと思う >>974
こういう機材に囲まれたことないなー
俺はIoTは名前だけでほんとに実感がない >>969
機器に「組み込まれ」ているなら組み込みと呼んでいいだろう。
パソコンに近い構成にしてパソコンでも使えるソフトウェアを活用する場合があるというのは結果論だよ。 そうなるとPC使っていても組み込み扱いして良いと言うことになりますよね
近い構成どころか、何でもありになりそう そうだよ。
技術的な実態としてはそんなにはっきりした境界がない。 なんでもありだ。
用途の側でふんわりと分野が分かれてる。 >>961
Cは枯れた言語で今さら新機能は誰も望んでないからな
むしろ余計なことをしてくれるなと 古いソースが問題なくコンパイル出来ないと、それはそれで問題にされる。
今でもトライグラフ受け入れないと駄目なんだろう >>981
C99 の C++ との互換性がまったく取れていない変てこ機能はさっさと削除してほしいものです
いまや私は C のソースを書くのに C++ コンパイラが通るか試してみる体たらく、あれらはいったいなんなんだ？ 今回「削除」になったのはいわゆるK&Rスタイルの関数定義くらいだな。
いずれ削除するということは以前から書かれてたし、
習慣的にも行儀が悪いという考え方が支配的だから
これで問題が起こるなら長い移行期間中に対応できてなかったほうが悪いと言ってよかろ。 削除って事は、古いソースのコンパイルはもはや出来ないと言うことなんでしょうか
いや、なに、クラシックカーに乗ってみたい位の好奇心ですけど 歳をとるということ 〃
シワが増えるということ 〃
なのに
ぼくたち
私たちは 〃
なぜ、最新機種で進化の止まった古臭いコンパイラを使うのでしょうか
でしょうか >>985
削除された機能を使っていればそういうことになるが、
そもそも C で書かれたプログラムなんてどこかしらで環境依存な部分があるもんだし、
よほど配慮されたものでない限り古いコードは素直には動かないのが普通だろう。
まあ C23 が出来たからと言って C89 (に対応したコンパイラ) が直ちに消滅するわけでもないし、
なんだかんだであと二十年くらいたっても C89 派がそれなりにはいそうな気がする。 K&R CこそCの面白さの塊なんだけどな
GCCが「カバにダンスを踊らせるのはあまり面白くない」なんて言ってた人もいるように
歳月とともに雁字搦めになっていく流れは酷くつまらない >>988
でもね、C のコンパイラは C で記述してほしかったですね
確かにカバの調教は難しいのかもしれませんが
というか、gcc をコンパイルするためだけの c で書かれた c++ コンパイラって需要ありますかね？ ラージモデルでFarポインタ使いまくったプログラム合ったけど、
今は流石に見るのも嫌だと思う
何言ってるか分からないと思うが、俺も分からない >>992
むしろnearポインタの方が面倒だと思うが... あり人間とかキチガイ、こっちでも頓珍漢なこと書いてるのか >>992
ラージモデルの far ポインタでしょう？別に far とか書かなくても普通にポインタを書けば far ポインタになったはず
であれば、あとは 64kb の壁を意識してむやみにポインタのインクリメントをせずに上手に部分にわければなんとかなったでしょう
far ポインタでの経験はいろんな場所で活かせる貴重な体験だと思いますよ
私は試食版 LSI-C のスモールモデルで陽に far を指定して far ポインタをバリバリつかっていましたよ
スモールモデルだからコード領域はせまいけれども（near コールしか使えない）、far と書けばデータは 640KB までフルに使えましたし インテルのクソ設計でみんな迷惑してたってだけの話
K&R Cの楽しさとは全く何の関係もない
68kと86系は異次元の世界だった >>995
テキトー書く前に8086 メモリーモデル とか near far huge とかでググってから出直してこい >>997
私の認識であってますよ
ラージモデルのデフォルトポインタ（データ・コードとも）は far ですし、スモールモデルはどちらも near
しかしスモールモデルでも far ポインタは far と陽に宣言すれば使えるんですよ… Windows16ビットのCでは16ビットハンドルを架空の構造体へのnearポインタとして実装してたな(#define STRICTした場合)
例えばデバイスコンテキストハンドルをビットマップハンドルに代入しようとするとtype mismatchエラーになってすぐわかる
STRICTでないと単なる本来の16ビット整数として扱われ混同しても通ってしまう
win32ではnearがないので普通の32ビットポインタになってしまいメモリがちょっともったいない >>92push(保存)してpop(書き戻し)してるから結局pushしたときのデータになる
popとpushの間のややこしいとこはシカトな レス数が1000を超えています。これ以上書き込みはできません。
