K.Maebashi's BBS

>ただ、今度はP102のPostBBS.javaをコンパイルしようとするとエラーが。 エラーが出たというのであれば、せめてエラーメッセージは書いてください。 >普通に >javac PostBBS.java としてるのですが・・・。 p.102にPostBBS.javaはないので、どこのソースのことかわかりませんが、 Tomcatで動かすサーブレットをコンパイルするのであれば、 > javac PostBBS.java ではなくて、p.97にあるとおり、 >javac -classpath C:\Tomcat8\lib\servlet-api.jar PostBBS.java のように、servlet-api.jarをクラスパスに入れてコンパイルする必要があります。 (Tomcatのバージョンや配置先が違うなら、適宜読み替えてください)

ご回答ありがとうございます！素晴らしい書籍の執筆ありがとうございます！ 時間がとれたので、早速回答に従ってやってみます・・・のような返信を入れたのですが、Upされてないのか、私が不慣れなのか・・・ｗ とにもかくにも、本日もう一度最初からやり直してみましたら、ちゃんと動きました。 ありがとうございました。 ただ、今度はP102のPostBBS.javaをコンパイルしようとするとエラーが。 普通に >javac PostBBS.java としてるのですが・・・。 ご教授いただければ幸いでございます。

>いつもお世話になっております。初めて投稿します。 はじめまして。 >書籍「Webアプリケーション開発入門」のP99で、「http://localhost:8080/ShowBBS」を >ブラウザで実行すると、書籍の中にあった、「ごめんねごめんねごめんねごめんねごめ >んね･･･」と続くページが表示されてしまい、掲示板が表示されません。 書籍の通りの順番でp.99だとすると、「3.3.3.Tomcat で掲示板を作る」のところです。 章タイトルの通り、ここでは、へなちょこサーブレットコンテナHenacatを作る前に、 Tomcatで掲示板を作ろうとしています。 そして、「ごめんなさいごめんなさいごめんなさいごめんなさいごめんなさい ごめんなさい…」と続くページは、p.74にあるWebサーバもどき「Modoki/0.2」の 404ページです。 Tomcatの設定をわざわざ変えたのでなければ、TomcatがModoki/0.2の404ページを 返すわけがないので、ここではTomcatではなくModoki/0.2を叩いているのでは ないでしょうか。 ただし、Modoki/0.2のポート番号は8001で、Tomcatのポート番号は8080です。 Modoki/0.2のポート番号をわざわざ変えたのでなければ、 「http://localhost:8080/ShowBBS」 であればTomcatが動くはずです。 考えられる可能性としては、 ①本当は「http://localhost:8001/ShowBBS」を叩いていた。 ②Modoki/0.2のポート番号を8080に変えて実行していて、 　Tomcatはポートが塞がっているので起動に失敗している。 のどちらかですかねえ。

いつもお世話になっております。初めて投稿します。 書籍「Webアプリケーション開発入門」のP99で、「http://localhost:8080/ShowBBS」をブラウザで実行すると、書籍の中にあった、「ごめんねごめんねごめんねごめんねごめんね･･･」と続くページが表示されてしまい、掲示板が表示されません。 Tomcatも動いているようですし、書籍の通りやったつもりなのですが、どこが良くないのかがわかりません。同じようなところで躓いて、ピンときた方、いらっしゃいましたら、ご教授お願いします。

お世話になっております。 細かい内容について答えていただき、ありがとうございます。 char,shortと、intでの処理速度やサイズの違いについて、よく分かりました。 現在の処理環境なら、あまり気にする必要は無いのかな、という気がしました。 スカラの変数ならintを使うということも理解できました。 お忙しいところ、ありがとうございました。

