C言語なら俺に聞け 146
■ このスレッドは過去ログ倉庫に格納されています
C勉強してるんすけど、どの方面の分野で活かされそうですか 組み込み関係、OSやデバイスドライバ作成。及び昔Cで書かれたシステムのデバッグ。 その他、Linux等のUNIX系OSで小規模なツール作る時にも使うかも。 もっと高級な言語を使うときに、裏で何やってるか見当がつくようになる、 というのも大きな利点かも。 Cやるならマシン語の知識も… マシン語の前にTTL回路を… TTLを理解するためにトランジスタ… キリがないけどな。 >>5 アセンブラ(アセンブリ言語)ではなくてマシン語、電子回路・論理回路ではなくてTTL回路と言う所から判断して1980年代の8ビットパソコン世代かな >>6 当たらずと雖も遠からず。誤差はプラマイ50年以内。 私はCを利用してでど底辺から成りあがりたいんですよ とにかく人生を向上させたいホームレス予備軍 ツールとして今目下格闘中 実益求めるならJava かPython あたりの方が需要あると思うけどな 今やC言語は学習用の通過点か、あるいはニッチな趣味人のためのプログラム言語だよ さもなければ「Cでプログラムを組んでみせる」が持ちネタのYoutube芸人とか。 現在は何でもエンタテインメント化できる時代らしいから、演出次第だね。 今から地道にやれば学校のプログラミング教育にうまいこと乗っかって NHK教育で番組持てるかもしれんぞ。 >>4 lC++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが 簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを 追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。 C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、 それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる: - うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が 安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、 もはや笑えるレベルを超えている) - 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに 効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の コードがその素晴らしいオブジェクトモデルに依存していて、直すためには アプリ全体を書き直さなきゃなんない。 言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに 限定するってことは、他の人がそれをめちゃくちゃにしないってことで、 ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい 「オブジェクト・モデル」のたわごとを持ちこまないってことだ。 すべての用途にCは適切な選択である! >>12 コピペは落ち着いてしろ。 それと Linus のメールの和訳とわかるようにした方が良かろう。 >>13 > Linus のメールの和訳とわかるように 極上のお楽しみを自分で潰すこともないかと お楽しみ? C++信者が釣れるってこと? この程度で釣れるかなあ? linuxだってglibという"素敵ライブラリ"に完全依存してるけどな glibに依存してるのはGtk+を使うGUIアプリが主でそれ以外はぼちぼちって感じだぞ ま、しかし、Linuxはkernelだけでその周りはGNU関係のもので埋め尽くされている。 LinuxカーネルだってGCC拡張が無いとコンパイル通らないだろ。 3次元配列を動的に確保する際に、メモリ領域を連続にする以下の処理について解説をいただければと思います。 全部わからないのですが、とくに矢印のところがわかりません。 // メモリ領域が連続な2x3x4の配列 int ***d = (int***)malloc(2 * sizeof(int**)); d[0] = (int**)malloc(2 * 3 * sizeof(int*)); d[0][0] = (int*)malloc(2 * 3 * 4 * sizeof(int)); for (int i = 0; i < 2; i++) { d[i] = d[0] + i * 3; ←不明 for (int j = 0; j < 3; j++) d[i][j] = d[0][0] + i * 3 * 4 + j * 4; ←不明 } // 解放 free(d[0][0]); free(d[0]); free(d); よろしくお願いいたします。 >>23 それが載っていた本の著者とタイトル教えて >>25 個人のサイトになります。 「連続したメモリ領域を持つ多次元配列」で検索して最初に見つかるページです。 一次配列で確保して、インデックスで多次元配列のように使うのが一手かな。 int *pi = (int *)malloc(2*3*4); #define MULTIARRAY(i0, i1, i2) \ pi[((i0) * 3 + (i1)) * 4 + (i2)] これだと区間チェックがないから、本番ではもっと改良が必要だけど。 >>27 訂正。 int *pi = (int *)malloc(2*3*4*sizeof(int)); です。 >>26 そのサイトは酷い勘違いをしている あるいは故意に間違えたソースを書いている C99なら、動的に配列サイズを指定できるから、そんな汚いコードを書く面倒は要らない。 >>26 Cでここまであからさまに間違えているのも今時珍しいが、 そもそもその程度の個人サイトなんて見る価値無いからやめとけ。 その次の検索結果の以下とか、図もあるし、その件についても解説されてるし、そっち読め。 http://www.ibe.kagoshima-u.ac.jp/edu/gengo0/p12.html 見分け方を教えておくと、 10-20行程度のソースをさも一生懸命書いた=初心者レベルと分かるだろ。 Cは歴史も長いからガチの解説サイトも大量にある。 逆に言えば、ガチで解説してないところは全部ゴミ扱いでいい。 あと、メンテされてるかも見ろ。具体的には日付な。 計算機の安全と、プログラマーの業務を守るための意義のある戦いであった。 >>26 です。 皆さんありがとうございます。 ガチの説明が書いてあるサイトを検索してみます。教えていただいたサイトも見てみます。 >>36 33のサイトは鹿児島大学だけど、おそらく大学がいいと思うぜ。理由は以下。 ・入門者のレベルに合ってる ・どこの大学にも入門講座はある ・毎年使われる=メンテされてる まあがんばれ。 大学っつうても、研究室のお遊びブログ的なのはだめだぞ 大学だってちゃんと社会貢献してる。 でも最近は高過ぎるし、多すぎる。 我が人生、フィクションの世界で生活しないといけないんだ。 ttps://stdput.com/dat/program/allocppp.zip >>23 一応元のサイトでやろうとしてたことだけ解説しておくと、 (int*)malloc(2 * 3 * 4 * sizeof(int)); が実際に整数値が入るメモリ領域で、このメモリ領域に d[0][1][1] = num; でアクセスできるようなアドレスの配列を別に malloc してる。 でも普通はこう書くと思うわ。(面倒だったので3x3x3で書いた) int dim1[3][3][3] = { {{0x0000, 0x0001, 0x0002}, {0x0010, 0x0011, 0x0012}, {0x0020, 0x0021, 0x0022}}, {{0x0100, 0x0101, 0x0102}, {0x0110, 0x0111, 0x0112}, {0x0120, 0x0121, 0x0122}}, {{0x0200, 0x0201, 0x0202}, {0x0210, 0x0211, 0x0212}, {0x0220, 0x0221, 0x0222}},}; int *dim2 = calloc(1, sizeof(int) * 3 * 3 * 3); for (int i = 0; i < 3; i++) for (int j = 0; j < 3; j++) for (int k = 0; k < 3; k++) dim2[k + j*3 + i*3*3] = i * 256 + j * 16 + k; (gdb) p dim2 $1 = (int *) 0x602010 (gdb) x/28x 0x602010 0x602010: 0x00000000 0x00000001 0x00000002 0x00000010 0x602020: 0x00000011 0x00000012 0x00000020 0x00000021 0x602030: 0x00000022 0x00000100 0x00000101 0x00000102 0x602040: 0x00000110 0x00000111 0x00000112 0x00000120 0x602050: 0x00000121 0x00000122 0x00000200 0x00000201 0x602060: 0x00000202 0x00000210 0x00000211 0x00000212 0x602070: 0x00000220 0x00000221 0x00000222 0x00000000 int (*dim2)[3][3]; これができないばかりに アホらしい努力を・・・ そろそろ、GUI勉強したいんだけど どれ覚えたほうがいいかわかりません 解説サイト知りませんか? >>49 https://www.google.co.jp/search?q=Win32+API+ 入門 「Win32 API 入門」でググった一番目 手元のWindows7で確かめた範囲では、クリップボードビューアチェインがうまく動かなかった、あとは妥当なところ googleさんは同じ検索ワードの組み合わせでも 人によって結果の表示順序が違うと聞いたことがあるけど、 その紹介の仕方で大丈夫なのかしら。 Windows APIのwikipediaが表示されてる X Window System ってのもあるが・・・あまり使われないか。 まあしかしGUIの学習そのものなら話は別だが、何か実用的なプログラム作りたいのなら他の言語使った方が楽だと思うよ。 >>49 他の人も言っているが、CでGUIはやめとけ。 今現在、また今後とも、GUIをCで積極的に作る理由はない。 GUI用の言語としてオススメなのはJavaScript/HTML/CSSだ。これはほぼ間違いない。 ただし、JavaScriptはコミュニティが腐っていて、 Web情報/紙媒体その他全般的に間違いが多すぎるから、 全くの初心者が正しく学ぶのは難しい。 それでもCでGUIを学ぶよりはマシだ。 今の君には分からないだろうが、CはGUI向けの言語ではない。(変数の生存期間等が) 間違いないオススメなのか、難しいけどマシなのかハッキリしろよ てか真面目な質問だったら可哀想だからネタ回答はやめれ >>57 JavaScript/HTML/CSSは今現在最強だ。これは否定できないし、やれば分かる。 だから、他でGUIを既に知っており、自分で組めるのなら、これでやれってこと。 ここまでは間違いない。 ただし質問者はGUIが初めてだろ。だとするとWebや文献を漁ることになるが、 JavaScriptに関しては間違った情報が多すぎるから、 少なくとも「そんなわけないだろ」と自分で見抜けないとおかしな事になる。 これもほぼ見えた展開だ。だからJavaScripterは馬鹿が再生産されまくってる。 だからGUIもJavaScriptも知らない奴がGUIをJavaScriptで始めるのは問題があり、 判断は分かれるだろう。 それでも俺はGUIをCで始めるよりはマシだろう、という判断だということ。 JavaScript自体は簡単だから、C言語を十分に使えるのなら習熟は容易い。これは事実だ。 ただ、その過程で当然ググルわけだが、 これに間違いが多すぎて、ものすごく回り道をさせられる。 それでも正しい位置に帰ってこられればいいのだが、それは間違いを見抜けるからであって、 間違いを見抜けない奴に間違った教科書を渡したら終わるだろ。 とはいえ、CのGUIなんて(当時はさておき)今から考えたら完全に間違いでしかない。 当たり前だが、GUIなんて無い時代の言語にGUIをやらせようというのは無理があるんだよ。 そしてJavaScriptは最初からGUI用の言語だから、当然相性はいい。 で、どっちを取るか?となると、 今後CのGUIなんて要らんし、JavaScriptの方がまだマシだろ、という判断。 >>59 なら突っ込めよ。 突っ込む勇気すらないのなら黙っていろ。 歴史的経緯からJavaScriptが有名だけど現在では本来の標準仕様はECMAScript 方言や派生の情報が混乱の原因 https://ja.wikipedia.org/wiki/ECMAScript そもそも「GUI勉強」が何を指してるか次第だな Windowsアプリを作れるようになればいいだけなのか スマホ等も含めたクロスプラットフォームな環境を考慮する必要があるのか… GUIっていっても実際の学習ではGとUに分かれてるんじゃないかなあ 手段としてはGraphicalなんだけど、本質のUser Interfaceは不変というかなんというか C言語はGraphicalに向いている訳ではないけど、できなくもないのがコメントしにくい 人間工学まで含めて考えるなら、 例えばWeb画面レイアウトや画面遷移もそういう要素あるからなあ 組み込み機器のHMIはC言語で実装するのも珍しくないだろ CソースはXMLから自動生成とかしてるかもだけどさ テキスト画面に表示してるけどGUIみたいなやつはあるな。BIOS画面とか。 BIOS画面でもグラフィックスの画面で本当にGUIになってるの見たことあるな。多分中にLinuxとX入れちゃってるんだろうけど。 >>68 USBマウス刺さってれば、ちゃんとポインティングしよるぜ 最近のBIOS >>70 BIOSにLinuxとかXとか言ってる奴に構うなよ >>73 その部分はBIOS画面としてしか動かんようにしてあるのでは? 必要最低限のプログラムしかないだろうし。 容量の小さいSDメモリみたいなのに入れてるだろうし。 組み込み機器みたいなものだな。 そんなこともあろうかとレスキュー用のミニBIOSが用意してある ところで元の話はなんだったっけ? CでGUIならGTKがおすすめだっけ? パターン青です、使徒にセントラルドグマを侵食されました 自爆装置が作動します CでのGUIプログラミングは、オススメといっても人それぞれだし。 本人が興味のある手法、あるいは必要に迫らせた手法から順に 手を出してみればいいんじゃないかな Cで低レイヤーなプログラミングを学ぶように低レイヤーなGUIを学ぶならXかなぁ 実用性は皆無とこそ言わずともほぼないが 結局ろくな突っ込みねえじゃねえかよ。 ・CではGUIをやらないのがオススメ だよ。 WindowsアプリにしたければC#でフロントエンドだけ作ってCプログラムを呼べばいいだけ。 VisualStudioがこの作りだろ。 組み込み機器でネットワークありなら鯖立ててブラウザから設定してもらうのがベスト。 ルーターとか全てこれだろ。 今時ネットワークもない機器でGUIなんてほぼねえよ。 そもそもお前らがGTKもQtも使ってねえだろ。 >C#でフロントエンドだけ作ってCプログラムを呼べばいいだけ。 >VisualStudioがこの作りだろ。 そうだったのか、知らなかった。 VBで作っているのかと思ってた。 あれ、JavaScript最強とか言ってたのどうしたの? >>83 ポイントはそこじゃねえ。VisualStudio自体が何で書かれているかは知らんよ。 ただ、今時、GUIまで含めてCで書く必然性はほぼないんだよ。 保守性を上げる為にも、GUIは設定ファイルを生成し、 各種プログラムを呼び出すだけの単純なコントローラに徹するべきなんだよ。 だからこそVSは各種プログラミング言語をカバーできているのであって。 >>84 C#もGUI用言語としてはゴミだぞ。Cよりはマシだが。 >>83 普通にC++だろ word,excelも普通にC++ ※未承認広告※ リソーエディタでさくさくGUIが作れちゃう? 今すぐ試そう。 http://katahiromz.web.fc2.com/re/ja >>82 やらないのがおススメとかどうでもいいんだよ おススメばかりで組める世界なら苦労は無い >>91 ならまずお前がオススメを出せよ、自称苦労人さんよ。 俺なら新規で自由に選択出来るのならまずElectronを検討する。 元々のコードが相当量有るのならグダグダ言わずにそれを使うしかない。 それ以前に、お前らJavaScript/HTML/CSSを知らんだろ? 実際はさらにそれ以前で、お前らGUIなんてほぼやってないだろ? だからそんな低レベルな突っ込みしか出来ないわけでさ。 Cが十分出来るのなら、JavaScript/HTML/CSSの習熟は簡単だ。 CのGUIなんて悲惨なコードにしかならない。 次の機会があるのなら、騙されたと思って、 ElectronからCプログラム/DLLを呼び出すのも検討に加えてみろよ。 どんだけCのGUIがゴミだったか実感出来るから。 web系()が馬鹿ばかりというのも事実だが、逆に言えば、 馬鹿でも何とかなるようにシステムが組まれてるからこそ成立してるのであって、 この意味では学ぶことも多いぞ。 Electron、少し気になって調べてみたらhello worldアプリのファイルサイズが100MB近くになるとか書いてあってワロタ さすが最強だなw >>96 動作環境同梱だからな。 でも実際、それで問題ないからVSCodeやatomに使われてる。 しかしこのスレも本当にゴミになったな。 揚げ足取りしか出来ない馬鹿しか居ない。 文句を言う前に、まずオススメのGUIを出してみろよ。 事実として、CのGUI環境でオススメ出来る物なんて存在しないだろ。 そもそもGUIをCで書いてる奴が居ないんだから。 Electronにはそれ以外にも色々問題はある。 だからElectronが許されるかどうかは確かに問題だが、 それでもいい環境なら今現在GUIに最適なのは間違いない。 ある程度大きなツールなら問題ないだろうけど、 ちょっとしたアプリだと驚きのサイズかな 個人的にお手軽なのはC#(WinForms)で 気合入れるならC++(Win32API)だけど オススメと言われると悩ましいな Cはその手のには使ってない Win32APIの肥大化を危惧してCOMを使うようになったな ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.0 2024/04/24 Walang Kapalit ★ | Donguri System Team 5ちゃんねる