- - PR -
int型の数字を二進数変換してbyte配列に変換したい
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-05-23 09:39
そうだったんですか ? そんな JLS の大改訂をされたら、困るなぁ。 そんな、いつ起きるかわからない、まずあり得ない仕様変更を心配する(まさに「杞憂」)よりは、すっきりとしたわかりやすいコードを書きましょうよ。 [ メッセージ編集済み 編集者: びしばし 編集日時 2005-05-23 09:41 ] | ||||||||||||
|
投稿日時: 2005-05-23 10:01
NAL-6295です。
まぁ、 仕様が変更される未来を予測して今は不利益なコードを記述するか、 仕様が「永続的である」保障は無いが、「永続的でない」保障も無い未来なんかよりも現在の利益を優先するか。 立ち位置の違いでしょうね。 自分が選択するのはいつも後者ですが。 #そんなことよりも二進数変換という言葉に違和感を感じる・・・ _________________ 「伝える」とは「人に云う」と書く。 http://d.hatena.ne.jp/NAL-6295/ | ||||||||||||
|
投稿日時: 2005-05-23 10:20
どもです。がるです。
確かに困るんですけどねぇ。ただ、可能性としては十分に。 実際、５年10年のスパンで考えると、過去に「常識」だったものが 結構変わってたりもするので。 # 色々と痛い目にあっております(笑
んっと…。 マスクが１つ増えただけなのですが、そんなに「ごちゃごちゃして わかりにくいコード」でしたか？ 個人的には「byteは8bitだから暗黙の了解として下位8bitしか代入されない ことを期待している」という暗黙のコードよりも「無用でもきちんとマスク 処理がなされている」という明示的なコードのほうがわかりやすいと思うの ですが。 その辺、どうなんでしょ？ # この辺はまぁ、私が「昔からCを使ってる」あたりも原因なのでしょうかね？ # C言語は「型に対するサイズ」が常に不定だったので、暗黙的なコードは # 非常に危険でした。 # その点、Javaは「型に対するサイズ」が(少なくとも今のところ)固定ですし。 # 慣れている人にとっては「byte == 8bit」が直感的なのかもしれないですね。
この辺はまぁ、そうでしょうね。実際「正解」なんてほとんどない業界 ですし。 ただ、私の場合は「どっちもありえる」です。特に、俗に「共通ルーチン」 と呼ばれる部分の中でもコア部分を記述するときは悩みますねぇ。 コア部分だけに性能もかなりシビアに要求されるのですが。場合によっては、 それと"同時に"移植性、仕様変更への耐久性も高いレベルで要求されるので。 # どないせぇと(笑 よく逃げるのは「コメント＆仕様書に書いておく」ですかね？ 今回なら ・プログラムではマスクをしない ・コメントに「& 0xFF は、byteが8bitであるために事実上不要なので省略」 こんな感じでしょうか？ これだと、ある程度「必要に応じてこうもりになれる」ので :-P 以上、軽く雑感でした。 | ||||||||||||
|
投稿日時: 2005-05-23 13:53
そもそもの議論の元が間違っています。
DataOutputStream#writeLong(long v) writeBuffer[7] = (byte)(v >>> 0); DataOutputStream#writeInt(intv) out.write((v >>> 0) & 0xFF); OutputStream.write(int v) に直接渡すためにマスクしています。 OutputStream.write(int v) の仕様として上位２４ビットは捨てると あります。 クラスライブラリの仕様変更を考慮しているようです。 | ||||||||||||
|
投稿日時: 2005-05-23 14:31
どもでし。がるです。
なるほどぉ…とおもって調べていたのですが。 (Javaはさして詳しいというほどでもないので) http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/io/DataOutput.html#writeInt(int) http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/io/DataOutput.html#writeLong(long) 上記のURLを見ると、どちらもマスクをしてあるのですが…。 もしかして、上記のURL、見る場所とか間違えてますでしょうか？ できましたら、Keisukeさんの発言のベースになっている仕様が載っている PageのURLとかを教えていただけるとありがたいです。 | ||||||||||||
|
投稿日時: 2005-05-23 14:51
もはや雑談ですね。
いやあ、私も「あり得そうな(想定されうる)仕様変更」については布石を打ちますけど、「プリミティブ型のサイズが変わる」なんて Java ではあり得ないと思いますよ。まさに「想定外」(^^; そういうものは「Java」を名乗らないか、旧バイトコードをそのまま動くようにサポートしてほしいですね。 それをふまえて
私も C の経験ありますから「定型句」として理解できますが、「Java では自明なんだし不要」と思いますよ。 # if( (boolean型の値) == true ) と同様に。 で、それでも「byte が、名前が同じままでサイズが変わることがあるかもしれないから布石を打っておけ」と言われたら... ・Integer.SIZE, Byte.SIZE を駆使して書き直す。 ・DataOutputStream を ByteArrayOutputStream につなげて利用(ライブラリにお任せ)。 ・assert文や System.getProperty("java.version") で現在の仕様の環境でしか動かなくする。 [あとから追記] ところで byte(または int)のサイズが変わったとして、このメソッドはやっぱり 8ビットずつに切り分けるのでしょうか ? 新しい byte のサイズで切り分けるのでしょうか ? [/あとから追記] とでもしますかねぇ...。 「アプリの機能仕様変更をどこまで想定して布石を打っておくか」というのはけっこう悩ましい問題なのは確かです。ある程度(納期限内や作成者の技術力で対応できる程度)で見切りをつけないとキリがありませんよね  [ メッセージ編集済み 編集者: びしばし 編集日時 2005-05-23 14:57 ] | ||||||||||||
|
投稿日時: 2005-05-23 22:09
がるがるさん、
私が引用したのは、j2se1.4.2_06 に付属のソースファイルです。 “＃”を使ったのが紛らわしかったですね。 eclipse 使いなので疑問に思ったらすぐにソースを見てしまいます。 | ||||||||||||
|
投稿日時: 2005-05-24 11:21
どもです。がるです。
なるほどぉ。 考えてみるに、私の書いたURLのほうは 「次に示すバイト値が、この順番で書き込まれます。」とは書かれても、 「このように実装されています」とは書いてないんですよね :-P そこから察するに ・意味合いとしては「下位１バイト。ゆえにビットマスク」となる ・実装としては「代入先がbyteならマスクは冗長なので行わない」 というのがJavaの開発陣のスタンスっぽいという感じなのでしょうか？ この辺の微妙な部分での差異と開発者のスタンスが少し見えてきたように 思います。 ありがとうございました ^^ | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。