K.Maebashi's BBS

tasaedaです。ご返信ありがとうございます。 >正直、私としてはあまりこういう質問が来ることは想定していなかったのですが、 私もちょっと筋違いかなとは思ったのですが、引用については様々な本や記事で話題に なっていますし、少しでも自信がなければ（私自身経験不足ですから）しっかり確認を とっておいた方が良いだろうと思いまして。 >ということで、数ページ程度の引用でしたらまったく問題ありません。 なるほど、承知しました。一つの基準として覚えておきます。もっとも数ページも引用 してしまっては、私程度の筆力では間違いなく「主従の関係」が逆転してしまいそうです。 >もし必要でしたら、該当部分の電子ファイルをお送りしますが、どうしましょうか? それは大変助かります。本の文章をネットで掲載するには、自分でキーボードを叩か ねばなりませんしね。（私は遅筆なものですから） ではご厚意に甘えてメールを出させていただきますので、いつでも結構ですからご返信 いただければ幸甚です。 過分なご配慮、ありがとうございました。

>前橋様、皆様、初めまして。tasaedaと申します。 はじめまして。 >そういうわけですので、差し支えなければ前橋さんからの引用に関しての注意点や >不都合とお考えになることについて、お教えいただけたらと存じます。 状況は了解いたしました。 正直、私としてはあまりこういう質問が来ることは想定していなかったのですが、 私自身の都合からすれば、その引用を読んで「もう本は買わなくてもいいや」と 思う人さえ出て来なければ差し支えないわけです(おそらく出版社さんとしても)。 具体的には「1章まるごと」とかの転載をされなければ問題ないと思います。 1ページ程度であれば全然問題ないです。 また、引用部分を読んで、「こんなクソ本買うのやめた」と思う人がいたとしても、 それは仕方がないと思います(立ち読みでも発生し得る話ですし)。 本来、この本を読んでメリットを受ける人が(仮にいるとして)、その引用部分を読んで、 目的を達成してしまうと、私としては(経済的に)嬉しくないわけですけど、 1ページやそこらはもともと立ち読みできる範囲内ですから。 ということで、数ページ程度の引用でしたらまったく問題ありません。 引用した上でボロクソにけなそうがかまいません(再反論はするかもしれませんけどね) ので、ご自由にしてください。 もし必要でしたら、該当部分の電子ファイルをお送りしますが、どうしましょうか? もっとも私の手元にあるのは編集さんの手が入る前の、著者校正もしていないものだけ ですから、漢字の使い方が違っていたり誤植があったりしますけれど。 必要でしたら、そう言っていただければ、1/10中にはメールで送れると思います。

前橋様、皆様、初めまして。tasaedaと申します。 プログラミングに関する話題ではないのですが、掲題に関する質問がございますので 投稿させていただきます。 私のホームページでは雑文のようなものを書いているのですが、近日中の日記に前橋 さんの「センス・オブ・プログラミング」から一部を引用させていただこうと考えて おります。 具体的には、今のところP.10の24行目からP.11の15行目くらいまでを想定しています。 ただ読み始めて間がないので、他に感銘を受けた箇所を見つけた時は、もう少し増える かもしれません。 引用の理由ですが、プログラミングに関することでは全くございません。最近「抽象」 についての駄文を書いているとき、偶然手元にある貴著を拝読し、「これは自分の 考えにピッタリだ！」と思いましたので、早速日記に書こうと思いました。 ただ、引用部分が少々長くなりそう（あるいは増えそう）だな、と感じましたので、 これは前もって著者様に確認しておいた方がよいと判断し、この度お伺いを立てた 次第です。 そういうわけですので、差し支えなければ前橋さんからの引用に関しての注意点や 不都合とお考えになることについて、お教えいただけたらと存じます。 無論、文化庁の言う「引用における注意事項」は当然守りますが、それ以外に留意 して欲しいことがございましたら、ということです。 以上、宜しくお願いいたします。 追記：前橋さんの本には「C言語 ポインタ完全制覇」以降全てお世話になっており ます。もう何年もたちますが「最後は本人次第だなぁ」と痛感しております（苦笑）

ISO C99はすっかり頭から抜け落ちていたので、今調べなおしました (^^; >int32_t を生で使うのがアレなのは賛成ですが、 >typedef int32_t CustomerID; のようにして >int ではなく CustomerID を使うってのは OK >なんですよね？ 私の主張は「低レベルな概念をわざわざアプリケーションにばらなくな」 ということなので、CustomerIDを使うのであれば問題ないと思います。 ただ、ISO C99を前提にするのなら、CustomerIDなら、int_least32_tの 方が移植性が高そうには思います。 が、「どの環境でも同じようにバグって欲しい」とか、 「バイトオーダーがある程度限定されてもよいから生データでやりとりしたい」 とかの状況も当然あるとは思います。移植性という点ではどちらもなんとも 中途半端だと思いますが、全面否定はできません。 >int32_t の定義されてない古い処理系上で、 >上の CustomerID のような typedef を行うために、 >アプリケーションで「typedef int int32_t;」するのも >OK なんですよね？ 上のような意図なので、これもOKですね。 いつもながら軽率な表現ですみません(ご指摘ありがとうございます(_o_)) 意図としてはそのあたりだとご理解くださいませ。

一応、念のため確認です。 int32_t を生で使うのがアレなのは賛成ですが、 typedef int32_t CustomerID; のようにして int ではなく CustomerID を使うってのは OK なんですよね？ あと、int32_t は既に C言語標準に含まれているので、 基本的にはアプリケーションで定義する必要はないわけ ですが、int32_t の定義されてない古い処理系上で、 上の CustomerID のような typedef を行うために、 アプリケーションで「typedef int int32_t;」するのも OK なんですよね？

>> 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 >> 色々な環境からハードウエアを直に叩く様なアプリケーションを >> 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 >もちろんそういう低レベルな階層を意識しなければならないケースでは、 >ビット数を意識する必要があると思います。それでもできるだけ階層化して、 >下の方に押し込めたいところですが。 私の感覚が特殊な状況にあったようですね。 私の作るアプリケーションが いわゆるICデバイスを生で扱うためのもので、 最上位...つまりユーザインターフェイスにまでビット数やら 各ビットの01情報が見えないといけないという「超特殊」なモノ... 私が特殊な環境のプログラムばかり作っているってことを忘れてました(^^;) しかも、私の環境がWindows⇔UNIXという移植性は(あまり)考える必要がないので バイトオーダと言うことも考えから抜け落ちてました。 そうですねぇ。一般の例えばワープロとかで、使うintが何bitか なんて概念が残ってる必要はないですよねぇ。

件名を変えました。 >># そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション >># プログラムとしては、方向性が間違ってると思う。 … > 一般のアプリではビット数なんか気にしないで作らんとあかんって言うことでしょうか? まあ、簡単に言ってしまえばそういうことです。 > でも、ファイルフォーマットとかでやっぱりビット数って重要になりそうですが。 ファイルにデータを吐き出したいのなら結局バイト列まで面倒を見なければ いけないでしょう。int32_tを、32bitだからってそのままファイルに吐いてたら、 バイトオーダーの問題さえ解決できません。まあ、バイトオーダー(とか負の数の 表現方法とか)が同じ環境に限り移植性が高い、というだけでもメリットは もちろんあるので、全面的に否定はしませんが。 コンピュータの世界では、実に色々な概念が階層的に構成されていて、 ハードに近い「低レベルな」概念を、より抽象的な概念で隠す、という層の 積み重ねになっています。が、typedef int int32_t; は、より低レベルな階層を 剥き出しにする方向の定義になっている。これじゃあ向きが反対です。 その意味で、私は、Javaな人が、「Javaでは、Cなんかと違い、intとかの データ型のサイズがきちんと規定されているから良い」という主張が理解できません。 「intは最低限いくつからいくつまでの数を表現できる」という規定があれば (本来は)十分じゃないでしょうか。実際、Cの規格ではそれは保証していますし。 # intが3万ちょっとであふれるのは嫌だ、ということなら、「俺のプログラムは # intが32ビット以上の環境だけを対象とする」と言ってもよいでしょう。 2147483647に1足すと-2147483648になる、なんてことを仕様で保証しても、 「どの環境でも同じようにバグる」ことが保証できるだけでしょう。 現実問題としては「どの環境でも同じようにバグる」と助かるのは確かですが、 そういう意味で利便を図るなら、実行時エラーにする(できる)ほうが 筋が通ってますよね(C#のように)。 > 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 > 色々な環境からハードウエアを直に叩く様なアプリケーションを > 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 もちろんそういう低レベルな階層を意識しなければならないケースでは、 ビット数を意識する必要があると思います。それでもできるだけ階層化して、 下の方に押し込めたいところですが。

あけまして おめでとうございます。 少し趣旨の異なる質問ですが ># そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション ># プログラムとしては、方向性が間違ってると思う。 この方向性が間違っていると言うのは, どういうことを意味してるのでしょう? int32_tみたいな型を利用するのは、けっこう便利だと思うのですが。 一般のアプリではビット数なんか気にしないで作らんとあかんって言うことでしょうか? でも、ファイルフォーマットとかでやっぱりビット数って重要になりそうですが。 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 色々な環境からハードウエアを直に叩く様なアプリケーションを 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 >>ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 >これは私も知りたいです。詳しい方、よろしくお願いいたします。 Javaはよくわかりませんが、私はX関係とかで一般に公開されている かなり熟練されている人たちが作ったと思われるプログラムの ディレクトリ構造とかを真似してみたりしてます。 まぁ、新規に作り始めることが少ないので、 既にある環境で何も考えずに やってることがほとんどですが。 なんつうか、頭を使わない私なのでした。

>皆様初めまして、ＨＮ「けろ助」と申します。 はじめまして。 >ビルドを効率的、柔軟に行えるようにするには、makefile (make)、build.xml (ant) の記述ノウハウはもちろ >んのこと、ディレクトリ構成等も慎重に考えて設計しなくてはならないように思います。 いやあ、このあたりは、最近はかなり「若い奴にお任せ」してる部分が大きいので、 私がこの方面に詳しいかというとそんなことはないと思います (^^; 詳しくないなりに思うところを書きますが、こういうのはアプリケーションと 環境により千差万別なわけですが、実はプログラマが仕事で書くプログラムの 95%は特定顧客からの受注アプリケーションだという現実があって(※1)、 その場合、特に相手がUNIXワークステーションだったりすると環境はかなり 限定できますから、「ディレクトリまるごとtarで固めてインストール先で展開。 パスは全て絶対指定」みたいなやり方でもなんとかなっちゃう、という面はあると 思います。 Windows環境ではさすがにそういうのは避けるべきかと思いますが(PCはきっと 他のことにも使うので)、業務用の特注アプリケーションだと、Cドライブにしか インストールできなくてもさほど問題にはならなかったりします。 一般に配布するのでどこでも動くようにしたい、と考え出すと、途端に難しく なりますよね。Cの場合、かつては#ifdef __SOLARIS__ とか書いてましたが これはひどいということでautoconfみたいなのが出てきましたけどconfig.hに 頼ってたらテストが大変(というか不可能)という状況には変わりなく、 結局は、(Javaが本質的にそうであるように)最初からどこでも動くように書くのが 正しいのでしょう。 # そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション # プログラムとしては、方向性が間違ってると思う。 Javaではそういうところは改善されているはずが、Webアプリ構築のために アプリケーションサーバを導入すると移植性なんかどっか行っちゃったりしますし、 JDKのバージョンに泣かされることもあります。 「Tigerはいつになったら仕事で使えるんだろう?」 「あと数年は無理じゃないですかねえ」 という会話を、まさに今日、同僚としてました。 >ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 これは私も知りたいです。詳しい方、よろしくお願いいたします。 ※1「魔法のおなべ」より http://cruel.org/freeware/magicpot.html

皆様初めまして、ＨＮ「けろ助」と申します。 職業プログラマ歴３年と９ヶ月のまだまだへっぽこです。 前橋さんのファン歴（？）は「Java 謎＋落とし穴」発刊以来ですから丸３年くらいでしょうか。 で、いきなりですが質問なのです。 本格的なアプリケーションを作る場合、「ソースを書いてコンパイルする」だけではなく、「リリース用のファ イルセット (実行モジュールや設定ファイル等の集合) を作成する」という作業も必要になってくると思います。 そして世間一般ではこの作業を「ビルド」と言い習わしているようです (正確な定義は良く認識できていません。 コンパイル～リリース用ファイルセット作成までの、一連の作業を「ビルド」と言っている場合もあれば、個別 の作業行為を「ビルド」と言っている場合もあるからです)。 ビルドを効率的、柔軟に行えるようにするには、makefile (make)、build.xml (ant) の記述ノウハウはもちろ んのこと、ディレクトリ構成等も慎重に考えて設計しなくてはならないように思います。 プログラマにとってデータ構造やアルゴリズムと同程度に重要な話題に思えるのですが、参考になる書籍やサイ トが見つからずに困っております。 ビルドツールの使い方そのものについては充分な情報が得られるのですが…。 ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 特に Java＋ant に向いた情報を必要としています。 「自分は大抵こんな構成で作ってる」「このオープンソースの設計が参考になる」「そんなものはプログラマの 基本教養じゃ。この青二才め」等、何でも構いません。 よろしくお願いします。 個人的には、前橋さんに「本格的なアプリケーションの構築技法」の本を出していただきたいな…と思っていた りするのですが。

Perlに詳しいわけではありませんが、故あって最近Perlのソースを眺めたりも してるので、ちょっと調べてみました。 >perlの場合、関数の引数は全て配列(@_)として扱われます。なので、この場合は、 >一つ目の%sには$_[0]が、二つ目の%sには$_[1]が、三つ目の%sには$_[2]が入ります。 Perlで記述された関数についてはその通りでしょうが、今回のケースのsprintfは Perl組み込みの関数ですから、Cで書かれた実装部分に引数の数が渡っているかどうかが 問題では? で、5.8.6のソースから探したところ、どうもsv.cのPerl_sv_vcatpvfnが sprintfの実装のように見えます(1000行近い巨大関数。sprintfじゃあ しょうがないですが)。 void Perl_sv_vcatpvfn(pTHX_ SV *sv, const char *pat, STRLEN patlen, va_list *args, SV **svargs, I32 svmax, bool *maybe_tainted) doop.cのPerl_do_printf()から追跡すると、このsvmaxが、引数の数のように見えます。 printfかましてminiperlを再構築し、確認しましたが、実際に引数の数が渡って きているようです。 が、この関数の中でsvmaxをどう使っているか見てみると、 if (svix < svmax) { というように「svmaxを超えてないか?」というチェックは何箇所かでしてますが、 上記の箇所でもelse節はなかったりするので、そのために何も起きないんじゃ ないでしょうか。

あけましておめでとうございます。今年もよろしくお願いいたします。 しばらくごぶさたしてましてすみません。 この年末は、風邪ひいて寝込むわ、紅茶ひっくり返して太ももをやけどするわで、 ただでさえ短い正月休みの前半は寝ている間に終わってしまいました。 Webページの更新を含め、やりたいことはいろいろあったはずなので、 3が日の間にぼちぼち進めるつもりです　　　…無理かも。断酒も明けたし。 なお、正月バージョンの壁紙は、 「へなちょこ愚連隊」 http://www6.wind.ne.jp/hena/index.html からお借りしました。

>Perlのようなインタプリタ型の言語は、なぜエラーにならないのでしょうか？ インタプリタだから、ではなくて、perlの言語仕様的な問題です。 perlの場合、関数の引数は全て配列(@_)として扱われます。なので、この場合は、 一つ目の%sには$_[0]が、二つ目の%sには$_[1]が、三つ目の%sには$_[2]が入ります。 このとき、Cあたりだと配列長を超えたらそのままバッファオーバーラン、Javaだと 例外が投げられますが、perlの場合は読むときはundefが返り、書くときは自動で 配列長が拡大されます。 今回の場合は、$_[2]を読もうとして返ってきたundefが文字列化されて空文字列 扱いになったわけです。

>>externで「外部にあるよ！」と宣言してるにも関わらず、 >「プログラマの意図」はそうなのかもしれませんが、言語規格書の主張は違います。 >3.5-6 で、こういう宣言を行うと hoge() は内部結合のままだと書かれています。 ふむふむ。C++だとそう記述があるのですね。 ありがとうございます。

御指摘ありがとうございます。 >sprintf は「可変個引数」な関数です。 >固定な引数＝必ず必要な引数、が無いとエラーになりますが、 >可変個数部分＝有るか無いかは状況次第、が過不足していてもエラー検出することはできません。 >原理的に不可能。 申し訳ありません。すっかり忘れていました。 （前橋さんの本などで、話題になっていたのに・・・） printf系の関数は実引数が不足しているときの動作は未定義でしたね。 >C/C++ では上記コードのエラー検出はされません。 確認せずに記述してしまいました。（VC++でも検出しませんでした） 大変お騒がせ致しました。 （件名のインタプリタとコンパイラとは一切関係ありませんでした (;_;) ）

>my $string = sprintf("%s %s %s\n", $day, $message); perl はぜんぜん知りませんが、この sprintf が C の sprintf と同じ機能と仮定して： C/C++ では上記コードのエラー検出はされません。 sprintf は「可変個引数」な関数です。 固定な引数＝必ず必要な引数、が無いとエラーになりますが、 可変個数部分＝有るか無いかは状況次第、が過不足していてもエラー検出することはできません。 原理的に不可能。 # GNU CC では printf 系関数のフォーマット引数が文字列リテラルな場合に限り、 # 個数や形の不一致を検出してくれますが、一般的には無理。

とりあえず以下 C++ の話に限定 (ISO/IEC 14882:1998) 。 # C 規格書はウチに帰r) >externで「外部にあるよ！」と宣言してるにも関わらず、 「プログラマの意図」はそうなのかもしれませんが、言語規格書の主張は違います。 3.5-6 で、こういう宣言を行うと hoge() は内部結合のままだと書かれています。

いつも楽しく拝見しています。 久しぶりに投稿します。konです。 質問なんですが、 共通機能でログを作成する機能をPerlで作成する事になりました。 その際、ログファイルに情報を1行ずつ書くのですが 必ず最後にスペースが入って改行される現象がありました。 原因は my $string = sprintf("%s %s %s\n", $day, $message); 上記のコードで、2番目の%sの後のスペースが表示されて、3番目の%sが引数のエラー にならない事が分かりました。 Ｃなどのコンパイラ型の言語なら、コンパイルエラーになりますが Perlのようなインタプリタ型の言語は、なぜエラーにならないのでしょうか？ （strictはいれてますが、ワーニングにもなりません） Perlのマスターが言うには、”Perlはアバウトだからね”と意味不明（論理的でない？） 回答が返ってきました。私も、あまりPerlをやっていないのでとても 気持ちが悪いです。

>は、「コンパイラさん、宣言はブロックスコープを越えないで…」というような、私の嘆きの意味合いです。 なるほど、そうでしたか。 私は「ブロックスコープを超えるのはなんで？」と読めたのでその理由を書き足したのです(^-^;) # とりあえず解決！？

>まぁ、コンパイラがリンク処理を行う段階でexternなんていう情報は >すっかり消えうせて関数名だけ残ってしまう。 >しかも、名前の一致する呼び出し元と実体をリンク処理しちゃう。 ここ、私の解釈が間違ってましたね・・・ 本多さんの意図はexternで「外部にあるよ！」と宣言してるにも関わらず、 同一ファイル内に同じ名前があると「外部」を見に行かなくなるってことですね。 # ブロックスコープの「外にある」という風に解釈するのが自然！？

クリスマスバージョン(柄にもなく)ということで背景をいじってみました。 イブの晩が終わったら戻そうと思います。 少し前、板ごとにCSSをいじれるようスクリプトを修正しました。 なので、以前作ったテスト掲示板↓では、古いCSSがそのまま適用されています。 http://kmaebashi.com/bbs/list.php?boardid=testbbs 板ごとに多少の紹介文をページ上部に入れられるような修正もしたのですが、 とりあえず今は時間がないので 今回の素材は以下のページからお借りしました。 http://kisetu.chu.jp/navi_fuyu_xmas.html ところで、クリスマスといえば、最近久々にアクセス記録なぞ見たのですが、 「赤鼻のトナカイ」「赤鼻のトナカイ 歌詞」という検索キーワードで この雑記↓に到達した人が最近結構いらっしゃるようです。さすがはクリスマス。 http://kmaebashi.com/zakki/zakki0009.html#xmas きっとお役には立てなかったと思います。すみませんねえ。

自己レスです。 >>a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 >なのに、既存の宣言(hoge1の関数ブロック内の宣言)との整合性がチェックされているとは…。 は、「コンパイラさん、宣言はブロックスコープを越えないで…」というような、私の嘆きの意味合いです。

れぷさんへ。 > a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 > b)hoge2()の中のpiyoの呼び出しで、宣言がないので暗黙にintを返す関数として >　宣言されて、 > c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは >　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 なので、 「a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、」なのですが、 最終的には、 「c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは 　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 」 となるので、前者の文章は「完結していて」が「完結していない」という結論になります。 (チェックされていればhoge1で完結している事にはなりませんので、(ぱ)さんは完結していないと仰りたかったんだと私は解釈しております。間違ってたらごめんなさい。) という訳で(私の解釈が正しければ)、bcc32では774RRさんが仰っている > と思います。C++ と違い C の場合、K&R1 の頃の（いわゆる non-ansi C) との後方互換性を > 保つため、規格書に書かれていない（もしくは規格書が禁じている）後方互換のための機能が > いくつも有効になっている処理系がほとんどのようです。 となります。 という訳でして、hoge1()のextern宣言時では「外部関数はグローバルにあると想定するしかない」ですよね。 で、宣言が完結していていない(コンパイラが余計(?)なことをしてくれるため)ため、「外部関数はグローバルにあると想定するしかない」がhoge2にも摘要されるので、れぷさんの仰る通り、 > なので「外部関数はグローバルにあると想定するしかない」→「だから整合チェックがかかるのでは？」と思ったわけです。 となります。 一応念の為に書いておきます。

>　と仰っているので、C++の名前空間的な機能が無い限り衝突はされられないので、それはできないとい >う結論になると思います(少なくても私の知っている限りでは)。 そうなりますね。 実は私が反応したのはお二方の文、 　　>>a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 　　>なのに、既存の宣言(hoge1の関数ブロック内の宣言)との整合性がチェックされているとは…。 だったりします。 なので「外部関数はグローバルにあると想定するしかない」→「だから整合チェックがかかるのでは？」と思ったわけです。 ちなみにstaticを使ってしまうと、最初のソースの記述では hoge1()もhoge2()もstaticのほうを呼び出してしまうので、 元のソースとは構成を変える必要が出てしまいますね(^-^;)

> 例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 　仰っている意味が分かりました。 　ローカルextern用のpiyo()は、a.cのローカルextern用の関数定義って事だったんですね。 > 例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 > グローバルextern用のpiyo()を定義したものをc.cしたとして、 > どちらのpiyo()をローカルへリンクして、もう一方をグローバルでリンクすれば良いのか、 > コンパイラこれを判断するにはどうすることが良いのでしょうか？ > b.c、c.cの関数定義はいずれにせよグローバルにおかれるでしょうし、 > コンパイラもそれを想定していると考えるなら衝突することになるのかな、なんて思いました。 >　名前空間があれば解決できるのでしょうが、Cは空間分けがザックリすぎて(^-^;) > それができないですよね。 　774RRさんも、 > C の場合は名前空間わけがざっくりすぎるし、オーバーロードは無いので、 > 結局同一名称の関数は１つしか存在し得ないわけです。では 　と仰っているので、C++の名前空間的な機能が無い限り衝突はされられないので、それはできないという結論になると思います(少なくても私の知っている限りでは)。 　ローカルのextern宣言の意味については774RRさんの仰っている通りです。 　一応念の為に書いておきますが、b.cのpiyoをa.cのhoge1専用の作業関数としたい場合にはstaticを付けて、翻訳単位を分けるという方法しかないと思います。

宣言した関数が宣言のあるブロック内でのみ有効と明示したいんでしょうね。 でも、C言語を使っていると型はコンパイル後に情報が残らないので、 同じ名前が二つ残ったら、リンクエラーになるんですね。 宣言を関数ブロックに入れるというのが、かなり異常な使い方だと思いますが。 実際、以下の様になってると宣言は何の効果も発揮しません。 ----test1.c---- #include <stdio.h> static int hoge(void) { printf("static int hoge()\n"); return 0; } int main(void) { extern int hoge(void); hoge(); return 0; } ----test2.c---- #include <stdio.h> int hoge(void) { printf("extern int hoge()\n"); return 0; } ---- % gcc -O2 -Wall test1.c test2.c % a.out static int hoge() まぁ、コンパイラがリンク処理を行う段階でexternなんていう情報は すっかり消えうせて関数名だけ残ってしまう。 しかも、名前の一致する呼び出し元と実体をリンク処理しちゃう。 だから処理内容を考えると当たり前の結果なんでしょうけど。 宣言で自分の結合先を選べるという意図があったとして、結果がこうなったら、 私の例はstaticを使ってるのでちょっと事情は異なりますが ちょっと残念に思うかもしれませんね。

C の場合は名前空間わけがざっくりすぎるし、オーバーロードは無いので、 結局同一名称の関数は１つしか存在し得ないわけです。では >int func1(void) { > extern int piyo(void); > return piyo(); >} の意図はというと、 「この extern を {} 外に出してしまうと同一翻訳単位中の他の関数から piyo() が正しく 　呼び出せてしまって警告にならない」 ことを防止することにあります。 piyo() は func1() 専用の作業関数であることを明示したい、と。 だから func2() からは piyo() を呼び出せない、ないしは、 呼び出そうとすると警告になってほしい、わけですね。 # C++ ではきっちりエラーになってくれる。 ではない？

九龍さん、はじめまして。 　3つに別けたのはa.cのコードが以下のような状況を想定しているように思えたからです。 ---a.c--- void hoge1(void) { extern void piyo(int a); // b.c内を想定 piyo(1); } void hoge2(void) { piyo(2); // c.cを想定 } 　なので、↓こういう状況を考えたわけです。 ---b.c--- // hoge1()ではAさんがくれたこっちを使おうと思った void piyo(int a) { return; } ---c.c--- // hoge2()ではBさんがくれたこっちを使おうと思った int piyo(int a) { return a; } 　この状態でb.c内にあるpiyo()をhoge1()ローカルだけに対して定義できるかというとできないですよね。 従って、hoge1()でローカルexternしたpiyo()はどこにあるのかというと、 コンパイラは「外部にある関数はグローバルに存在すると想定する」としかないのかな、と思います。 そうなると、 　　「hoge1()でローカルexternされてるpiyo()はグローバルにあるはず」 　　「hoge2()のpiyo()はプロトタイプ宣言ないけどこれも多分グローバルにあるはず」 になるので、a.cのコンパイル時に正しいpiyo()をリンクするための情報を作るには 「正しいpiyo()はどれですか？」と整合エラーを吐くしかないような気がしました。 　名前空間があれば解決できるのでしょうが、Cは空間分けがザックリすぎて(^-^;) それができないですよね。

れぷさん、はじめまして。 >例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 「ローカルextern用のpiyo()を定義したもの」とありますが、どのような意味なのか理解しかねております。 具体的にどういうソースかをお書き頂けると嬉しいのですが。

横レスすいません。 >c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは >　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 ローカルでexternするにしてもグローバルでexternするにしても、 piyo()は外部に定義あるわけですよね。 例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 グローバルextern用のpiyo()を定義したものをc.cしたとして、 どちらのpiyo()をローカルへリンクして、もう一方をグローバルでリンクすれば良いのか、 コンパイラこれを判断するにはどうすることが良いのでしょうか？ b.c、c.cの関数定義はいずれにせよグローバルにおかれるでしょうし、 コンパイラもそれを想定していると考えるなら衝突することになるのかな、なんて思いました。 あー、なんかまた外したこと言ってそう(;_;)