K.Maebashi's BBS

>「別のところにあるのを宣言する」ってのはexternの本質を表していないのですね。 こういう疑問が出てくるということは、言語規格書を読んでみていいレベルということだ 初心者向け解説書は厳密さよりもわかりやすさを優先せざるを得ないので びみょーに不正確だったりすることがある extern の意味するところは[1020]で書いたとおり、結合指定 C なら JIS X 3010:2003 6.2.2 C++ なら JIS X 3014:2003 3.5 厳密なところは自分で JIS 言語規格書を参照してもらうとして、簡単に言うなら extern:外部結合を指定、static:内部結合を指定 外部結合＝その名前が表す実体は、他の翻訳単位または同じ翻訳単位で使うことができる 内部結合＝その名前が示す実体は、同じ翻訳単位で使うことができる ということだ。

ご回答ありがとうございますm(_ _)m 変数と関数の宣言・定義の違いでの説明がしっくり来ました。 >初心者向け解説として「 extern は別のところにあるものを使う宣言」と書いてある書籍を見かけるけど >言語規格書的には大きく間違い (同一翻訳単位中にあってもかまわないので) まさにこれがもう一つ質問したかったことでした。 「別のところにあるのを宣言する」ってのはexternの本質を表していないのですね。

>グローバル変数の名前が偶然かち合ってしまう可能性があります。 (snip) >と書いてもエラーにならないと困ってしまいます。 C++ においては ODR (One Definition Rule) により、これは必ずエラーになる C ではエラーにならない (仮定義の重複を認める) という違いがあるですな。 初心者向け解説として「 extern は別のところにあるものを使う宣言」と書いてある書籍を見かけるけど 言語規格書的には大きく間違い (同一翻訳単位中にあってもかまわないので) 俺も後輩君にそういう説明したことあるし反省っすな。

>ヘッダ中で宣言＋ソースファイル中で定義することは完璧に正しい これはもちろんそうなのですが、 >以下のような小細工コードをいまだに見るけど、現代 C/C++ であれば不要 >#ifdef HOGE_DEFINITION >#define EXTERN >#else >#define EXTERN extern >#endif この小細工は、ヘッダとソースファイルに似たようなものを分散させたくないという面からは有効だと思いますよ。初期化子がうまく書けないとか、文法的にCのパーサを通らんようなマクロを作るなとか、そもそもそんなにグローバル変数使うなよとか、批判があるのはわかりますが。

>分割コンパイルなどで、外部で定義している変数を参照するにはexternを使う、と >よく本に書いてあると思いますが、外部の関数を参照するにはexternを >付ける必要がないように見受けられるのです。これはなぜなんでしょうか。 774RRさんのおっしゃるようにそういう約束だから…なのですが(X3010の6.1.2.2)それを言ってしまうとつまらないので、理由を考えますと。 大規模なプログラムを何人もの人で書いている場合、グローバル変数の名前が偶然かち合ってしまう可能性があります。たとえば a.c: int hoge; b.c: int hoge; と書いてもエラーにならないと困ってしまいます。この場合、それぞれの担当プログラマには、「グローバル変数の値がいつの間にか変わっている」という得体の知れないバグとして見えるはずです。 その点、「externなしで定義できるのは必ず1箇所のみ、それ以外の箇所では必ずexternを書け」という規則にしておけば、リンク時にエラーになるのでこの問題を回避することができます。 では関数の場合はどうかというと、関数名が偶然かち合ったとして、 a.c: int hoge(void) {...} b.c: int hoge(void) {...} とか書いたらどうせエラーです。 つまり、関数の場合、関数の処理を書くブロックの有無で定義と宣言の区別がつくため、わざわざexternをつける必要はない、というのが私の理解です。

そういう約束だから 関数(原型)宣言に extern も static もない場合は extern が補われると考えよう void myfunc(int); // これには extern も static も明示されてないので extern void myfunc(int); // と解釈される規則 この規則は関数の場合にのみ適用されるので、変数宣言には適用されない 以下は、言語規格書の厳密解釈なので、一読してわからなかったらスキップしてね ・関数宣言で指定できる linkage は static か extern かどちらかだけ (無指定も OK) ・ static が明示されている関数宣言は internal linkage ・ internal linkage でない関数宣言は external linkage ヘッダ中で宣言＋ソースファイル中で定義することは完璧に正しい ----hoge.h---- void hogefunc(double); // This declaration has external linkage ----hoge.c---- #include "hoge.h" void hogefunc(double d) { ... } // This definition also has external linkage 以下のような小細工コードをいまだに見るけど、現代 C/C++ であれば不要 #ifdef HOGE_DEFINITION #define EXTERN #else #define EXTERN extern #endif

