K.Maebashi's BBS

「C言語 体当たり学習徹底入門」正誤表に載っている「ほげを考えるページ」へのリンクがniftyのURLのままです。

こんにちは。 >MacOSX で電卓使いたいとコンパイルしたのですが、エラーになります。 … >cc -c -g lex.yy.c >calc.l:6:31: readline/readline.h: No such file or directory このエラーメッセージは、readline.hというファイルが見つからないと言っている わけですから、GNU readlineがインストールされていないのでしょう。 MacOSはよく知りませんが、デフォルトでは入ってなくても無理ない気がします。 実は入っていて、#includeのパスが通ってないだけかもしれませんが。 もし入っているのであれば、コンパイラの-Iオプションにそこを加えれば よいですし、入っていないのであれば拾ってきて入れることになります。 このページからダウンロードできるようです。 http://tiswww.case.edu/php/chet/readline/rltop.html インストールの方法はここにありました。 http://tiswww.case.edu/php/chet/readline/INSTALL GNUのソフトらしく、 ./configure make make install でインストールできるようです。 ただ、電卓を作るための勉強用なら、こちらの方が簡単でよいかと思います。 GNU readlineも使っていませんし。 http://kmaebashi.com/programmer/devlang/yacclex.html

その4 「電卓を作ってみよう」 MacOSX で電卓使いたいとコンパイルしたのですが、エラーになります。 前橋さまの電卓試したいのですが、ご教授よろしくお願いします。 $ tar zxvf mycalc.tgz $ cd mycalc $ cd memory/ $ make cc -c -g -Wall memory.c cc -c -g -Wall storage.c ld -r -o mem.o memory.o storage.o $ cd ../debug/ $ make cc -c -g -Wall -I../ debug.c ld -r -o dbg.o debug.o $ cd .. ーーーーーーーーーーーーーーーーここまでは、エラーでませんが $ make bison --yacc -dv calc.y flex calc.l cc -c -g lex.yy.c calc.l:6:31: readline/readline.h: No such file or directory calc.l: In function `tty_input': calc.l:87: warning: assignment makes pointer from integer without a cast make: *** [lex.yy.o] Error 1 $ ーーーーーーーーーーーーーーーーここで、エラーになりました。どうして？？？

>以前から告知されていましたが、niftyのメンバーズホームページはリンクのサービスも停止してしまいましたね。 ありがとうございます。まったく気付いていませんでした。変更しておきました。 ずいぶん長いこと転送してくれていましたから、まあ文句は言えませんね。

トップページ > kmaebashi.comに直接飛ぶように設定できるようになっていたことが判明。今はそのように設定しています。 以前から告知されていましたが、niftyのメンバーズホームページはリンクのサービスも停止してしまいましたね。 トップページの口上が現状と合致しなくなったので、(おせっかいながら)指摘しておきます。

もいちど駄レスしておくと オブジェクト指向な設計、というものはあっても 非オブジェクト指向な設計の元にオブジェクト指向なプログラム、ってのはありえない わけで、「基礎設計したことがないプログラマ」ではＯＯがわからなくて当然。 メタ度が違うっちぅことで。 俺も、基礎設計が気に入らなくなったという理由で、５０％くらい作ったプログラムを 全部捨てて最初から再設計したなんて経験が何度もある。 ただ「実装するだけ」のＯＯでは意味が無いと思うのココロ そーいう人に限って「スーパークラスがごみ置き場」になるわけだ。

>リスコフというと「え、ええと置換原則の人?」程度の私はまだまだ勉強が >必要のようです。 リスコフは「抽象データ型」とか「カプセル化」を考えた（言い出した）人です。 >新しいほうの3系統 >http://d.hatena.ne.jp/sumim/20080415/p1 > >は大変腑に落ちます。 それはよかった。ご紹介痛み入ります。

>新人はさしたる仕事もなく、昨日もオブジェクト指向のサイトを転々としておりました。 ああ、それはうらやましい。 戦力として配置されるとだんだん勉強の時間も削られてくるものですし、 さらに年を食うとろくにコードも書かせてもらえなくなるのがこの業界ですので。 >　継承：共通処理（親）をベースとして差分を子に付け加える。ライブラリを > includeするのと逆の発想。 うーん、これはまさに(最近評判があまりよろしくない)実装継承ですよね。 以前、この辺のスレッドで議論したことがあります。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&thread=270 この中で出ているoo-squareのリンクは、現在切れていますがこっちです。 http://www.ogis-ri.co.jp/otc/hiroba/oosquare-ml/Archive/200501.month/thread.html よく使うメソッドをスーパークラスに置いて、なんてことをやっていると、 http://www.ogis-ri.co.jp/otc/hiroba/oosquare-ml/Archive/200501.month/4468.html | 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」 | と化していることが多いようです。 なんてことになってしまう。それよりはむしろ、 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=276&range=1 | 「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」 のほうが実際の使いどころに合っていると思いますが、こうなるとインタフェースと 一緒になっちゃうんですよね。実際、「継承なんかどうでもよくてインタフェースこそが 本質なのだ」と言う人もいますし。 じゃあ継承なんかなくていいのかというとそうでもなくて、実際私も使うというのが ややこしいところ。「継承とインタフェースのどっちを使えばいいんですか?」というのは FAQですが、私はこれはもう単純に ・データメンバがメインの構造体的なクラスにフィールドを追加するなら継承を、 ・それ以外はインタフェース でいいんじゃないかな、と思っています。 >　隠蔽：見せたくない処理はlocal変数、local関数にて実装する。 これは実態としてまさにそうだと思います。 よく「その『オブジェクト』だけが知っていればよいことはprivateにするんだ」と オブジェクトごとに丸を描いたりして「カプセル化」としている説明がありますが、 言いたいことはよくわかるものの、C++でもJavaでも実はprivateは 「別のクラスから見えない」だけで「別のオブジェクトから見えない」のでは ないんですよね。 これを、単にC++(およびその派生言語)が腐っているとか実用上の妥協だとか 言うことも可能ですが、私はこれを「privateというのは他の『プログラマ』に 対する隠蔽なのだ」と考えてしまってよいと思っています。 >　多態性：引数に基づき、サブルーチン側でif～elseで処理分岐する。 > またはincludeを変える。 「またはincludeを変える」のほうは良くわかりませんが、1行目は、用途としては そのとおりです。よくある図形(Shape)の描画ルーチンの例のように、 ポリモルフィズムを使うことで、プログラムからswitch caseを排除できます。 Cにはそれがないばかりに巨大なswitch caseを書いてる例： http://kmaebashi.com/programmer/devlang/diksam_src_0_2/S/7.html#693 ポリモルフィズムにおいて、一見単なる実装詳細に見えるけど実は結構重要なのは、 サブクラスを追加しても、呼び出し素(switch caseに相当する部分)再コンパイルの 必要がない、ということですね。だからAppletを継承したクラスを作れば すぐにブラウザで実行できるわけで。 >　マルチプルインスタンス：サブルーチンをメインの実行状況によって任意に > （動的に）増やせる。 うーん、これはどうなんでしょう。オセロの例で言えば、Boardをいくつnewしても、 put()というルーチンは増えないと思うのですが… 「メソッドはインスタンスに付属している」というイメージからすると、 一緒に増えると考えることもできるのかもしれませんが。

こんにちは、sumimさん。(いろいろなところで)いつもお世話になってます。 >すみません（汗）。 いえそんな(大恐縮) >当時はまだリスコフの抽象データ型（カプセル化）について理解があさく、 >ユーザー定義型に手続きを含むか、含まないかで、それぞれを OOP（あるいは、 >手続きによる抽象化。PDA）とするか、ADT（クック独自定義の抽象データ型） >とするかという分類はとてもクールに思えて必要以上に持ち上げてしまいました。 リスコフというと「え、ええと置換原則の人?」程度の私はまだまだ勉強が 必要のようです。 新しいほうの3系統 http://d.hatena.ne.jp/sumim/20080415/p1 は大変腑に落ちます。

返信下さった皆さん、ありがとうございます。興味深く読ませて頂きました。 新人はさしたる仕事もなく、昨日もオブジェクト指向のサイトを転々としておりました。 やはり「猫」の例はヘンですよね。現実世界を模しているならば「鳴けとメッセージを送ると 鳴く」というよりは「腹が減ると鳴く」の方がピッタリでしょう。つまり完全自律型、プログラムで いったら暴走に近いかも・・・。 プログラミングは少々かじったことがあるのですが（学校の実習レベルです）、無理矢理 現実世界に例えるよりはこんな感じの説明の方がイメージに合っていると思います。 　継承：共通処理（親）をベースとして差分を子に付け加える。ライブラリをincludeするのと逆の発想。 　隠蔽：見せたくない処理はlocal変数、local関数にて実装する。 　多態性：引数に基づき、サブルーチン側でif～elseで処理分岐する。またはincludeを変える。 　マルチプルインスタンス：サブルーチンをメインの実行状況によって任意に（動的に）増やせる。 　オブジェクト指向：これら個々の処理を分離して薄皮でくるみ、モノとして捉える。 わかってないとお叱りを受けそうですが、「犬・猫」よりはそれっぽい（笑）気がします。

># 以前何度か読んで、そのたびに「手続きによる抽象化」について調べようと思いつつ ># 忘れていたらいつの間にか追記がついていた。あれ? すみません（汗）。 当時はまだリスコフの抽象データ型（カプセル化）について理解があさく、 ユーザー定義型に手続きを含むか、含まないかで、それぞれを OOP（あるいは、 手続きによる抽象化。PDA）とするか、ADT（クック独自定義の抽象データ型） とするかという分類はとてもクールに思えて必要以上に持ち上げてしまいました。 その後、リスコフは、手続きを型に含むか含まないかは抽象データ型の実現方法の バリエーションにすぎない（それぞれにメリット・デメリットがある…）と書いてある のを見つけて、追記にように認識を改めた次第です。

>オブジェクト指向のごちゃごちゃが気になったら、とりあえずこのページを見ておくと良いと思います。 >http://d.hatena.ne.jp/sumim/20040525/p1 ページの紹介ありがとうございます。 # 以前何度か読んで、そのたびに「手続きによる抽象化」について調べようと思いつつ # 忘れていたらいつの間にか追記がついていた。あれ? というわけで、Javaの勉強をするのなら、「メッセージ」という言葉を多用している 入門書はひとまず避けておけ、と(ぉぃ 逆に言えばうちのページ http://kmaebashi.com/programmer/object/index.html はC++/Java流OO限定ですね。そういうわけで当時の掲示板でのバトルの末 「言語としてはJavaを使用します。」という文言を先頭のページに持ってきた、 という経緯はあるんですが、もうちょっとでかでかと書いてもよかったかも。 まあ当時は依怙地になっていたかと思います。

>新人君 (大学では情報技術をやってなかった君) を見ていると >やはり[マルチプルインスタンス]にてつまづいているようだ。 >http://kmaebashi.com/programmer/object/othello.html この「マルチプルインスタンス」という言葉は別に私の造語ではなく、 http://kmaebashi.com/programmer/object/intro.html にも書いたようにC++ FAQにあった言葉を使ったのですが、上のページを私が書いた 時点では、「マルチプルインスタンス オブジェクト指向」でGoogleしても 0件でした。 それが今では258件だか出ます(私のページやそれに対する言及も多いですが)。 うちのページの影響だと思っても、自意識過剰じゃないですよね。きっと。たぶん。 プロトタイプベースまで含めるとまた話がややこしくなりますが、 クラスベースのOOに関する限り、複数のインスタンスが作れるという概念は 基本だと思うんですよね。あまりに基本すぎるせいか、入門書とかでは 飛ばされてしまっていたわけですが。 新人君がなにもかもstaticなプログラムを書いたら「オブジェクト指向的じゃない!」 と怒るくせに。 >マルチプルインスタンスが理解できても static という罠が待ち構えている。 しかもJavaの場合実行がすべてpublic static void main()から始まるために、 本当の入門者がいきなり罠にはまるという…

Gloryさん、こんにちは。 >例題は「車」・・・このサイトの予想通り。ご多分に漏れずなかなか >理解できずにいます。 車ですか…これもよく使われる例かと思いますが、やっぱりたとえ話はよくないと 思います。 >そのうえ更に「よくある○○という説明は間違い、誤解をうむ、 >オブジェクト指向ではない」などと説明されると、卓袱台を引っくり返された >ような感覚すら。 >結局どれが”正”なんだ？と。お互いに自分の説明こそが正しいという立場で主張する >わけですから（当たり前ですが）、初心者は余計に混乱し、根気がないと挫折します。 すみません、一部加担しています。(_o_) >オブジェクト指向に対する根本的なモノの考え方は同じなのかもしれませんが、 >投稿・掲示板でも意見が分かれるように、統一見解がないことこそが >”なぜわからなくなってしまうのか？”の一番の原因なのかもしれません。 [1111]でこくぼさんが挙げておられるページのように、また、 http://practical-scheme.net/trans/reesoo-j.html こちらでも「オブジェクト指向というものが動く標的であるため、オブジェクト指向の 熱心な支持者はこのメニューのうちの適当なサブセットを気まぐれに選んで、 それを以って他の言語はオブジェクト指向ではないと説得しようとする。 」 と言われているように、定義がちゃんと定まったものではないとは思います。 >本当は誰もが認めるバイブル的な教本があるとよいのですがねぇ・・・。 たとえばBertrand MeyerさんのOOSC(Object-Oriented Software Construction)は かなり多くの人がバイブルと認めると思いますが(少なくとも静的型OO支持者であれば)、 それでも「あの本の継承の使い方は…」という留保をつける人が多いんじゃないかと 思います。

昨晩はちょっと早めに帰宅して、 　　↓ 掲示板を確認し、ゴミ投稿を消して、 　　↓ どうお返事しようかなあ、と考えながらベッドにごろんと 　　↓ 気付いたら朝　←いまここ というわけで、今しばらくお待ちくださいませ。

オブジェクト指向のごちゃごちゃが気になったら、とりあえずこのページを見ておくと良いと思います。 http://d.hatena.ne.jp/sumim/20040525/p1

新人君 (大学では情報技術をやってなかった君) を見ていると やはり[マルチプルインスタンス]にてつまづいているようだ。 http://kmaebashi.com/programmer/object/othello.html 同じ種類のモノが、複数個！という概念が理解できた後でないと 同じ性質だけど、違う種類！ (基底クラス→派生クラス) の理解は危うい。 と思うのであった。 マルチプルインスタンスが理解できても static という罠が待ち構えている。 Java の Double クラスの public static Double valueOf(String s) が ああ、そういうことねーと納得できるかどうか こりゃいったいなにがいいたいんぢゃろと困るか その辺にわかるわからないの境目がありそうな気がする俺ちゃんであった

管理人さん＆読者の皆さん、こんにちは。 この前、会社の新人研修でオブジェクト指向（Java）を学びました。 例題は「車」・・・このサイトの予想通り。ご多分に漏れずなかなか理解できずにいます。 いろいろなオブジェクト指向関連のサイトや本を読みあさって勉強していると、筆者それぞれに 思い入れがあって、解説の仕方や考え方が異なることに気付きます。「実は簡単」とか「これだけ 覚えればOK」という内容をよく目にしますが、私のような初心者にとっては、それでさえ 理解できなかったりします。そのうえ更に「よくある○○という説明は間違い、誤解をうむ、 オブジェクト指向ではない」などと説明されると、卓袱台を引っくり返されたような感覚すら。 結局どれが”正”なんだ？と。お互いに自分の説明こそが正しいという立場で主張するわけですから （当たり前ですが）、初心者は余計に混乱し、根気がないと挫折します。 オブジェクト指向に対する根本的なモノの考え方は同じなのかもしれませんが、投稿・掲示板でも 意見が分かれるように、統一見解がないことこそが”なぜわからなくなってしまうのか？”の一番の 原因なのかもしれません。研修の講師の方も仰っていました。「わからないときは先輩に 訊いた方がよい、ただしその相手を間違えるとヘンな設計になる（笑）」。なんとなく分かるような 気がします。どうもベテランのJava開発者＝オブジェクト指向を理解している人ではないようです。 本当は誰もが認めるバイブル的な教本があるとよいのですがねぇ・・・。

>まあ、仕事のプロジェクトについてここであんまり書くわけにもいきませんから >このへんにしときます。 ですよね。 失礼しましたm(_ _)m

>自分も何の因果か、巡り巡って今はGのつくプロジェクトにどっぶり漬かっています。 >＃お客さんとコネのあるベンダーなので面倒がないというか、大変というか…＾＾； >＃(前会社で働いてたときよりも待遇も給料も良いので全然良いんですけどね) あの会社にGのつくプロジェクトはいくつかありますが、あのGであれば、 お会いする機会は今後もあるかもしれません。 まあ、仕事のプロジェクトについてここであんまり書くわけにもいきませんから このへんにしときます。

>ええと、それならおそらく私です。 やっぱりそうでしたか。お会いできるチャンスを逃してしまって残念です＾＾； >ただ、現在私は1階にコーヒー屋があるビルの向かいのビルにはいません。 ># 会社自体変わったような変わってないような。 そうなんですか…! >超巨大企業の子会社の、Gのつくプロジェクトの人たちも現在はコーヒー屋がある >ビルではないビルに移っているはずです(全員ではないはずですが)。 今年末くらいに駅近くの新しくできるビルに移るって話は聞いてますが、今はまだ大部分はそこのビルにあると思います。 >月日は過ぎ人は去り状況は刻々と変わっているようです。諸行無常といいますか。 自分も何の因果か、巡り巡って今はGのつくプロジェクトにどっぶり漬かっています。 ＃お客さんとコネのあるベンダーなので面倒がないというか、大変というか…＾＾； ＃(前会社で働いてたときよりも待遇も給料も良いので全然良いんですけどね)

こんにちは。 >自分は名古屋の伏見にある某企業で働いてるのですが、２年ほど前(2006年の3月末) >にとある会社(超巨大企業の子会社)の名簿みたいなやつに前橋さんのお名前を見かけ >ました。 ええと、それならおそらく私です。 >おそらく前橋さんの会社からすぐ近くの1階にコーヒー屋があるビルなのですが、 ただ、現在私は1階にコーヒー屋があるビルの向かいのビルにはいません。 # 会社自体変わったような変わってないような。 超巨大企業の子会社の、Gのつくプロジェクトの人たちも現在はコーヒー屋がある ビルではないビルに移っているはずです(全員ではないはずですが)。 月日は過ぎ人は去り状況は刻々と変わっているようです。諸行無常といいますか。

はじめまして、こんにちは。 ポインタ本を６年くらい前(？)に読んでから、前橋さんのファンです。 自分は名古屋の伏見にある某企業で働いてるのですが、２年ほど前(2006年の3月末)にとある会社(超巨大企業の子会社)の名簿みたいなやつに前橋さんのお名前を見かけました。 (ちょうど自分が3月末までその会社に派遣されてまして) おそらく前橋さんの会社からすぐ近くの1階にコーヒー屋があるビルなのですが、あのとき見た名前が本当に前橋さんなのか今でも気になっています。 迷惑でなければ、教えてくださいm(_ _)m

はじめまして。おほめいただきありがとうございます。 >よくわからない宣言は避けて、使わないようにしていたのですが >それが理解できると途端に使えるものが増えて、世界が広がったような気がしました 本にも書いたとおり、あまり複雑な宣言を使うのはおすすめできませんが、読むときには読めないと困りますし、わからないからとvoid*に逃げるのもよろしくないですから、宣言の読み方はわかっているほうがよいですよね。 お役に立てたようで何よりです。

C言語ポインタ完全制覇の本を読ませていただきました 細部まで説明してくれるこういう本は本当にありがたかったです よくわからない宣言は避けて、使わないようにしていたのですが それが理解できると途端に使えるものが増えて、世界が広がったような気がしました 良い本を出してくれて感謝致します

はじめまして。書き込みありがとうございます。 >で、今回は、面白いページがありましたので、ご紹介致します。（既に知っていらっしゃるかもしれませんが・・・） >http://builder.japan.zdnet.com/sp/c-programming-language/story/0,3800083430,20370255-2,00.htm?p=3&mode=all#block_comment 某筋から聞いて知っていました。4/1にかこつけてこんなのを書いちゃったくらいで (^^; http://d.hatena.ne.jp/kmaebashi/20080401 >しかし、簡単なポインタが分からない人は、表舞台（雑誌とか、本とか）から絶滅したと思っていましたが、まだまだ現役なんですね :-p C自体、うちの会社では使っている部署はどんどん減っているのですが、まだCの記事に需要があるようですね(この記事の出来はさておき)。 「C言語 ポインタ完全制覇」は今度第11刷が出ます(奥付は5月11日)。皆様のおかげです。

前橋さんのファンです。一度は書き込んでみたいと思っておりました。(^^;) で、今回は、面白いページがありましたので、ご紹介致します。（既に知っていらっしゃるかもしれませんが・・・） http://builder.japan.zdnet.com/sp/c-programming-language/story/0,3800083430,20370255-2,00.htm?p=3&mode=all#block_comment 最初は単純ミスかとも思いましたが、直せば直すほど馬脚を現していく有様を見ていると、これは「真性」だと思います。 しかし、簡単なポインタが分からない人は、表舞台（雑誌とか、本とか）から絶滅したと思っていましたが、まだまだ現役なんですね :-p

>JAVAを使っていてわざわざ１クラスのなかに全プログラムを記述するような >ことをせず、クラスに分割していけば自動的にオブジェクト指向になっていく >のではないでしょうか。 Javaで1クラスの中に全プログラムを記述するようなことをする人はめったに いないと思いますが、Cで、関数を複数の.cファイルに分類して書いていった ところで、「オブジェクト指向になっている」とは言わないでしょう。普通は。 そういうことを下記ページに書きました。 http://kmaebashi.com/programmer/object/othello.html、 | しかし、現状では、カプセル化は実現できていても、オブジェクト指向に | はなっていません。なぜならここにはオブジェクトがいないからです。 >そこで、JAVAのプログラマーであるのに、オブジェクト指向でない >プログラミングの例を示して解説していただければうれしいです。 >ただし初心者や技術不足が原因のしょうもない例ではなくお願いします。 いまどきJavaといえばWebアプリケーションの開発に使うことが多いと思いますが、 たとえばStrutsとJDBCを使うとして、UIの階層はStrutsが提供するクラスを 継承したりして作るかもしれませんが、そこから呼び出されるビジネスロジックの 階層を「staticメソッドの集合体」にするケースは結構あると思いますよ。 それでもJDBCが提供するinterfaceを使っているからオブジェクト指向だ、とか、 UI層ではActionを継承して作っているからオブジェクト指向だ、と主張する のであれば別に止めませんが。 いわゆる業務アプリケーションの開発において、継承やらインタフェースやらを 多用したクラス階層を自分で設計してプログラムを書いていく場面は実はかなり 少ないです。 以前この掲示板ではこんな議論がありました。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&thread=693 この中で紹介されているhappieさんの意見に、私は大筋で賛成です。 http://happiese.exblog.jp/3127241/

オブジェクト指向について分かりやすい説明ありがとうございました。CとJAVAの違いで説明されているところで感じたのですが、もともとJAVAでプログラミングしていれば自然にオブジェクト指向になるのではないでしょうか。JAVAを使っていてわざわざ１クラスのなかに全プログラムを記述するようなことをせず、クラスに分割していけば自動的にオブジェクト指向になっていくのではないでしょうか。私の疑問は、JAVAのプログラマーでありながら、オブジェクト指向でないプログラミングをするということの方が難しいのではないかということです。 そこで、JAVAのプログラマーであるのに、オブジェクト指向でないプログラミングの例を示して解説していただければうれしいです。ただし初心者や技術不足が原因のしょうもない例ではなくお願いします。しょうもない例というのは、Newのタイミングを間違えるとかそういう例です。

>結果として、このプログラムは一見正常に動きますが、 >再入力の場合に限り字数チェックが行なわれない、という奇妙な仕様になっています。 ご指摘ありがとうございます。コーディングの方針とかスタイルとか そういう話ではなく、再入力のときBOOK_NAME_LEN等より長い文字列を 入力すると領域破壊を起こしますから、これは致命的ですね。 こういうバグが入った経緯はさすがに思い出せませんが、正誤表に追加しておきました。 えー、他にもまだあるようでしたら(と書くのも怖いのですが、間違いは間違いとして 正誤表に載せておきたいと思いますので)