『CプログラミングFAQ』は、持ってたはずなのですが、どこを探しても見当たらない…… >①汎整数拡張により、char型やshort型は、値を取り出す時に32ビットに変換されるので、 >int型より処理時間がかかったり、int型より実行ファイルが増大したりするのでしょうか？ この手の性能問題は私は全然詳しくないのですが(アプリケーションプログラマですので…)、 今時のCPUを相手に、どちらが良いとか悪いとかそう一概に言えるものではないと思っています。 たとえば先のchar_test.sとint_test.sをそれぞれGAS(GNU assembler)にかけてみると、 movsblの命令長はmovlよりも確かに長いのですが、int int_var = 5; の「5」が 32ビット幅になるので、結局のところ実効形式のサイズとしてはint_test.sの方が 微増しているようです。 char_test.s 17 0008 C645FF05 movb $5, -1(%rbp) 18 000c 0FBE45FF movsbl -1(%rbp), %eax 19 0010 89C6 movl %eax, %esi int_test.s 17 0008 C745FC05 movl $5, -4(%rbp) 17 000000 18 000f 8B45FC movl -4(%rbp), %eax 19 0012 89C6 movl %eax, %esi 特に配列なら、主記憶は十分にあっても、今時キャッシュに乗らないと性能は出ないので、 小さな型を使った方が早いケースはあるかもしれません。 配列でないなら、どちらにしても、そう大差があるとは思えませんが。 >②汎整数拡張があるので、char型やshort型を使わずに、int型を使った方が良いのでしょうか？ 配列でないスカラの変数であれば、たとえば1バイト文字しか入らないとわかっていても、 私ならintを使います。「ポインタ完全制覇」にも書きましたが、getchar()の 戻り値やputchar()の引数も、実際intですし。

ご連絡遅くなりました。 アセンブラの解説をしていただき、ありがとうございます。 char型はアセンブラ上で変換が入るということで理解しました。 会社内で汎整数拡張について聞いてみたら、アセンブラ上で差異は無いと言われたので、間違って理解していました。 movsblというのが分からず、ネットで調べました。 movsはsign extension（符号拡張）によるコピー、blはfrom byte(8ビット) to long(32ビット)ということで理解しました。 これに付随して、さらに質問があります。 ①汎整数拡張により、char型やshort型は、値を取り出す時に32ビットに変換されるので、int型より処理時間がかかったり、int型より実行ファイルが増大したりするのでしょうか？ ②汎整数拡張があるので、char型やshort型を使わずに、int型を使った方が良いのでしょうか？ ①については、char型やshort型を使うと、アセンブラ上で余計な変換が入って実行ファイルが増大してしまう、ということが書かれた技術書を読んだことがあります（『CプログラミングFAQ』だったと思います）。 ②については、C言語ではint型が基準なので、できるだけint型を使うべきなのかなと思っています。 巨大な配列を扱う時にメモリのサイズを減らしたいのでchar型やshort型を使うのはいいと思うのですが、 そうでないなら、できるだけint型を使うべきではと思っています。

こんにちは。 >汎整数拡張という機能は、char型やshort型は、アセンブラ上ではint型と同じように >扱われる、ということかなと思うのですが、この認識で合っているでしょうか？ >Cのソースコードからアセンブラに変換されるときに、汎整数拡張によって何か >変換処理が行われるわけではないと思っています。 汎整数拡張という機能は、charやshortの変数でも、式の中ではintに変換される、 という機能です。変数に格納された値を使う時にはintでも、変数のサイズは、 charやshortならintより小さいわけですから、メモリから値を取り出して (intと同じビット幅の)レジスタに乗せるときには汎整数拡張による変換処理が 入りますし、逆に(int型の)式の値をcharとかshortの変数に格納するときには、 逆の変換が必要です。 試してみました。 char_test.c #include <stdio.h> int char_test(void) { char char_var = 5; printf("%d", char_var); } int_test.c #include <stdio.h> int int_test(void) { int int_var = 5; printf("%d", int_var); } アセンブラ上の差異は以下です(Linuxでgcc -S)。 char_test.s movb $5, -1(%rbp) ← char_var = 5のところ movsbl -1(%rbp), %eax ←　char_varの値をeaxレジスタに移動 int_test.s movl $5, -4(%rbp)　←int_var = 5のところ movl -4(%rbp), %eax　← int_varの値をeaxレジスタに移動 int_test.sでは、単に32ビットを移動するmovl命令が使われていますが、 char_test.sでは、5をchar_varに代入する際にはバイトでの移動命令movbが、 char_varの値を取り出すときにはバイトを32ビットに変換しつつ移動する movsblが使われていることがわかります。

お世話になっております。 汎整数拡張(又は整数拡張)について質問があります。 汎整数拡張という機能は、char型やshort型は、アセンブラ上ではint型と同じように扱われる、ということかなと思うのですが、この認識で合っているでしょうか？ Cのソースコードからアセンブラに変換されるときに、汎整数拡張によって何か変換処理が行われるわけではないと思っています。 試しに、char型、short型、int型による演算を、アセンブラ上で比較してみたのですが、差異が出てしまいました。 全て同じような結果になると期待していたのですが、そうはならなかったです。 あまりアセンブラに詳しいわけではないので、自信を持って言えるわけではありませんが。

はじめまして。 >180ページのTable3-3でint *hoge[10]のサイズが8×10になっていますが >int型の配列へのポインタなので4×10ではないでしょうか？ int *hoge[10]は、そのページの説明にもあるとおり、 「int型へのポインタの配列(要素数10)」です。 ポインタのサイズは処理系依存ですが、その前のページでポインタは8バイトと 仮定しているので、8×10で80バイトです。 なお、「int型の配列へのポインタ」であれば、(指す先は何であれポインタなので) 8バイトになりますね。

最近貴書を購入しました。 一つ質問があります。 180ページのTable3-3でint *hoge[10]のサイズが8×10になっていますがint型の配列へのポインタなので4×10ではないでしょうか？ よろしくお願いいたします。

すみません、自己解決しました。 Eclipseがコンパイル時にデフォルトで使用するバージョンがJavaSE11になっていたので、CokkieTestもreleaseオプションで指定で同バージョンにすることで解決致しました。 （というかそもそもスタックトレース見ろレベルの質問でした、大変失礼致しました。）

はじめまして。 >URL（http://localhost:8001/testbbs/ShowBBS）を入力したところでclassLoaderが例外を発生させてしまいました。 具体的なスタックトレースがわからないので何ですが、 もし起きているのがClassNotFoundExceptionだったとすると、 ShowBBSのクラスが所定の場所にないのではないでしょうか。 Henacatの場合、Henacat自体のソースやクラスをどこに置くかに関係なく、 サーブレットのクラスは、WebApplication.javaの8行目、 private static String WEBAPPS_DIR = "C:\\Henacat_0_1\\webapps"; この場所に置いてあることを期待しています。 もっとも、ここに置いてないならEclipseでなくても動かないですし、 >ShowBBS等のクラスパス指定もElicpseのプロジェクト配下のクラスパスを >指定してコンパイルしています。 というのは、「3.4.3 Henacat ver.0.1 で掲示板を動かす」の | この修正を加えたうえで、Henacatのクラスファイルのルートである | com ディレクトリが存在するディレクトリ（「com\ kmaebashi\henacat\……」と | いうディレクトリ階層の根元）にclasspathを向けてコンパイルし、 | クラスファイルを作ります。 という記載に沿っていることを意味するのであれば、そのあたりも 当然分かったうえで実行されているように思います。 あとは、具体的な例外を見てみないと、ちょっとわかりません。

こんばんは、本質的なところと全く違うので恐縮ですが、 「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」の第3章にて実装したHenacat0_1の挙動について質問となります。 Henacat0_1のソースコードをダウンロードし、 コマンドプロンプトにてコンパイルを通してMainを実行したところ、 特に問題なく掲示板が稼動しました。 ところが、同ソースコードをEclipseで作成したJavaプロジェクトにコピペしてMainを実行したところ、 URL（http://localhost:8001/testbbs/ShowBBS）を入力したところでclassLoaderが例外を発生させてしまいました。 （デバッグ実行させたところ、WebApplicationインスタンスやServletInfoインスタンスは値を渡せているように見えます） Eclipseはデフォルト文字コードがUTF-8ですが、本プロジェクトについては個別設定でsjisを設定しているので文字コードは問題ないかと思うのですが。。。 また、binフォルダを見ても無名クラス含めてクラアスファイルはしっかり作成されていますし、ShowBBS等のクラスパス指定もElicpseのプロジェクト配下のクラスパスを指定してコンパイルしています。 文字コードとコンパイルミス以外に考えられる原因等はありますでしょうか？

返信が遅れて申し訳ありません。 >書籍の中の補足でNULLマクロは処理系によって定義のされ方が違うと書かれていましたが、 >(void*)0であっても0であってもNULLは真偽値で言えば偽が返る値ということですね。 その通りです。これについてはC FAQに記載がありました。 http://www.kouno.jp/home/c_faq/c5.html#3 | 5.3: | ポインターがヌルポインターでないかどうかのテストの省略形 「if(p)」は有効なのか? | ヌルポインターの内部表現が0でない場合は どうなるのか。 | A: | C言語が式のブール値を必要とする場合(if、while、forやdo文において、 | また&&、||、!、?:演算子と共に使う場合)、0と比較して等しい場合は偽の値が | 産み出され、その他の場合は真が産み出される。すなわち | | if(expr) | | と書いたらいつも、「expr」がどんな式かにかかわらずコンパイラは必ず | | if((expr) != 0) | | と書かれたように基本的には動作する。

書籍の中の補足でNULLマクロは処理系によって定義のされ方が違うと書かれていましたが、(void*)0であっても0であってもNULLは真偽値で言えば偽が返る値ということですね。 本日読了しました。初心者だったので4章以降の実践的な部分は難しく感じる部分もありましたが、何度も読み返していくことでかなりの部分を理解できたと思います。 入門書を読んだだけで理解が曖昧だったポインタや配列、変数の分類や構造体などのC言語の文法についても改めて整理できました。本書のテーマはC言語のポインタですが、結果的にはC言語の文法全体に触れるような構成になっているのはそれだけC言語とポインタが深く広く結びついているということですね。 長くなりましたが技術書ながらとても読みやすく勉強になる本でした。質問にも丁寧に答えていただきありがとうございました。

stdinも含めてFILE構造体には、ファイルが終端に達したことを示すフラグがあって、そのフラグが立っている場合にはfgetc()で取り出される値はEOFになるということですね。 納得できました。ありがとうございます。

>P.297 List 5-14 11行目で、for文の終了条件にposとあるのですが、 >これは pos != NULL ではないでしょうか。 Cでは0以外は全部真なので、条件式にposと書いてもpos != NULLと書いても 意味は同じです。 Cプログラマは使いがちな書き方ではありますが、p.57の「ポインタ演算なんか 使うのはやめてしまおう」のところで『「一見してわかりにくいように見える」なら、 やっぱり書くべきではないでしょう』とか書いてる本としては ちょっとダブルスタンダードっぽいかな、とは我ながら思わなくもないです (^^;

あれ、昨晩返信したつもりなのに投稿されていませんでした。 >それとも標準入力において一度EOFが入力されたら、以降標準入力から取り出される値は >EOFとなることが決まっているのでしょうか。 こちらです。 規格では(マクロであることを除き)getc()はfgetc()と等価とされていますが、 そのfgetc()の説明には以下のようにあります。 | 返却値　そのストリームのファイル終了表示子がセットされている場合， | 又はストリームがファイルの終わりに達している場合，そのストリームの | ファイル終了表示子をセットし，fgetc 関数は，EOF を返す。 つまり、FILE構造体には「ファイル終了表示子」というフラグがあり、 ファイルの最後に達するとそれがセットされて、以後はEOFを返します。

お忙しい中ご返信ありがとうございます。 度々申し訳ないのですが、確認させていただきたい所がございます。 P.297 List 5-14 11行目で、for文の終了条件にposとあるのですが、これは pos != NULL ではないでしょうか。

>はじめまして。 はじめまして。読んでいただきありがとうございます。 >p.114 List2-6 12行目 >コメントとの対応を考えると、%edではなく%edxではないでしょうか。 そうですね。オリジナルのソースを見ると%edxになっているので、 編集段階で(矢印を入れたときに?)xが消えてしまったようです。 確認不足でした。申し訳ありません。 >p.226 10の後の英語的表現 >英文の2行目最後のfucntion(int)の後に閉じ括弧)がありますが、 >不要ではないでしょうか。 こちらもそのとおりです。申し訳ありません。 ご指摘ありがとうございました。後ほど正誤表に入れさせていただきます。

重ねて質問させていただきます。 C言語ポインタ完全制覇 P.243-246 の、read_line()関数を、引数にstdinを渡して呼び出す部分について聞かせていただきたいです。 例えば標準入力から、 abcd[Enter] ef[EOF] というように入力すると、read_line()関数は、P.244 List4-6 の61-75行目の処理で、 まず"abcd\0"を返し、次にline_bufferが"ef"になったところでchがEOFとなるので61行目のwhileを抜けて69行目に進み、結果"ef\0"を返します。 この時点でまだNULLを返さないので、main()関数のwhileは次のループに入り、再びread_line()関数にstdinを渡して呼び出すこととなりますが、この時に61行目のgetc(fp)で取り出される値は何なのでしょうか。 実験してみると、どうもこの段階でEOF(だけ)を取り出していて72行目に進み、read_line()関数がNULLを返しているようなのですが、標準入力においてキーアクションのEOFの後に続けて入力を行うことが可能ならば、getc(fp)でその入力値を受け取ってしまうということはないのでしょうか。 それとも標準入力において一度EOFが入力されたら、以降標準入力から取り出される値はEOFとなることが決まっているのでしょうか。

はじめまして。 C言語ポインタ完全制覇(初版　第一刷)の内容についていくつか確認させていただきたいです。 C言語勉強中、アセンブリ言語については全く知らない身なので、見当外れな質問でしたら申し訳ないです。 p.114 List2-6 12行目 コメントとの対応を考えると、%edではなく%edxではないでしょうか。 p.226 10の後の英語的表現 英文の2行目最後のfucntion(int)の後に閉じ括弧)がありますが、不要ではないでしょうか。

ご連絡ありがとうございます。 正誤表を確認しました。 ご対応、ありがとうございました。

はじめまして。遅くなりましてすみません。 >330ページにある、 >void (*draw_shape_func_table)(Shape *shape)[] >というのは、誤植ではないでしょうか？ >正しくは、 >void (*draw_shape_func_table[])(Shape *shape) >だと思います。 確認しました。これはこの本のテーマにもろに重なっているという点で かなりまずいミスでした。申し訳ありません。 「わからない人は3章を読み返しましょう」って書いてあるのが 我ながら余計に痛いです。 正誤表に載せておきます。ご指摘ありがとうございました。

前橋和弥様 改訂版のC言語ポインタ完全制覇を読んだものです。 非常にためになる本で、常日頃参考にさせて頂いております。 今回は、この本に誤植らしきものがあるので、ご連絡致しました。 330ページにある、 void (*draw_shape_func_table)(Shape *shape)[] というのは、誤植ではないでしょうか？ 正しくは、 void (*draw_shape_func_table[])(Shape *shape) だと思います。 前者だとコンパイルが通りませんでした。 以上、確認をお願い致します。

>ぱさんの本で自分がポインターの何が解っていないか初めて解り >大変良い物だとありがたい限りです はじめまして。読んでいただきありがとうございます。 >ところで次のような物を見つけたのでご存じなければつまみにでもどうぞ >https://cdecl.org/ 紹介ありがとうございます。初めて知りました。 ポインタ完全制覇でも取り上げた、K&Rに載っているdclのWeb版ですね。 Webで簡単に解析できるのは便利なので、あとはひっくり返して日本語に してくれれば…… と思うのですが、自分で作れと言われそう。 時間があれば、作ってみたい気はするのですが。

こんばんは ぱさんの本で自分がポインターの何が解っていないか初めて解り 大変良い物だとありがたい限りです ところで次のような物を見つけたのでご存じなければつまみにでもどうぞ https://cdecl.org/

>レスが付かないまま１週間以上たってしまったため、自己レスします。 すみません、最近どたばたしておりまして、ちょっと気力がたまりませんでした。 >で、パケット解析をするとすぐわかりますが、ブラウザから [ http://localhost:8001/日本語 ] でアクセスすると、 >サーバからレスポンスコード301が返ってきており、 >そこで指定されている移動先URLが文字化けしています。 なるほど…… これはさすがに気付いてしかるべきでしたね。 パケットキャプチャやFiddlerどころか、F12開発者ツールでわかるレベルの話です。 言い訳しますと、 >SenderThread.javaの24行目に、以下のようにSystem.out.println()を挟んで確認しました。 …という確認をしていたのにリクエストは1回ずつしか来なかったので、 リダイレクトは想定しませんでした。最初の1回はちゃんと飛んでたはずですが (過去投稿を見るとIEではそうだったとの記載もある)、今F12を入れて見てみると、 2回目以後はキャッシュされてますね。 「F12開発者ツール」とか、「変な動きがあればキャッシュを消せ」あたりは Webアプリ開発の基本ですが、どうもぼけてたようです。

削除パスワードを設定していなかったため修正も削除もできないため返信します。 前回の発言、一部間違っていました。ダウンロードしたのは再現テストの前、一番最初です。