C言語なら俺に聞け 143
■ このスレッドは過去ログ倉庫に格納されています
>>647 ゆずの大馬鹿は18年だったんだが、最近のゆずは発育がいいのか? >>646 Java がいいんじゃないかな?書籍も多い >>646 数学/物理が出来なくて文系に行った口なら諦めろ。一生無理だ。 頑張ったところで、若い奴らに簡単に追い越され、一生惨めな思いをするだけだ。 他に適性のある分野を探した方がいい。 現実的には、理系/文系のどちらの知識も必要なく、抽象/論理思考が出来るかどうかが全てだ。 だから高々高校2年間程度のラベルの結果である文系/理系自体には大した意味がない。 しかし、そもそも抽象/論理思考が得意なら、当然、 不得手な奴が混ざっている環境(つまり文理分けていない状況)においては無双できる。 結果、「得意だから」≒「好きだから」という理由で文理を選んだのなら、文系を選んでる時点で向いてない。 そして大学4年間で理系の連中は周りが抽象/論理思考出来る奴らばかりという環境で鍛えられることになるから、 決定的な差がついてしまう。 そうではなく、俺は数学も得意な文系だ!というのなら行けるかもしれん。 最近は経済学部が理系化しつつあるという話だし。 いずれにしても個人差の方が大きい。学生なら、やってみて面白くなければ諦める、でいいと思うが。 面白いと思えて続かないようなら向いてない。 >>654 むしろ向いてる気がする 数学とか論理によりすぎだと変なこだわりがあったり 現実のあいまいさに適応できなかったりするから 現実的な手続きや広範な知識が必要な化学が得意だったら適正ばっちりじゃないか >>654 高校生物=ほぼ暗記 高校化学=暗記7割、理論3割 高校物理=ほぼ理論 高校数学=8割理論、2割パターン暗記 (高校国語/英語/社会=ほぼ暗記) じゃね? だから高校化学/生物が得意だからといって、抽象/論理思考の能力は分からない。 (無いとは言わないが、得意とは判断できない) 逆に暗記が得意なら自然と文系教科で無双することになる。 この理由で文系を選んだのなら、暗記能力>抽象/論理思考能力、ということになり、向いてない。 今時のプログラミングってWebを参照しながらやるもんだし、暗記能力自体はほぼ要らなくなってる。 ただしドキュメントを大量に読むようになってきてるから、国語/英語の能力は重要になってきてるが。 とはいえ、高校英語=ほぼ単語を覚えているかどうか、であり、 現実はポップアップ辞書も使えるし、google翻訳も読めないほどでもないし、そもそも技術英語は簡単だしで、 テストでの英語の能力よりも、何を書いてあるか読み解く方が重要で、 いわゆるTOEIC等とは違う尺度だから、高校英語の点なんて全く当てにならないが。 ただまあ、学生なら、グダグダ言わずにやってみて、面白いと思えなければ向いてない、でいいと思うよ。 ただ、ド初心者なら、>>648 の言うとおり、他言語の方がいいと思うが。 >>657 まあ、国語は暗記でも行けるかもだけど、読解系の問題は論理思考でいけばかなり楽できるんだぞ。 >>659 勉強しなくても、論理思考さえできれば、ほとんど正解できるってこと。 つかな、多分、解く過程が数学と同じなんだよ。 ただし数学自体ではないから、数学の成績自体はあまり関係ないけど、 数学めいたものが嫌いな場合には向いてない。 そして大体の場合は好き=得意科目になるから、 集団から選抜するのなら数学の試験を課すなり、面倒なら一律文系お断りってのも当たっている。 (もちろんプログラミング課題を課せるのであればそれが一番いいが) よくある初心者向けのプログラミング課題、 ・ソース○○に対して、出力△△を得たい、どうすればいいか、 に対して、実際は適切なメソッドや典型的な手法を組み合わせて対応するわけだろ。 これが、公式やお約束的解法を組み合わせて問題を解く「高校数学」と似てる。 そして実際のプログラミングなんて、 上記単発のお題が階層跨いでフラクタルになっているようなものだから、 ある意味数学パズルをずっと解き続けるようなもので、数学が嫌いだと持たんだろ。 ただし本来はその先の、 「こうすればこんなに簡単に実装できるのか」という構造を思いつける奴が「センスがある」となるわけだが、 これについては選抜の仕方(適正判断の仕方)は分からんなぁ。 ただ、いわゆる「エレガントな解法」というのが存在するのも数学だけだし、 プログラミングと数学はかなり構造が似ているのだと思うよ。 >>660 論理思考、最強!みたいな勢いだけれども、 その論理思考の中身というのが常識を外れているような気がする 命題A: 「1 + 1 = 3」 ならば「2 * 3 = 6」である とするとき、命題Aは正しいか間違っているか、また、その理由は? >>661 プログラミングは証明に似ているのには理解が及びますね。 ただ、普通の証明よりもずいぶんと細かいことに気をくばらないといけない気がします。 「型」を数学であつかっている例はありますか? >>646 マーチ文系の俺は現場に入るまで3週間 足引っ張らない程度になるまで3か月 無双するまで1年だったかな 3年たった今では Golomb 符号とたわむれてる >>663 証明問題じゃねえよ。つかおまえも数学出来なかった口だろ。 数U数Vはほぼパターン通りだけど、 数Tの難しい問題はたいがい「エレガントな解法」ってのがあって、裏技みたいに簡単に解けたりするんだよ。 それはそれこそ東大の過去問とか見てみればいい。 或いは三平方の定理とかでも何通りも証明方法があって、おおっ、てのもあったりするだろ。 (ただ、この話が通じない時点で説明しても無理なのは確定だが…) 実際のプログラミングもこれと同じで、データ構造を正しく整理すれば制御構造もものすごく単純に出来たりするんだよ。 だから数学的な「エレガントさ」を追求するのが好きじゃないと向いてない。(というか上達しない) そして「型」なんてのはノートに引いてある罫線みたいなもので、プログラミングの本質とは全く関係ない。 ただし型自体は圏論だっけ?Haskellの連中がやってたはずだけど。詳しくは知らんが。 で、QZ、君は色々文句言われてたりしてるのを見たことがあるが、俺自身は知らんからそれはどうでもいい。 ただC++のスレで「色々忘れてしまうんで…」とか言い訳してたろ。 (別段それについて責めるわけではないが)それは覚え方が悪いんだよ。 例えば高校の物理、 ・ma=Fとsin/cosだけ覚えて後は組み合わせるだけだが、 // (A) ・「垂直にぶら下げたケース」「斜面においたケース」「バネがくっついたケース」とか、// (B) 別々に覚えたがる奴はいるんだよ。それで、(A)が抽象思考(分類)できる奴、(B)が出来ない奴、となるんだよ。 そして、プログラミングで必要なのは(A)で、(B)は死ね、でしかないんだよ。 で、多分君は(B)派なんだよ。だから「忘れる」とかいうことになる。 (A)だったら忘れるも何もない。どの言語でも同じものを使っていて、 それを「ひらがな」「カタカナ」「英語」のどれで書くか、でしかないから。 ただ自分が(A)なのか(B)なのかは簡単に分かるとして、(高校の物理に最初からついて行ければA、無理ならB) これは思考の癖だから、簡単には直せないんだよ。だから向き不向きはかなりある。 単純に言えば、脳内のCPU/ストレージのコストによる。 いちいち圧縮/展開してでもストレージをケチりたい=CPUの速さに対して記憶が得意ではない場合は(A)、 いちいち展開するくらいならベタでストレージした方が楽=CPUのコストに対して記憶コストが安い場合は(B)になる。 そしてこれは無意識領域で作用するから、簡単には変えられない。 (A)の連中は最初から抽象思考する、というより抽象思考ベースだから、プログラミングにはフィットするけど、 例えば高校の歴史、「○○年に何がありました」という単発事象を別々に暗記するのには全く向かない。 逆に(B)の連中にはこれが向いているが、抽象思考するためにはいちいち「意識的に」圧縮/展開する必要があり、 ネイティブ(A)の連中にプログラミングでは太刀打ちできない。 それでも(B)の連中が得意な「記憶」でプログラミングに対処しようとした結果が「デザインパターン」だ。 だから(B)の連中はデザインパターンにすがるし、新しいパターンをどんどん登録しようとする。それが上達への道だから。 (A)の連中は最初から「デザインパターン?何それ?おいしいの?」だし、「名前つけただけだろ」程度でしかないんだよ。 で、QZ、君はデザインパターンにすがってるタイプだとC++スレで言ってたろ。 ここでも(B)だと分かるんだよ。 で、俺は、(B)の連中はわざわざプログラミングする意味無いと思ってるんだよね。向いてないから。 多分、その記憶コストの安さを生かした、何か別のことをすべきだよ。 パターン暗記で対応することも出来るけど、それだとコピペプログラマ程度にしかどうせなれないし。 Haskellは非常にエレガントだからな プログラマーたるもの一度はCとHaskellに触れるべきだ 願わくばHaskellのエレガントさとCの自由さを合わせ持つ神話的な言語が生まれて欲しいものよ 回答ありがとうございます プログラマになりたいのは、単純に稼ぎたいからです んで色んな言語の基礎というか素地になってるのがCみたいだから まずはCをと、今いろいろ入門書を読んでるところです 難しいけど楽しくて仕方ない感じなのですが 大学は駅弁経済(だいたいmarchクラス)で数学無しで入ったので 今更ながら後悔してます(高校で挫折したクチ) ココ見てるとやっぱりこの世界はすごく論理とセンスがモノを言うんだな、と ちょっとビビってます Cより楽な言語に移ろうかとも思案中ですが、 もう少し基礎を固めてからにしようと思ってます また覗きに来ますねw 稼ぎたいからプログラマって、何か凄い誤解してるような 金融行っとけ マスコミは今後怪しい 数学無しの経済ってアリなの?? >>669 ソフトウェアで稼ぎたいならcはないかな javascript と python を頑張った方が良いかと ここら辺の高校数学とか延々述べてる回答者たちは荒らしなの? >>669 > 難しいけど楽しくて仕方ない感じなのですが これなら当面は問題ない。駅弁なら時頭も問題ないだろう。 > ココ見てるとやっぱりこの世界はすごく論理とセンスがモノを言うんだな、と 残念ながらそうでもない。 というか、(どの仕事でも同じだが)結局、仕事の9割以上は「与えられた分担をきっちりこなすこと」であって、 それは「パターン暗記」でほぼ何とかなってしまう。ここが逆に不幸なところで、 彼らもまた「仕事が出来る」うちに入ってしまい、彼ら流、つまり「パターン暗記」流を推奨してきたりする。 (C++のスレでだいぶ言ったが、俺はJavaはもうそっちに行っちまって戻れないと見ているから、Javaは俺は勧めない) 逆に、仮にセンスがあったとしても、仕事の1割以下でしかそれを発揮する機会がなく、埋没してしまう。 ここら辺を突破しようとしたのがGoogleの20%ルールだったわけだ。 > Googleにおいて、従業員は「勤務時間の20%を他のプロジェクトに費やしても良い」のではない。 > 「費やさなければならない」のだ。これは人事評価の対象にもなり、 > 従業員はその20%の時間を使って「本業以外の何か」を生み出すことを期待されている。 > https://innova-jp.com/google-20-rule/ 「パターン暗記」では未来には対応できない。センスがない奴は、何をやっていいかすら分からない。 とはいえ、実際はこれを隠れ蓑に遊ぶ連中も多くて、って話だったが。 (少なくとも「パターン暗記」するタイプのまじめ人間からはそう見えた) 実際にそれが無駄だったかどうかは分からん。 https://www.countand1.com/2016/07/google-20-percent-time-implication-for-making-failure-be-good-learning.html 結局世の中OSSに完全にシフトしつつあるのも、 OSS側でセンスがある連中がつるんで好き勝手やるのにプロプライエタリでは全く太刀打ちできないからであってね。 ただし、公務員的にITで働きたいのならJavaだろう。向こう20年仕事はあるだろうし、あまり変化もない。 それ以前に、稼ぎたいのなら金融、ってのは当たっているが。 (なお金融関係のプログラマならPythonと聞いているが、多分これは日本国内の話ではない、 というか、日本国内に「金融関係のプログラマ」がそもそも居ないと思う) >>674 いや、俺が言っているのはそっちじゃない。 インフラは COBOL -> Java の移行中だ。君はこの意味で言っている。 俺が言っているのは以下で、 https://jp.stanby.com/media/programming_ranking2017/ Pythonの右端の連中は金融関係だ、と聞いている。 具体的には、デリバティブとかアービトラージとか、そっち系。 Cはお察し、として、Javaの右端の連中は何だろう? >>665 >証明問題じゃねえよ。つかおまえも数学出来なかった口だろ。 数学の本道は証明問題にあるとおもっていますが 数学の本をみればわかりますが、定義、命題、証明をひたむきにくりかえしていますよ。 https://ja.wikisource.org/wiki/%E5%88%9D%E7%AD%89%E6%95%B4%E6%95%B0%E8%AB%96%E8%AC%9B%E7%BE%A9 >>655 >三平方の定理とかでも何通りも証明方法があって、おおっ、てのもあったりするだろ。 でしょう、証明問題こそプログラミングに似ていると思っています。 >「色々忘れてしまうんで…」 そして、証明をいちいち覚えるんじゃない、その都度再構成できるように努めています。 といって、数学の本はときどき「証明は読者にまかせる」とくるのですが、それはちょっと困ります >>677 おかしくないですよ、論理学的には。 「論理思考の中身というのが常識を外れている」の一例です。 >>662 "1"という数字は数値に直すと1.5であり、その他の数字は通常と同じであるとする。 という一文が手前に挿入されるとその後の計算は正しくなる。 >>676 君が「証明問題」に限定しようとしているのはなぜだ? 証明問題以外でも、俺はプログラミングと数学は雰囲気やノリが酷似していると思うが。 >>669 あと、職業として選ぶのなら、当たり前だが、君に特に抜きん出た才能がなければ、 ・君が半年で出来るようになったことは、普通の新人も半年で出来るようになること ・君が半年かかったことも、センスのある新人なら1-3ヶ月で習熟してしまう可能性もあること を考えておかないといけない。 威張り散らす必要はないけど、あの人イマイチだよねって言われ続けるのも辛いでしょ。 適性がないところを職業にするのは悲惨だと思うぞ。自分の適性はよく見極めた方がいい。 逆に、君にセンスがあり、 ・普通の人なら半年かかるところを3ヶ月で会得 なら、やっているうちにどんどん差が勝手についてしまうわけでね。 >>680 まあ数学とプログラムとでは、双方に互いに似たような思考方法を行う、という意味では大枠同意します 特に「証明」に拘っているわけではないのですが、拘ってしまいました…忘れてください… てか、プログラミングは数学の範疇に入らないか? 計算機に実行させる計算手順書だし。 >>682 個人的にはComputer=計算機ってのはかなり違和感があるんだよね。 プログラミングって、むしろシーケンサだろ。(処理手続きをひたすら記述する) 数学に似てるのは、結局、チューリングマシンからきてるのだと思う。 もちろん「このプログラミング言語はチューリング完全です」なんてやってるのは数学者であって。 これとは逆に、ニューラルネットワークなんて、正直、まともに証明すらされてないだろ。 なんだか分からないけどうまくいきます、程度であって、 ニューラルネットワークがチューリング完全なのかどうか、誰も証明して無いと思うし、(俺の知る限り) それ以前に、プログラミングなんて出来る状態じゃない。 今も機械学習で係数を探している程度、つまりトライアンドエラーしか出来ていないわけであってさ。 だから、将来的にニューラルネットワーク等、チューリングマシン以外をプログラミングできるようになれば、 数学じゃないプログラミング手法が見つかる可能性はあると思う。 実際、機械学習自体は物理/数学の教え方(理論を教えてそれを適用)ではなく、 語学の教え方(習うより慣れろで、ひたすら知識(結果)を積み上げる)に近いし。 ところで、人工知能のバグ取りってどうやんの? それともダメな子だから抹殺しちゃうの? 人格と知識は分離可能になるだろう。人格モジュールを切り替えたり、アップデートするんだろう。 自分自身が間違っていると判定されたら(サニティチェック)、「人格を初期化または取り換えて下さい」と表示される。 >>685 シーケンサってコンピュータの一種じゃ…? というか計算しないで手続きだけひたすら書くのって わりと特殊な方じゃないかな シーケンサー(通称PC)はアセンブラもあったりするけど 基本デノイマンだよ。 >>692 それはCに階層記述能力が欠けているからだ。 例えばNode(JavaScript)のコーディングルールでは、関数は15行以下にしろとなっている。 > Write small functions > Keep your functions short. A good function fits on a slide that the people in the last row of a big room can comfortably read. > So don't count on them having perfect vision and limit yourself to ~15 lines of code per function. > https://github.com/felixge/node-style-guide#functions-1 やれば分かるが、15行で書く為には、中位記述と下位記述を明確に分け、下位記述は全て関数で括り出すことになる。 このとき、中位記述の関数はベタに手続きだけひたすら書くことになる。 俺も最初は戸惑ったが、実際、この方が読みやすいし、自己ドキュメント化する。 ただしCだとこれはちと辛い。 JavaScriptだとそもそも下位記述がほぼ無く、大体何かしらのメソッドを呼んで終わるし、 階層を自由に作成できるし、プロトタイプ宣言も必要ないし、デフォでクロージャだから外変数を自由に掴める。(引数にする必要がない) Cだと関数内関数が出来ないし、プロトタイプ宣言も必要だし、全部引数で渡さないといけないし、 GCも無いから宣言スタイルでも書きにくい。また、関数呼び出しも無駄ならケチる文化もある。 最大15行なら、実際は5-10行の関数が氾濫することになるのだが、Cでこれをやるとよけいに読みにくくなる。 だから、Cでは珍しいだろうけど、JavaScript等手抜き系スクリプト言語だったら割と普通だったりするはずだよ。 Cはクラスがないせいで戻り値が使い物にならん 中でMallocして返すとすぐメモリリークする 文字列や配列を扱う関数は 第一引数と第二引数に結果格納用の配列と最大長を渡すというまだるっこしい作業をせんといかん Cで言語を学ぶと悪いコーディングの癖がついてしまう オブジェクトへのポインタを1つ追加するだけでリエントラントな作りになるだろうに。 >>696 それがいい習慣というものです、配列(の先頭)と文字列長をセットで扱うのは基本中の基本です win32api をみればわかりますが、一度目には自分が用意しなければならない領域の大きさについてお伺いをたててから、 二度目にやっと目的の情報を手に入れる、これは C ではセットですね c++ で文字列型のような便利なアイテムを使っていたために、だんだん馬鹿になってきていたことに、最近ようやく気がつきました:−) バッファの大きさを受けて範囲内で書き込む sprintf じゃなくて sprintf のフォーマット処理した結果、こんだけの大きさが欲しいって答える関数はないのかな >>705 snprintf() は >>703 の希望をかなえてはくれないのでは? >>705 snprintf は 渡した大きさで打ち切ることはするけど、完全に必要なサイズを返すっけ? 書き込んだ文字数だから打ち切った場合たかだか渡した大きさ-1 だと思うけど >>707 自己レス C99 から戻り値が完全な長さを答えてくれるみたい なので len = snprintf(buf, 0, .... ); len+1 以上確保して snprintf(buf, len+1, .... ); これが出来るのか >>708 普通は、とりあえずやってみて戻り値判定したあと切り捨てられていたら大きめのバッファにreallocしてつかうんじゃないかな。 確保するメモリサイズは一定の方がいいと思うんだ。 まぁ、Cなら大抵の場合、サイズオーバーでエラー処理へとばす気もするけれど。。。。 asprintf() も良いよね。 GNUの拡張だけど。 >>694 頭悪そう 分割数に依存してO(n**2)で命名の手間が増える O(n**2)は行かないかもしれないがO(n)よりは大 >>708-709 manの「準拠」のところで、snprintf()の第2引数sizeに0を指定できる、 返り値を必要なバッファサイズを決めるのに使えると明記されてるね。 これは有難い。 >>712 エリートな人だなぁ。俺にはよく分からんけど… 男は度胸! 何でもためしてみる、か。 >>712 のやつは多分中々みつからないと思うぞ。>>712 のPCのディスクの中か心の中にしかないんじゃないか?w char aznable は、いつか、やるかも、しれない -able は「〜することができる」という意味を加える接尾語と解釈できるから azn と略せる何か動詞っぽい操作を思いつけば char aznable; を 「合法的に」使うことができるね。 単なるフラグなら int なり bool なりを使え、と言われると弱いけど。 >>713 横だが 関数名が事実上のドキュメントになるんだよ 15行の関数量産したらfunc1, func2, ...となるのが目に見えている 途中の欠番で変更履歴の推測も可能 素晴らしいドキュメントだな ファンクなあ。 アシッドテイストを入れてもう少しオサレな感じにすれば爆発的にヒットするだろうになあ。 関数名はプログラマがこう動いて欲しいという願望まで func なんて関数名見かけたら fack に置き換えるわ >>728 ドイツ語とか関数名変数名だけでコード9割埋まりそう そう考えると世のプログラミング言語のベースが中国語だったら表意文字だしだいぶ可読性高そう 日本語はむしろ同じ物を表す書き方が平仮名片仮名漢字と何通りもあるから面倒だろ。 表のように与えられた時各学年の人数と全校の人数をふ計算するプログラムを教えてください。 できれば今日中に。 1組 2組 3組 4組 5組 1年 33 35 34 32 36 2年 34 33 35 33 31 3年 31 32 36 30 35 >>734 は学校の宿題か課題の代行をタダでやってくれ、みたいに見えるなぁ。 親切心で教えることが質問者のためになるか疑問ってこと。 元のデータはどういう形で与えられるのかな。 質問の内容から見て、学年数もクラス数も一定で 配列としてソースファイルに埋め込みで良さそうだけど。 学年数やクラス数まで実行時の入力によって可変、となると かなり面倒な話になるね。 安心して翌朝覗いてみたら何も上がってないという寸法さ execve関数を使うためにclearenv()で環境変数を初期化すると手順にあるのだけど この関数の影響範囲をどう調べればわかるか調べ方もしくは影響範囲が知りたいです manページを見ても名前と値の組の環境変数を〜みたいな話しかなくて困ってます >>734 宿題用のスレなかったっけ? C言語のはなかった? >>740 影響範囲?そりゃ環境変数使うプログラム全てだろう。特にPATH使うようなやつ(外部コマンドをフルパス使わずに動かす可能性のあるプログラム)は影響受けるよね。 その他、動かすコマンドによって影響は違うと思う。これから動かそうとしているコマンドがどういう環境変数を使うかに掛かっている。だからこうだと固定的に言うことができない。 >>744 無知ですまんが 環境変数をクリアするってことは要はLD_LIBRARY_PATHに登録されてるものをすべて無にするってことなのだろうか これは一時的なもの?それとも永続的なもの? ここらを参考にsystem関数ではなくexecveを使う方針になったのだけど むしろ改悪になってるんじゃないかとなってきている https://www.jpcert.or.jp/sc-rules/c-env33-c.html http://www.jpcert.or.jp/m/sc-rules/c-env03-c.html 下を読んでなんとなく何がリセットされるのかはわかってきたけども それがどう影響を与えるのだろうかと https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/c703.html 下記のように書いてあるけども むしろ影響範囲でか過ぎるんじゃねぇか?ってのが困ってるところ 確かに改竄とかの対策にはなるとは思うんだけど リセットしてしまったことによって使えなくなるものについてはどう担保するのかがわからない このクリアが呼び出した関数内だけなのか、呼び出したプロセスやスレッドだけなのか、呼び出したら再起動までずっとなのか、呼び出したら再起動しても以降ずっとなのかと (2) 環境変数のクリア 外部プログラムをコールする(exec(3))前に、環境変数をすべてクリアするとより安全になる。環境変数をクリアするには、clearenv(3) をコールすればよい。 clearenv(3) が無い環境では、以下のように extern char **environ 変数を直接クリアする。 environ = NULL; ※上記の方法で環境変数をクリアしても、system (3) による子プロセスの環境変数は、クリアされず再設定されたものになる。 >>745 一時的もなにもそれを実行したプロセスとそのプロセスからexecしたプロセスにしか影響しないよ。だからfork()後に子プロセスだけでやるなら親プロセスには影響しないしその他無関係なプロセスにも影響はない。 >>745 環境変数はシステム全体で一箇所に持っているものではなくプロセス単位で持ってるものだからね。そしてexecの時に引き継ぐ事もできるようになってるだけ。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる