アカウント名:
パスワード:
冒頭だけ読みましたが、これは初心者殺しのマニュアルですね。RMSは多数の罠を仕込んでいます。
1) 最初の罠: gitで公開されているファイルは GNU Texinfo 形式
あなたは git が使えますか? texi から html やpdfを生成できますか? この質問で何を聞かれているか理解できない人は、このマニュアルを読むことさえ出来ません。RMSこわい。
2) 次の罠: 最初のコードはフィボナッチ数を再帰処理で計算する例
いきなり再帰関数です。フィボナッチ数。スタック使って再帰を実行するぜ。メモリブロックの一部がスタックって呼ばれる領域なんだけど、C言語はそこを使って再帰を実現するんだぜ。スタック食い潰したらクラッシュする。どうだC言語は怖いだろっていう怒涛の文章になってます。これがイントロです。RMS頭オカシイ。
3) 1112行目でやっとコンパイル方法が説明されている
1000行ぐらい我慢して読み進むと、やっとコンパイル方法が説明でてきます。 gcc -g -O -o fib1 fib1.c でコンパイルできるよ、って1行だけ。説明はこれだけ。"gcc -g -O -o "の説明は皆無。ひどい
4) トドメの罠 1132行目で gdb が登場
なぜかgdbを起動する方法が紹介されます。起動する方法だけです。gdbを使ったことがない人が 書いてある通りに gdb を起動してしまうと、 gdbって何?これ、どうやって終了するの?という感じで詰みます。
ざっと見た限りでは冒頭の1章で大半の人が挫折する構成になっています。 C言語というかGNU文化を知らない人は読んでも理解できない。GNU文化を知ってる人は読む必要がない。 誰をターゲットにしたマニュアルかがよくわからない出来栄えでした。
GNU Cのマニュアルは既にあるから、それも一緒に読む前提なんじゃねーの?あれもあれで冒頭から間違ってて、Cの言語規格読んだことない奴が書いたんじゃないかと疑う代物だけど。
> プログラミング初心者に対しては C 言語から始めるのではなく~
と記事中にも書かれてるんだから、初心者をターゲットにしてないのは明白なんだけど
これは初心者殺しのマニュアルですね。RMSは多数の罠を仕込んでいます。
Recall Manual Softlyの略だったんだよ
# そっとマニュアルを突き返そう
男は、黙ってmanだろ。
そんなこと言っているから、『RTFM』とか言われそう。 ワタクシ?ワタクシは、まずgoogle様に聞きますが。
#元コメを見てる範囲では、RMS 健在なり!\(^○^)/
初心者にはチュートリアル、経験者にはリファレンス。そーゆーこと。
チュートリアルといえばTurboPascal3.0のは感動的だったなあ。今でもどっかに転がってそう。
老害ですが何か?
> 知らない人は読んでも理解できない。> 知ってる人は読む必要がない。
ダメなマニュアルあるあるすぎる
技術書とかも、わかってから読むとわかるってのよくあるよね (´・ω・`)
ハード(デバイス)のマニュアルはみんなそう。「初見の人に分かり易く」書くつもりなんか絶対に無いんだろうな、っていつも思う。
作った人の覚え書きなのだろう
デバイスのマニュアルは教科書じゃないし電気的な条件とか判りやすいじゃないですか(多分
謎のAPIのマニュアルだって分かりづらかったりするかも
多分、annoymouse coward (11178) と彼 #4322131 の言いたいことは「マニュアルは、分からない人が分かるように書くべし」って考えなんだろう。でもハードでは「マニュアルは、分かる人が分かるように書かれている」と。
「GNU C Intro and Reference Manual」とあるんだから、「Reference manual」を「指導者向けの参考資料」という意味で解釈するべきなんだよ。「manual」には「指導書」という意味があります。デバイスの manual は「*取扱*説明書」(製品仕様書)の意味です。手引きや教習という意味で解釈すべきではありません。「Intro」は、製品のデモンスト
デバイスのマニュアルの話を持ち出した#4322131です。#4322131はコメント先の「わかってから読むとわかる」に反応しただけなので、大元のGNU C 言語リファレンスマニュアルについてはコメントしません(そもそも読んでないし)。#4322131でちゃんと書きませんでしたが、問題にしたいのは電気的条件等ではなくソフトウェアインターフェースの説明です。#4323084のいう「API」がソフトウェアインターフェースのことだとしたら同意見と言うことでしょうか。デバイスのソフトウェアインターフェース自体がわかりにくいというか「素直じゃない」のは、そのデバイスの歴史的に最
探究のパラドック。Smalltalkの頃から指摘されてる。ダメかどうかは関係ない。
intで計算できる程度のフィボナッチ数を再帰で求めたとしてスタックオーバーフローになるわけないアホか
まともなコードとコンパイラならスタック消費しないからオーバーフローになるわけないアホか
まともなコンパイラなら再帰呼出しで組まれたフィボナッチ数の計算もループに展開してくれる、とか思ってるアホかな?
末尾再帰も書けないカスかな試しにアセンブリ出力してみたが、ちゃんとループに展開してくれたぞ
試しにアセンブリ出力してみたが、ちゃんとループに展開してくれたぞ
件のコードをgcc 12.2を使って最適化指示`-Os`を指定してコンパイルしてみたが https://godbolt.org/z/qvjeaedon [godbolt.org] fib: pushq %rbp xorl %ebp, %ebp pushq %rbx movl %edi, %ebx pushq %rcx.L3:
試されたコンパイラは何ですか??ちゃんとループに展開されたコードが見てみたいです。是非教えて。
Lispのコメントのところでも勘違いしている奴がいるが、フィボナッチ数と階乗を取り違えてるんじゃないかな。階乗でも、素直に書くと末尾再起にはならないからそこは一工夫いるけど。
#4322148は件のコードの通りFnからF₁へと遡る再帰コードのことを言ってるのでループに展開されることはない。(もしかして今どきのコンパイラはこれもループ展開されるの?)
#4322180は#4322048で「まともなコード」と書いてあるので(同一ACなら)リンク先の件のコードを見てない可能性がある。#4322180はF₁から昇順でFnを求めるコードを思い浮かべてそう。この場合ループに展開できる再帰関数は作れる(しかしながら、コンパイラが気を利かせてループ展開してくれるにしても、デバッグが微妙になるから最初からループ処理するコードを書くのがまともだと思う。)
最適化用にUBにしてる部分踏んで罠とか言う奴と同類
何言いたいのかわからんけどアホは#4322148 [srad.jp]と#4322180 [srad.jp]で確定だぞ
#4322218だがフィボナッチ数列でも、強引だけど例えば…#define FIB(n) _fib(n, 1, 1)
int _fib(int n, int f_1, int f_2) { if(2 >= n) { return f_1; } else { n--; return _fib(n, f_1 + f_2, f_1); }}ならループ展開される(のでスタックを消費しない)可能性があるでしょ?ってこと。(そもそもループに書き換えた方がいいよね。)
もちろん件のコード(スタックを消費する)とは全く違うので、そもそもすれ違ってるよねってことが言いたい。
int _fib(int n, int f_1, int f_2) { if(2 >= n) { return f_1; } else { n--; return _fib(n, f_1 + f_2, f_1); }}ならループ展開される(のでスタックを消費しない)可能性があるでしょ?ってこと。
「GNU C Language Intro and Reference Manual」のコード以外の話をする意図がサッパリわからん
要するに、#4322180がなぜ「GNU C Language Intro and Reference Manual」のコードを見ないのか?ってことか…
前にも書いたが#4322048(=#4322180だとして)の「まともなコードと」って文から「GNU C Language Intro and Reference Manual」のコードを見ていない可能性を読み取ることはできる。
コードを見ない原因も「まともなコード」から若干類推できる。そもそも再帰呼び出しはあまり「まとも」とは言えない。少なくともスタックオーバーフローを防ぐコードを追加する必要がある。だからこそannoymouse coward (11178)にも取り上げら
C言語をモノにできなかったLinuxerが挑戦してみたです。makeinfo して info -f c。
1. コピペしたけどビルドできませぇん(泣)K&Rとは違い、#include<stdio.h> なんておまじない(ごめんなさい)は書いてくれてないです。
2. コンパイラに怒られながらなんとかmain()にくるみました。でも何も出ませぇん(printfとかは知ってて当然?)
3. なんとか繰り返し処理で出せました。意外と重いですねぇ...
次のChapter(2 A Complete Program)に模範解答と解説が。なんか古典を苦労して読んだら、奥付に全訳があったような脱力感。
現代の子供は、そのぐらいで音を上げるのか。答えが提示されているだけマシだと思わねえんだな。ヒントはすでに出ている。あとは調べるだけ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
これは無理ゲー (スコア:5, おもしろおかしい)
冒頭だけ読みましたが、これは初心者殺しのマニュアルですね。RMSは多数の罠を仕込んでいます。
1) 最初の罠: gitで公開されているファイルは GNU Texinfo 形式
あなたは git が使えますか? texi から html やpdfを生成できますか? この質問で何を聞かれているか理解できない人は、このマニュアルを読むことさえ出来ません。RMSこわい。
2) 次の罠: 最初のコードはフィボナッチ数を再帰処理で計算する例
いきなり再帰関数です。フィボナッチ数。スタック使って再帰を実行するぜ。メモリブロックの一部がスタックって呼ばれる領域なんだけど、C言語はそこを使って再帰を実現するんだぜ。スタック食い潰したらクラッシュする。どうだC言語は怖いだろっていう怒涛の文章になってます。これがイントロです。RMS頭オカシイ。
3) 1112行目でやっとコンパイル方法が説明されている
1000行ぐらい我慢して読み進むと、やっとコンパイル方法が説明でてきます。 gcc -g -O -o fib1 fib1.c でコンパイルできるよ、って1行だけ。説明はこれだけ。"gcc -g -O -o "の説明は皆無。ひどい
4) トドメの罠 1132行目で gdb が登場
なぜかgdbを起動する方法が紹介されます。起動する方法だけです。gdbを使ったことがない人が 書いてある通りに gdb を起動してしまうと、 gdbって何?これ、どうやって終了するの?という感じで詰みます。
ざっと見た限りでは冒頭の1章で大半の人が挫折する構成になっています。 C言語というかGNU文化を知らない人は読んでも理解できない。GNU文化を知ってる人は読む必要がない。 誰をターゲットにしたマニュアルかがよくわからない出来栄えでした。
Re: (スコア:0)
GNU Cのマニュアルは既にあるから、それも一緒に読む前提なんじゃねーの?
あれもあれで冒頭から間違ってて、Cの言語規格読んだことない奴が書いたんじゃないかと疑う代物だけど。
Re: (スコア:0)
> プログラミング初心者に対しては C 言語から始めるのではなく~
と記事中にも書かれてるんだから、初心者をターゲットにしてないのは明白なんだけど
Re: (スコア:0)
これは初心者殺しのマニュアルですね。RMSは多数の罠を仕込んでいます。
Recall Manual Softlyの略だったんだよ
# そっとマニュアルを突き返そう
Re: (スコア:0)
男は、黙ってmanだろ。
そんなこと言っているから、『RTFM』とか言われそう。 ワタクシ?ワタクシは、まずgoogle様に聞きますが。
#元コメを見てる範囲では、RMS 健在なり!\(^○^)/
Re: (スコア:0)
初心者にはチュートリアル、経験者にはリファレンス。そーゆーこと。
チュートリアルといえばTurboPascal3.0のは感動的だったなあ。今でもどっかに転がってそう。
老害ですが何か?
Re: (スコア:0)
> 知らない人は読んでも理解できない。
> 知ってる人は読む必要がない。
ダメなマニュアルあるあるすぎる
Re: (スコア:0)
技術書とかも、わかってから読むとわかるってのよくあるよね (´・ω・`)
Re: (スコア:0)
ハード(デバイス)のマニュアルはみんなそう。
「初見の人に分かり易く」書くつもりなんか絶対に無いんだろうな、っていつも思う。
Re: (スコア:0)
作った人の覚え書きなのだろう
Re: (スコア:0)
デバイスのマニュアルは教科書じゃないし
電気的な条件とか判りやすいじゃないですか(多分
謎のAPIのマニュアルだって分かりづらかったりするかも
Re: (スコア:0)
多分、annoymouse coward (11178) と彼 #4322131 の言いたいことは「マニュアルは、分からない人が分かるように書くべし」って考えなんだろう。
でもハードでは「マニュアルは、分かる人が分かるように書かれている」と。
「GNU C Intro and Reference Manual」とあるんだから、「Reference manual」を「指導者向けの参考資料」という意味で解釈するべきなんだよ。「manual」には「指導書」という意味があります。デバイスの manual は「*取扱*説明書」(製品仕様書)の意味です。手引きや教習という意味で解釈すべきではありません。
「Intro」は、製品のデモンスト
Re: (スコア:0)
デバイスのマニュアルの話を持ち出した#4322131です。
#4322131はコメント先の「わかってから読むとわかる」に反応しただけなので、大元のGNU C 言語リファレンスマニュアルについてはコメントしません(そもそも読んでないし)。
#4322131でちゃんと書きませんでしたが、問題にしたいのは電気的条件等ではなくソフトウェアインターフェースの説明です。
#4323084のいう「API」がソフトウェアインターフェースのことだとしたら同意見と言うことでしょうか。
デバイスのソフトウェアインターフェース自体がわかりにくいというか「素直じゃない」のは、
そのデバイスの歴史的に最
Re: (スコア:0)
探究のパラドック。Smalltalkの頃から指摘されてる。ダメかどうかは関係ない。
Re: (スコア:0)
いきなり再帰関数です。フィボナッチ数。スタック使って再帰を実行するぜ。メモリブロックの一部がスタックって呼ばれる領域なんだけど、C言語はそこを使って再帰を実現するんだぜ。スタック食い潰したらクラッシュする。どうだC言語は怖いだろっていう怒涛の文章になってます。これがイントロです。RMS頭オカシイ。
intで計算できる程度のフィボナッチ数を再帰で求めたとしてスタックオーバーフローになるわけないアホか
Re: (スコア:0)
まともなコードとコンパイラならスタック消費しないからオーバーフローになるわけないアホか
Re: (スコア:0)
まともなコードとコンパイラならスタック消費しないからオーバーフローになるわけないアホか
まともなコンパイラなら再帰呼出しで組まれたフィボナッチ数の計算もループに展開してくれる、とか思ってるアホかな?
Re: (スコア:0)
末尾再帰も書けないカスかな
試しにアセンブリ出力してみたが、ちゃんとループに展開してくれたぞ
Re: (スコア:0)
試しにアセンブリ出力してみたが、ちゃんとループに展開してくれたぞ
件のコードをgcc 12.2を使って最適化指示`-Os`を指定してコンパイルしてみたが
https://godbolt.org/z/qvjeaedon [godbolt.org]
fib:
pushq %rbp
xorl %ebp, %ebp
pushq %rbx
movl %edi, %ebx
pushq %rcx
.L3:
Re: (スコア:0)
試しにアセンブリ出力してみたが、ちゃんとループに展開してくれたぞ
試されたコンパイラは何ですか??
ちゃんとループに展開されたコードが見てみたいです。是非教えて。
Re: (スコア:0)
Lispのコメントのところでも勘違いしている奴がいるが、フィボナッチ数と階乗を取り違えてるんじゃないかな。
階乗でも、素直に書くと末尾再起にはならないからそこは一工夫いるけど。
エスパーしてみる (スコア:0)
#4322148は件のコードの通りFnからF₁へと遡る再帰コードのことを言ってるのでループに展開されることはない。(もしかして今どきのコンパイラはこれもループ展開されるの?)
#4322180は#4322048で「まともなコード」と書いてあるので(同一ACなら)リンク先の件のコードを見てない可能性がある。#4322180はF₁から昇順でFnを求めるコードを思い浮かべてそう。この場合ループに展開できる再帰関数は作れる(しかしながら、コンパイラが気を利かせてループ展開してくれるにしても、デバッグが微妙になるから最初からループ処理するコードを書くのがまともだと思う。)
何れにせよ仕様と実装の区別がついてないアホが他人をアホ呼ばわりしてることにはかわらない (スコア:0)
最適化用にUBにしてる部分踏んで罠とか言う奴と同類
Re: (スコア:0)
何言いたいのかわからんけどアホは#4322148 [srad.jp]と#4322180 [srad.jp]で確定だぞ
Re: (スコア:0)
#4322218だがフィボナッチ数列でも、強引だけど例えば…
#define FIB(n) _fib(n, 1, 1)
int _fib(int n, int f_1, int f_2) {
if(2 >= n) {
return f_1;
} else {
n--;
return _fib(n, f_1 + f_2, f_1);
}
}
ならループ展開される(のでスタックを消費しない)可能性があるでしょ?ってこと。(そもそもループに書き換えた方がいいよね。)
もちろん件のコード(スタックを消費する)とは全く違うので、そもそもすれ違ってるよねってことが言いたい。
Re: (スコア:0)
#4322218だがフィボナッチ数列でも、強引だけど例えば…
#define FIB(n) _fib(n, 1, 1)
int _fib(int n, int f_1, int f_2) {
if(2 >= n) {
return f_1;
} else {
n--;
return _fib(n, f_1 + f_2, f_1);
}
}
ならループ展開される(のでスタックを消費しない)可能性があるでしょ?ってこと。
「GNU C Language Intro and Reference Manual」のコード以外の話をする意図がサッパリわからん
Re: (スコア:0)
要するに、#4322180がなぜ「GNU C Language Intro and Reference Manual」のコードを見ないのか?ってことか…
前にも書いたが#4322048(=#4322180だとして)の「まともなコードと」って文から「GNU C Language Intro and Reference Manual」のコードを見ていない可能性を読み取ることはできる。
コードを見ない原因も「まともなコード」から若干類推できる。そもそも再帰呼び出しはあまり「まとも」とは言えない。少なくともスタックオーバーフローを防ぐコードを追加する必要がある。だからこそannoymouse coward (11178)にも取り上げら
Re: (スコア:0)
C言語をモノにできなかったLinuxerが挑戦してみたです。
makeinfo して info -f c。
2) 次の罠: 最初のコードはフィボナッチ数を再帰処理で計算する例
1. コピペしたけどビルドできませぇん(泣)
K&Rとは違い、#include<stdio.h> なんておまじない(ごめんなさい)は書いてくれてないです。
2. コンパイラに怒られながらなんとかmain()にくるみました。
でも何も出ませぇん(printfとかは知ってて当然?)
3. なんとか繰り返し処理で出せました。
意外と重いですねぇ...
次のChapter(2 A Complete Program)に模範解答と解説が。
なんか古典を苦労して読んだら、奥付に全訳があったような脱力感。
Re: (スコア:0)
現代の子供は、そのぐらいで音を上げるのか。
答えが提示されているだけマシだと思わねえんだな。
ヒントはすでに出ている。あとは調べるだけ。