K.Maebashi's BBS

ご自由に書き込んでください。雑談も可。
テスト書き込みの類はテスト用掲示板にどうぞ

[日付順表示] [日付順インデックス] [スレッド順インデックス]


新規投稿 | 開設者ホームページへ戻る | ヘルプ


[2002] 『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:藤四郎
2017/09/16 21:07:59

Link:
はじめまして。

『Java謎+落とし穴徹底解明』は改訂も増刷もされていないのがとても残念です。現行のJavaでは本書で指摘されていた問題点の多くは改善されているらしいですが、本質的な理解を得るのに本書はまだまだ「現役」ではないかと素人ながら思います。(ただ、3.6.7や7.1は、相応の開発経験のない私には、まだしっくり理解できません。)

さて、まだそちらの正誤表に載っていない事項を見つけたと思いました。重箱の隅的なものばかりで単に煩わしいかもしれませんが、報告させていただきます。(第4刷)

p.37 3行目
fillPatternCodeで指定される色
→ fillPatternCodeで指定される中塗りパターン

p.74 8行目
ことにになり,

p.90 12行目
p2 = new Point();
→ Point2D()

p.99 4行目
その方法については「6.5 clone()とCloneable」で説明します.
→ 「その」が「深いコピー」を指すのなら、それは7.3.1で説明されているような…。

p.104 Fig.2.14
1 2 3 4
→ 0 1 2 3

p.166 下から2行目
elseif

p.203 NOTE
IntStackがIntArrayの一部であり
→ 「IntStackはIntArrayを持っている」ので「IntArrayがIntStackの一部であり」かと思います。

p.212 Fig.3.16
Polyine
p.213 List 3.24 XDrawApplet.java l.25
"Polyine"

p.214 List 3.30 ShapeIterator.java
→ 誤りではないですが、 4.2.4 (p.246) との整合性からpublicはないほうがよいのでは? Drawableなどの他のinterfaceではpublicされてないですし…。

p.217 List 3.34 DrawWindow.java l.24, 27
scale
→ 誤りではないですが、他の箇所ではthis.scaleとされています。

p.217 List 3.34 DrawWindow.java l.126, 143, 151, 158
dcToWcX(e.getX()), dcToWcX(e.getY()));
→ dcToWcX(e.getX()), dcToWcY(e.getY())); // こちらも、 xMin, yMinを 0にしているため発現しませんが。

p.225 1行目
finish()
→ finishCommand()

p.240 Fig4.3
CLASSPAHT

p.340 33行目(下から3行目)
FactoryTestImpl
→ あるいは私の理解が足りないだけかもしれません。しかし、これを直前の段落にあるWindowTestImplに置換すれば理解したつもりになれるのですが…。

p.350
} catch (Exception ex) {
    err.printStackTrace();

p.354 List 7.1 l.1
import java.security.*;
→ 不要と思われます。

p.355 1行目
SecurityManagerのgetStackTrace()メソッドは
→ SecurityManagerのgetClassContext()メソッドは

p.357 22行目
兼ね合いもなどある

p.365 1行目
Colorというフィールド
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2003] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:(ぱ)こと管理人
2017/09/21 00:56:22

Link:
はじめまして。反応が遅くなりまして申し訳ありません。

15年も前の本ですが、色々ご指摘ありがとうございます。
次の週末に正誤表に掲載いたします。

1点だけ。

>p.99 4行目
>その方法については「6.5 clone()とCloneable」で説明します.
>→ 「その」が「深いコピー」を指すのなら、それは7.3.1で説明されているような…。

7.3.1の直列化を使った「深いコピー」はある種裏技的なものなので、
ここでの「深いコピー」は、あくまで6.5のものを意味しています。

>p.340 33行目(下から3行目)
>FactoryTestImpl
>→ あるいは私の理解が足りないだけかもしれません。しかし、これを直前の段落にあるWindowTestImplに置換すれば理解したつもりになれるのですが…。

ここはWindowsTestImplが正しいです。これが理解の妨げになっておりましたら
申し訳ありません。

ありがとうございました。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2004] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:藤四郎
2017/09/22 21:34:17

Link:
ご返信ありがとうございます。

>15年も前の本ですが、色々ご指摘ありがとうございます。
>次の週末に正誤表に掲載いたします。

私は誤解やら勘違いやらをしょっちゅうやらかす人間なので、ほとんどをご確認いただけて安堵しました。お忙しい中お手数おかけして恐縮ですが、いまなお精読するに値する本だと思うので、よろしくお願いします。

>7.3.1の直列化を使った「深いコピー」はある種裏技的なものなので、
>ここでの「深いコピー」は、あくまで6.5のものを意味しています。

お言葉を返すようで恐縮ですが、直列化を使った「深いコピー」は7.3.2で説明され、7.3.1ではその前振りとしてclone()での「深いコピー」の具体的コーディング例が載っています。そして、6.5にはclone()での「深いコピー」の具体的方法の記述は見当たらないようです――というのが私の理解なのですが…。それこそこちらの勘違いでしたら、本当にすみません。

こちらこそ、ありがとうございます。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2005] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:(ぱ)こと管理人
2017/09/24 23:53:24

Link:
ご指摘の点、正誤表に記載しました。

>>7.3.1の直列化を使った「深いコピー」はある種裏技的なものなので、
>>ここでの「深いコピー」は、あくまで6.5のものを意味しています。
>
>お言葉を返すようで恐縮ですが、直列化を使った「深いコピー」は7.3.2で説明され、7.3.1ではその前振りとしてclone()での「深いコピー」の具体的コーディング例が載っています。そして、6.5にはclone()での「深いコピー」の具体的方法の記述は見当たらないようです――というのが私の理解なのですが…。それこそこちらの勘違いでしたら、本当にすみません。
>
おっしゃるとおりです。確かに、6.5.ではclone()の実装方法について説明はしていますが、
それは「深いコピー」ではありませんでした。
7.3自体が裏技の説明なので、そこを参照というのも妙な気がしますが、
7.3.1にしか深いコピーの具体的実装はないですね……

正誤表にはそのように記載しました。ご指摘ありがとうございました。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2017] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:藤四郎
2017/11/05 20:16:43

Link:
おくればせながら、正誤表の追加とソースの訂正、ありがとうございました。おそれいりますが、またいくつかきづいてしまいましたので、ふたたびご面倒をおかけします。今回も当方の勘違いがありましたらお許しください。 (才能に乏しいようでなかなか理解がすすみませんが、趣味としてこつこつやっております。)

まずは、またもや細かいことですみませんが……。 p. 147 の英文で [emphasis is in the original text] とあるのが反映されていません。和訳の方はされています。また、和訳の方で「どのオブジェクトも参照しない特殊なnull参照」に相当する英文がないです。

X-Draw のソースで DrawWindow.java の l. 110 -
    public void mouseDown(int x, int y) {}
    public void mouseUp(int x, int y) {}
    public void mouseDrag(int x, int y) {}
は不要と思われます。

あと、 l. 164 - 
    public void resize(int width, int height) {
        this.adjustBoundary();
    }
ですが、今後の拡張を見込んでこのようにされたのでしょうか。

3.6.7 「本当にdraw()をShapeに入れてよいのか?」が、コードを実地にかいてみることでようやくわかってきました。それできづいたのですが、 p.227 の interface Visitor の三つのシグネチャーの頭に void がいるかと。また、 p.228 の
        v.visitPolyline(polyline);
は実際には
        v.visitPolyline(this);
になるかと。

ちなみに、つぎのようにかきましたが、これで適当でしょうか。(Polyline たちから draw() を排除するかわりに getter をいれなければならなくなったのがどうも……。)

class Polyline extends Shape {
        private Point2D[] points;
        
        Polyline(Point2D[] points) {
                this.points = points;
        }
        
        public Point2D[] getPoints() {
                return this.points;
        }

        void accept(Visitor v) {
                v.visitPolyline(this);
        }
}
// Circle, Rectangle は略

class DrawVisitor implements Visitor {
        Drawable drawable;
        
        DrawVisitor(Drawable drawable) {
                this.drawable = drawable;
        }
        