「C言語ポインタ完全制覇」を読ませてもらっております。 その本の本筋とは外れるのかしれませんが、第５章のヘッダファイルの作成と関連 してexternでわからない点がいくつかあるので質問させてください。 ご回答いただけると幸いです。 とりあえず、ひとつお聞きします。 分割コンパイルなどで、外部で定義している変数を参照するにはexternを使う、と よく本に書いてあると思いますが、外部の関数を参照するにはexternを 付ける必要がないように見受けられるのです。これはなぜなんでしょうか。

ちょいちさん、はじめまして。 >fgets(buf, 1024, stdin) >と書いていたのを、なぜ急に >fget(buf, 1024, fp) >と変えたのですか？？ もちろんこれはトルさんから回答があったように入力元を変えるためなのですが、 「なぜこのプログラムから?」というのが疑問であるわけですよね。 確かに説明不足だったかもしれません。 理由は、ここで作っている関数input_string()は、汎用の関数を目指している ためです。 このinput_string()は、扱える行の最大長に制限があるとはいえおおむね現実的な 入力においては、長さチェックを行って長すぎる場合にはエラーまで出してくれる、 という便利な関数です。実際、蔵書管理プログラムの中でもあちこちで使われて いますし、今後別のプログラムで使うこともあるかもしれません。 今後別のプログラムで使うことがあるのなら、入力元をstdinに限定して しまったのでは汎用性が薄れます。そこで、input_string()に引数として 入力元を渡せるようにしているわけです。 これで回答になっていますでしょうか?

はじめまして。私は『C言語 体当たり学習徹底入門』はもってないんですが･･･ちょっとだけ。 fgetsの第三引数の型はFILE *で、入力先を指定します。 stdinは標準入力と結びついていますので、stdinを渡せば標準入力から入力します。 fpの方は、どこぞのファイルに結びついていますので、fpを渡せばそのファイルから入力します。 要するに、stdinをfpに変えたのは、読み込み先を変えたという事です。

すいません。 自分の文章が自分でも理解できなかったので 何が分からないかを言い直しますｗ えぇと、「FILE *fpを引数に渡しているのはなぜか」というよりも、 fgets(buf, 1024, stdin) と書いていたのを、なぜ急に fget(buf, 1024, fp) と変えたのですか？？ ってことがわからないってことです・・・。 すんません。

はじめまして。ちょいちというＣ言語初心者です。 C言語体当たり学習徹底入門で勉強しています。 お世話になってます。 で、早速質問を・・・。 既出でしたら大変申し訳ないのですが、 p225のlist5-6やp227のlist5-8において、関数の引数に 『FILE *fp』があるのはなぜですか？ よろしくお願いします。

>お父さんには今夜じゅうにでも謝っておこうかと思います。 それはよかった… ですが。 >後、気になることがあるのですが、以前、掲示板を覗かせてもらったときに、 >前橋さんが僕に対して「前言撤回。こういう馬鹿は一度死ななきゃわからないのかも >しれない。」とおっしゃっていたのを記憶しております。 a) まず、私はそのような発言をした覚えはありません。念のため「前言撤回」や 　「馬鹿」でkmaebashi.comをGoogleサイト内検索してみましたがみつかりません。 b) それ以前の問題として、そもそも吉田さんは、この掲示板に書き込んだのは 　2007年8月1日の[1008]が最初ではないのですか? 「初めまして」と書いてあるし。 　ほんの1～2日前にこの掲示板に登場した人に、過去罵声を浴びせることが 　できるはずがありません。 c) 仮に、吉田さんがかつては別のハンドルネームでうちの掲示板に書き込んでいて 　私から何らかの罵声を浴びせられたとして、だったらその過去のハンドルネームなりを 　教えてもらわなければ、私には、何の話だかわかるはずもありません。　 >これは何に対する憤怒なのでしょうか。 >僕はずっとbrainfuckインタプリタを自分の物として父親に発表されたことによる >憤怒かと思っておりました。 d) 「brainfuckインタプリタを自分の物として父親に発表された」ということを 　吉田さんがこの掲示板に報告したのは、これもつい1～2日前の[1008]の投稿です。 　吉田さんがお父さんに何を発表しようと、その内容を私が知ることは不可能です。 　よって、それによって私が憤怒するなどということがあるはずもありません。 a)だけなら、別の掲示板と勘違いしてたとか、前橋の方が過去に罵声を浴びせた ことを忘れてる、ということもあり得るでしょうが、b), c), d)は、そういうことでは 説明がつきません。 煽りでもなんでもなく思うのですが、吉田さん、統合失調かなにかのケがありませんか。 もちろん私のような素人が勝手に診断を下してよいはずはないわけで、だからこそ、 (現在未受診であれば)精神科の診察を受けられたほうがよいのではないでしょうか。

