C言語なら俺に聞け 146

2018/04/30(月) 04:47:37.50

C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

前
C言語なら俺に聞け 144
https://mevius.5ch.net/test/read.cgi/tech/1514025223/

次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512
-
※前スレ
C言語なら俺に聞け 145
http://mevius.5ch.net/test/read.cgi/tech/1519046038/

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2018/04/30(月) 18:40:05.50

1乙

2018/05/01(火) 00:44:35.15

C勉強してるんすけど、どの方面の分野で活かされそうですか

2018/05/01(火) 02:49:59.77

組み込み関係、OSやデバイスドライバ作成。及び昔Cで書かれたシステムのデバッグ。
その他、Linux等のUNIX系OSで小規模なツール作る時にも使うかも。

2018/05/01(火) 06:35:10.72

もっと高級な言語を使うときに、裏で何やってるか見当がつくようになる、
というのも大きな利点かも。

Cやるならマシン語の知識も…
マシン語の前にTTL回路を…
TTLを理解するためにトランジスタ…
キリがないけどな。

2018/05/01(火) 06:50:33.19

>>5
アセンブラ(アセンブリ言語)ではなくてマシン語、電子回路・論理回路ではなくてTTL回路と言う所から判断して1980年代の8ビットパソコン世代かな

5 (ﾜｯﾁｮｲ 4193-JpCb) · 2018/05/01(火) 08:02:05.75

>>6 当たらずと雖も遠からず。誤差はプラマイ50年以内。

**デフォルトの名無しさん** · 2018/05/01(火) 09:19:30.14

>>7
すごいね、おじいちゃん！

2018/05/01(火) 14:46:07.71

私はCを利用してでど底辺から成りあがりたいんですよ
とにかく人生を向上させたいホームレス予備軍
ツールとして今目下格闘中

2018/05/01(火) 15:01:37.73

実益求めるならJava かPython あたりの方が需要あると思うけどな
今やC言語は学習用の通過点か、あるいはニッチな趣味人のためのプログラム言語だよ

2018/05/01(火) 17:37:53.41

さもなければ「Cでプログラムを組んでみせる」が持ちネタのYoutube芸人とか。
現在は何でもエンタテインメント化できる時代らしいから、演出次第だね。

今から地道にやれば学校のプログラミング教育にうまいこと乗っかって
NHK教育で番組持てるかもしれんぞ。

2018/05/01(火) 18:15:30.40

>>4
lC++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:

- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)

- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。

言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。

すべての用途にCは適切な選択である！

2018/05/01(火) 21:03:14.34

>>12
コピペは落ち着いてしろ。
それと Linus のメールの和訳とわかるようにした方が良かろう。

◆QZaw55cn4c (ﾜｯﾁｮｲ 5360-c97c) · 2018/05/02(水) 18:01:54.66

>>13
＞ Linus のメールの和訳とわかるように

極上のお楽しみを自分で潰すこともないかと

2018/05/02(水) 19:18:05.28

お楽しみ？
C++信者が釣れるってこと？
この程度で釣れるかなあ？

2018/05/03(木) 09:53:31.82

linuxだってglibという"素敵ライブラリ"に完全依存してるけどな

2018/05/03(木) 16:20:53.83

glibに依存してるのはGtk+を使うGUIアプリが主でそれ以外はぼちぼちって感じだぞ

2018/05/04(金) 05:33:19.95

glib ではなく glibc なのでは?

2018/05/04(金) 05:49:32.75

ま、しかし、Linuxはkernelだけでその周りはGNU関係のもので埋め尽くされている。

2018/05/12(土) 10:50:36.15

>>2
２otu

2018/05/12(土) 22:35:28.33

LinuxカーネルだってGCC拡張が無いとコンパイル通らないだろ。

2018/05/13(日) 03:30:03.29

そだねー

2018/05/14(月) 21:02:48.20

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);

よろしくお願いいたします。