        public void visitPolyline(Polyline polyline) {
                Point2D[] points = polyline.getPoints();
                for (int i = 0; i < points.length - 1; i++) {
                        drawable.drawLine(points[i].getX(), points[i].getY(), points[i + 1].getX(), points[i + 1].getY());
                }
        }
        // visitCircle(), visitRectangle() は略
}

XDrawCanvas の paint() の
        shape.draw(this.drawWindow);

        shape.accept(new DrawVisitor(this.drawWindow));
に変更。

その他、まだ消化しきれていないこともありますので、今後もご面倒をおかけしてしまうかもしれませんが、どうぞよろしくお願いします。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2018] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:(ぱ)こと管理人
2017/11/08 08:27:48

Link:
ご指摘ありがとうございます。ちょっとどたばたしておりまして対応が遅れておりまして申し訳ありません。
週末にはご回答いたします。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2019] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:藤四郎
2017/11/08 20:53:59

Link:
大変お忙しい中、おそれいります。こちらはまったく急ぎませんので、ご都合のよろしいときにご対応いただければ幸いです。

ただ、またいまごろきづいてしまいましたが、 p. 228 l. 7
        visitPolyline(), visitCircle, visitRectangle
後二者に "()" がないので、こちらもよろしくお願いします。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2020] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:(ぱ)こと管理人
2017/11/13 01:15:51

Link:
週末に返信と言っておきながら日付が変わってしまいました。
遅くなりまして申し訳ありません。

>p. 147 の英文で [emphasis is in the original text] とあるのが反映されていません。

英語版の方で強調部分が太字になっていないということですね。
正誤表に載せておきます。

>また、和訳の方で「どのオブジェクトも参照しない特殊なnull参照」に相当する英文がないです。

この「どのオブジェクトも参照しない特殊なnull参照」という文言は、
JLSには含まれていて、日本語部分はそこから持ってきています。
このFAQのオリジナルの文章をWayback Machineから発掘したところ
「are pointers to these objects."」までで止まっていますが、
JLSから引用するのに勝手に変えるわけにもいかずにこうしたのではないかと
思います(記憶の彼方ですが…)。
ここはこのままとさせてください。

>X-Draw のソースで DrawWindow.java の l. 110 -
>    public void mouseDown(int x, int y) {}
>    public void mouseUp(int x, int y) {}
>    public void mouseDrag(int x, int y) {}
>は不要と思われます。

本当ですね。この手の空メソッドはインタフェースにあるシグネチャのうち
不要なものについて書くのが普通ですが、それにしてもメソッド名から違うので、
なぜあるのか不明です。正誤表に載せておきます。

>あと、 l. 164 - 
>    public void resize(int width, int height) {
>        this.adjustBoundary();
>    }
>ですが、今後の拡張を見込んでこのようにされたのでしょうか。

このメソッドは普通に呼ばれていますし、試しに処理を抜いてみたら、
倍率の計算がされずに何も描かれないので、必要なのではないでしょうか。

> p.227 の interface Visitor の三つのシグネチャーの頭に void がいるかと。

その通りです。正誤表に載せておきます。

また、 p.228 の
>        v.visitPolyline(polyline);
>は実際には
>        v.visitPolyline(this);
>になるかと。

こちらもその通りです。正誤表に載せておきます。

>ただ、またいまごろきづいてしまいましたが、 p. 228 l. 7
>        visitPolyline(), visitCircle, visitRectangle 

こちらもその通りです。正誤表に載せておきます。

いろいろご指摘ありがとうございました。

>ちなみに、つぎのようにかきましたが、これで適当でしょうか。
>(Polyline たちから draw() を排除するかわりに getter を
>いれなければならなくなったのがどうも……。)

描画をPolyline等ではなくDrawVisitorで行うようにしたのですから、
DrawVisitorに対し中身を開示しなければ描画できないというのは、
まあ、しょうがないですよね。
実際問題として、PolylineのようなCでいうところの構造体的なクラスが
外部に中身を開示しないというのは無理があるのではないかなあ、と、
この例を見ても思います。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2021] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:藤四郎
2017/11/13 19:04:42

Link:
貴重なお時間を割いていただき、改めてありがとうございます。