前橋さん、ご返信ありがとうございます。 brainfuckインタプリタの件に関して前橋さんが「問題ない」とおっしゃってくれてホッとしております（NYSLの簡単な概要に関しては理解しました)。 お父さんには今夜じゅうにでも謝っておこうかと思います。 後、気になることがあるのですが、以前、掲示板を覗かせてもらったときに、前橋さんが僕に対して「前言撤回。こういう馬鹿は一度死ななきゃわからないのかもしれない。」とおっしゃっていたのを記憶しております。これは何に対する憤怒なのでしょうか。僕はずっとbrainfuckインタプリタを自分の物として父親に発表されたことによる憤怒かと思っておりました。もし、違う理由があるのであれば、その理由を教えていただけないでしょうか。よろしくお願いいたします。

>僕が前橋和弥さんの作った宝であるbrainfuckインタプリタをさも自分が >作ったかのように自分の父親に発表してしまったことです。これは >ソースファイルの盗用にあたるかと思います。 Brainfuck自体は、私が考えた言語ではないですし、実装もそこかしこに 転がっていますがそれはさておき。 BF-BASIC'nのソースについて言えば、ライセンスはNYSLであり、これは http://www.kmonos.net/nysl/ | ご自分の作ったものを扱うのと同じように、自由に利用することが出来ます。 と明記してあるとおり、BF-BASIC'nのソースを「さも自分が作ったかのように」 扱うことはまったく問題がありません。 よって、私からすればまったく問題ないわけですが、吉田さんが謝罪すべき 相手はお父様の方ではないでしょうか。嘘をついたわけですから。

初めまして。吉田祥彰という者です。今回は前橋和弥さんへ謝罪いたしたく投稿させていただきました。謝りたい件というのは、僕が前橋和弥さんの作った宝であるbrainfuckインタプリタをさも自分が作ったかのように自分の父親に発表してしまったことです。これはソースファイルの盗用にあたるかと思います。ここで前橋さんにお願いがあります。どうか前橋さんの寛大な心で、僕の愚行を許していただけないでしょうか？今後、このようなことはしないように最大限の注意を払って努力していくつもりです。どうかよろしくお願いいたします。

>BF-BASIC…前フリで「逆にいま BASIC 回帰もありなんだな」とか妙に納得しちゃったんですがすぽぽーんでコーヒー吹きました どうもです。ウケたようで何よりです。 いまさらですが、BF-BASIC'nは日付を見ればわかるように2006年のエイプリルフールに書いたものです。 ところで、前フリ部分は、私にとってはあれはあれで一面の本音ではあります(ぼそっ)。

BF-BASIC…前フリで「逆にいま BASIC 回帰もありなんだな」とか妙に納得しちゃったんですがすぽぽーんでコーヒー吹きましたBF で気づくべきだったのだな

>>コードが美しく、短く、分かりやすいです。 > >うーん、ざっと見ただけですが、なんか効率悪いパーサのような… > 許容範囲のコードかなぁー

>つんつんが時々 訪れている「紫藤さんのページ」のPython関数電卓です。 >http://www.shido.info/py/python_calc.html 情報ありがとうございます。 「Perl, Python, Rubyの比較」 http://www.shido.info/py/python1.html は以前に読んだことがあるのですが、その方のページだったんですね。 >コードが美しく、短く、分かりやすいです。 うーん、ざっと見ただけですが、なんか効率悪いパーサのような…