>JLSから引用するのに勝手に変えるわけにもいかずにこうしたのではないかと
>思います(記憶の彼方ですが…)。
>ここはこのままとさせてください。 

了解しました。

>>X-Draw のソースで DrawWindow.java の l. 110 -
>>    public void mouseDown(int x, int y) {}
>>    public void mouseUp(int x, int y) {}
>>    public void mouseDrag(int x, int y) {}
>>は不要と思われます。
>
>本当ですね。この手の空メソッドはインタフェースにあるシグネチャのうち
>不要なものについて書くのが普通ですが、それにしてもメソッド名から違うので、
>なぜあるのか不明です。正誤表に載せておきます。

僭越ながら、 java.awt.Component に

public boolean mouseDown(Event evt,
                                     int x,
                                     int y)

Deprecated. As of JDK version 1.1, replaced by processMouseEvent(MouseEvent).

というのはあるので、古い版の X-Draw のがまぎれこんでいたのかもしれません。

>>あと、 l. 164 - 
>>    public void resize(int width, int height) {
>>        this.adjustBoundary();
>>    }
>>ですが、今後の拡張を見込んでこのようにされたのでしょうか。
>
>このメソッドは普通に呼ばれていますし、試しに処理を抜いてみたら、
>倍率の計算がされずに何も描かれないので、必要なのではないでしょうか。

すみません、言葉足らずすぎでした。 XDrawCanvas.java の l. 39 - で

            Dimension d = getSize();
            drawWindow.resize(d.width, d.height);

また、 DrawWindow.java の l. 96 - で

    private void adjustBoundary() {
        Dimension canvasSize = canvas.getSize();
        double xScale = canvasSize.width / (this.xMax - this.xMin);
        double yScale = canvasSize.height / (this.yMax - this.yMin);

となっているのは、一見 getSize() の二度手間に思えます。つまり、

    private void adjustBoundary(int width, int height) {
        double xScale = width / (this.xMax - this.xMin);
        double yScale = height / (this.yMax - this.yMin);

        // ...
    }

    public void resize(int width, int height) {
        this.adjustBoundary(width, height);
    }

と (あるいは、いっそ adjustBoundary() の中身を resize() に移動) されなかったのはどうしてかと思いまして。 adjustBoundary() は意味的に引数をとるような処理ではないし、 resize() では今後の拡張次第で別の処理もありうるがこのバージョンでは adjustBoundary() だけ、ということなのでしょうか……。

ところで、 p. 228 「別の方法」についてもお伺いしたいことがありますけれども、長くなるので別稿にて。

あと、自分の投稿
http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=2017&range=1
につっこみですが

        shape.accept(new DrawVisitor(this.drawWindow));

ここは while ループ内なのでここで new するのは効率的にまずいですね。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2022] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:(ぱ)こと管理人
2017/11/16 01:05:52

Link:
>と (あるいは、いっそ adjustBoundary() の中身を resize() に移動) されなかったのは
>どうしてかと思いまして。 adjustBoundary() は意味的に引数をとるような処理ではないし、
> resize() では今後の拡張次第で別の処理もありうるがこのバージョンでは >adjustBoundary() だけ、ということなのでしょうか……。

resize()はリサイズですし、adjustBoundary()は範囲合わせなので別の名前で
別のメソッドにするのが自然なように思います。
確かにこのケースでは、resize()の時しかadjustBoundary()は呼びませんが、
たとえば私が大昔に作ったこちらのプログラム

http://kmaebashi.com/programmer/serializer/draw.html

では、ZoomやPanの機能があります。このプログラムでは、Zoom時は
別ウインドウが開くのでちょっと特殊ですが、

・マウスで長方形を指定すると、その範囲がウインドウ全体になるように
 拡大されるZoom機能。
・マウスで座標を指定するとその位置が中心になるように移動するPan機能。

といったものを考えると、

「ワールド座標系で範囲を設定し、adjustBoundary()を呼び出せばけりがつく」

というのは、悪くない方針のように思います。

ただ、そういう意味だと、むしろ「ワールド座標系で範囲を設定し…」の部分が
「事前に変数に値を設定しておく」というグローバル変数渡しまがいで
気持ちが悪いので、むしろadjustBoundary()にはxmin, ymin, xmax, ymaxを
引数として渡すべきだったかな、と思わなくはないですが、
それはそれでウインドウサイズを変えた時にはデバイス座標系での領域変更が
起点になるわけで、では入口のメソッドとしてデバイス座標系起点のadjustBoundaryByDc()とワールド座標系起点のadjustBoundaryByWc()を作って
前者にはwidth, heightを、後者にはxmin, ymin, xmax, ymaxを渡そうか、
とか考え始めるときりがないですね。
まあ、このあたりは、何が正解とも言えない話なのではないかと思います。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2023] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:藤四郎
2017/11/16 19:37:20

Link:
詳しく解説くださり、ありがとうございます。 adjustBoundary() に引数をわ
たすとなると、ワールド座標系版とデバイス座標系版にわけるのがすじという
ようなはなしになってしまうので、引数なしの adjustBoundary() を採用され
たというわけですね。疑問がすっきり解消しました。

さて、 p. 228 「別の方法」について、そもそも Abstract Factory パターン
をよくわかってないのでとんだ見当はずれだったらもうしわけありませんが、
「各 Shape のオブジェクトに……くっつける」ときに使い、「いざ描画すると
きには…… DrawShapeRuntime にダウンキャスト」するとなると、

abstract class AbstractFactory {
    abstract PolylineRuntime createPolylineRuntime(Polyline polyline);
    abstract CircleRuntime createCircleRuntime(Circle circle);
    abstract RectangleRuntime createRectangleRuntime(Rectangle rectangle);
}

class DrawFactory extends AbstractFactory {
    PolylineRuntime createPolylineRuntime(Polyline polyline) {
        return new DrawPolylineRuntime(polyline);
    }
    // ...
}

としか思いつけませんでした。しかし、こうだと Visitor 同様「 if else を
ずらずら」になるように思います。また、各 Shape のコンストラクターに
AbstractFactory の分の引数を追加することになるのでしょうか。

ちなみに、つぎのようにするのではだめでしょうか。

abstract class Shape {
    ShapeRuntime shapeRuntime;
}

abstract class ShapeRuntime {
    protected DrawShapeRuntime drawShapeRuntime;
    
    abstract DrawShapeRuntime getDrawShapeRuntime();
}

class PolylineRuntime extends ShapeRuntime {
    
    PolylineRuntime(Polyline polyline) {
        this.drawShapeRuntime = new DrawPolylineRuntime(polyline);
    }

    DrawShapeRuntime getDrawShapeRuntime() {
        return this.drawShapeRuntime;
    }
}

interface DrawShapeRuntime {
    void draw(Drawable d);
}

class DrawPolylineRuntime implements DrawShapeRuntime {         // 「 PolylineRuntime を継承」無用
    private Polyline polyline;
    
    DrawPolylineRuntime(Polyline polyline) {
        this.polyline = polyline;
    }
    
    public void draw(Drawable d) {
        Point2D[] points = this.polyline.getPoints();
        for (int i = 0; i < points.length - 1; i++) {
            d.drawLine(points[i].getX(), points[i].getY(),
                       points[i+1].getX(), points[i+1].getY());
        }
    }
}

class Polyline extends Shape {
    private Point2D[] points;

    public Polyline(Point2D[] points) {
        this.points = points;
        this.shapeRuntime = new PolylineRuntime(this);
    }
    
    public Point2D[] getPoints() {
        return this.points;
    }
}

// Circle, Rectangle の対応分は略

/*
XDrawCanvas の paint() の
        shape.draw(this.drawWindow);

        shape.shapeRuntime.getDrawShapeRuntime().draw(this.drawWindow);        // 「DrawShapeRuntime にダウンキャスト」不要
に変更。
*/
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2024] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:(ぱ)こと管理人
2017/11/19 00:13:43

Link:
>としか思いつけませんでした。しかし、こうだと Visitor 同様「 if else を
>ずらずら」になるように思います。