つんつんが時々 訪れている「紫藤さんのページ」のPython関数電卓です。 http://www.shido.info/py/python_calc.html コードが美しく、短く、分かりやすいです。 （つんつんの関数電卓は、引退しました。） 「紫藤さんのページ」には、scheme の関数電卓もあります。 http://www.shido.info/lisp/scheme_calc.html

>>あ、それすごく面白そうです。何度か書いてますが、私自身車輪の再発明が趣味ですし。 > >私も全く同様なのですが、どうも肩身が狭いですね。 >サイトが稼動し始めたらお知らせします。 や、よろしくお願いします。 エディタとかメーラとか、普段使っているツールは、プログラマにとってもっとも自作 したくなる道具であるはずで、だったらプログラミング言語は最優先のはずではないか、 とも思うのですが。 前提からして間違っているのかなあ… # かくいう私自身、クライアントアプリとしてのメーラを書いたことはないですが # (Webメーラなら書いたことある) >解説とか研修を行なうときは「無駄を省いた自作コース」を提供するのが強力であることが多いと思います。 その意味で、以前書いたように「本当の基礎からのWebアプリケーション入門―― Webサーバを作ってみよう」というのを考えてはいるのですが、Diksamができるまでは お預けです。ていうか私自身読みたいネタなので、誰か書いてくれないかしらん。

>>「車輪の再発明工場(仮称)」なんていうサイトを立ち上げようとしている私としては、 > >あ、それすごく面白そうです。何度か書いてますが、私自身車輪の再発明が趣味ですし。 私も全く同様なのですが、どうも肩身が狭いですね。 サイトが稼動し始めたらお知らせします。 > 言語処理系だけでなく、普段使っている何かを自作するというのは、それを理解する > 一番の方法でもありますし(時間はかかるので効率は悪いですが…)。 そうですよね。何にもない状態から発明した人よりははるかに短時間で作れるわけですから、 解説とか研修を行なうときは「無駄を省いた自作コース」を提供するのが強力であることが多いと思います。 # 「何でも自作してみないと本当に分かった気がしないのは、損なのか得なのか？？」と悩んじゃうことはありますが(^^;)

>「車輪の再発明工場(仮称)」なんていうサイトを立ち上げようとしている私としては、 あ、それすごく面白そうです。何度か書いてますが、私自身車輪の再発明が趣味ですし。 言語処理系だけでなく、普段使っている何かを自作するというのは、それを理解する 一番の方法でもありますし(時間はかかるので効率は悪いですが…)。 >素朴な疑問なんですが、(ぱ)さん自身はCrowbarやDiksamを普段どれくらい使われているのでしょうか？ これはもう正直なところを言ってしまうと、ほぼまったく使っていません。 Diksamなんか現状でprint()しか組み込み関数がないので実用になりませんし、 crowbarならAWK程度の役には立ちそうですが、そもそもAWKとかPerlとかRubyとかの 言語でさくっとテキスト処理、という機会も、今の私にはあまりないですし。

久々にお邪魔します。 >まあ、あの文章が面白いのだとすればそれは別に私の手柄ではなく、 >「プログラミング言語を作る」という行為自体が非常に面白いためなんだろうと >思いますが。 ># でも、同意してくれる人はあまり多くない気がします。残念ながら。 「(ぱ)さんの手柄ではない」という点は同意しませんが、 「言語を作るという行為自体が面白い」という点は同意します(そんなに少数なんですかね？)。 「車輪の再発明工場(仮称)」なんていうサイトを立ち上げようとしている私としては、 「面白そうだからやってみる。それだけ」というノリに共感を覚えてしまうんですが(^^;) 素朴な疑問なんですが、(ぱ)さん自身はCrowbarやDiksamを普段どれくらい使われているのでしょうか？

はじめまして。おほめいただきありがとうございます。 まあ、あの文章が面白いのだとすればそれは別に私の手柄ではなく、 「プログラミング言語を作る」という行為自体が非常に面白いためなんだろうと 思いますが。 # でも、同意してくれる人はあまり多くない気がします。残念ながら。 >「プログラミング言語を作る」を体裁を整えて本にしてください。 >５０００円未満なら買います。 えー、どうなるかはわかりませんが、精進いたします。