AbstractFactoryとその実装クラスにcreateXXXRuntime()がずらずら並ぶ、
というのは確かにそうですが、draw()だけでなく、
「クリックした座標との距離を算出するメソッド」や
「図形を移動させるメソッド」、「図形を囲む最小の矩形を算出するメソッド」等も
DrawShapeRuntimeに入れておけば、それを呼び出すところでは、図形の種類分だけの
何かをずらずら書く必要はなくなりますよね。
(DrawShapeRuntimeというのは、draw()メソッドだけ持っていそうな名前なので、
この名前はよくなかったかもしれません…… 付けるならDrawToolShapeRuntimeでしょうか)

>また、各 Shape のコンストラクターに
>AbstractFactory の分の引数を追加することになるのでしょうか。

それでもよいですし、ShapeRuntimeは、ドローツールならドローツール、
図形ファイルを読み込んで解析するプログラムならそのプログラム、
というように、プログラムの種類ごとに作ることになるのでしょうから、
どこかにstaticに持ってしまってもよいような気もします。
Javaだと、「図形ファイルを読み込んで解析するプログラム」では
デシリアライザを使って図形ファイルを読み込むのでしょうから、
その場合、ShapeRuntimeはreadObject()でくっつけることになりますから、
AbstractFactoryはそこから手が届くところにある必要がありますし。


>ちなみに、つぎのようにするのではだめでしょうか。

>abstract class ShapeRuntime {
>    protected DrawShapeRuntime drawShapeRuntime;
>    
>    abstract DrawShapeRuntime getDrawShapeRuntime();
>}

もともとの趣旨として、
「Shapeクラスは、ドローツールだけでなく、たとえばドローツールで作った
ファイルを解析する別のプログラムでも使う」
というものがありました。

その点で、このShapeRuntimeは、「ドローツール」と、
「ドローツールで作ったファイルを解析する別のプログラム」で
共用するものなのでしょうか。

私の想定したShapeRuntimeは、Shapeとセットになっており、Shapeを
使うあらゆるプログラムで使用するものです。そして、ドローツールだけで
使うShapeRuntimeのサブクラスがDrawShapeRuntimeです。
同じ趣旨なのであれば、ShapeRuntimeのメソッドの戻り値の型として、
DrawShapeRuntimeが出てきてしまっては、ShapeRuntimeがドローツール
専用品に依存してしまうので、よろしくないのではないでしょうか。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2025] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:藤四郎
2017/11/19 12:54:41

Link:
今回もわたしの読みの浅かったところをくわしく解説してくださってありがと
うございます。

Visitor パターンだと

>「クリックした座標との距離を算出するメソッド」や
>「図形を移動させるメソッド」、「図形を囲む最小の矩形を算出するメソッド」等も

XXXVisitor として散らばってかくことになるところ……ということですね。

>私の想定したShapeRuntimeは、Shapeとセットになっており、Shapeを 
>使うあらゆるプログラムで使用するものです。

Shape と draw() を分離することだけかんがえてて、そこまで頭がまわりませ
んでした。納得です。


おかげさまで (まだまだ真にふかい理解にはほどとおいですが) Java のしく
みがかなりわかってきたような気がします。『センス・オブ・プログラミング!』
等々も参考にさせていただきつつ、小規模なアプリケーションを自作できるよ
うになるのが目標です。

今後も質問等をさせていただくこともあると思いますが、その折にもよろしく
お願いいたします。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2026] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:藤四郎
2017/11/26 09:27:24

Link:
正誤表の追加、ありがとうございました。

ただ、その正誤表に関して、ただし今回とは別件で、

http://kmaebashi.com/nazojava/seigo.html#p74
>p.68 8行目
>誤
>
>ことにになり
>
>正
>
>ことになり

は p.74 のあやまりと思われますので、またもやこまかすぎる指摘になってしまい恐縮ですが、念のためよろしくお願いいたします。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[2027] Re:『Java謎+落とし穴徹底解明』の正誤について
返信


投稿者:(ぱ)こと管理人
2017/11/27 23:50:41

Link:
>は p.74 のあやまりと思われますので、またもやこまかすぎる指摘になってしまい恐縮ですが、念のためよろしくお願いいたします。

修正しました。

何度もご指摘ありがとうございます。
[ この投稿を含むスレッドを表示] [ この投稿を削除]