せっかく年休を取ったのに、雨、というか台風来てるし…。
前回(2013年6月13日の日記参照)こんなこといいな、できたらいいな、とウダウダ書きましたが、結局何がしたいのか?を考えてみました。
条件2(ガベージコレクション)と3(標準ライブラリ、GUIライブラリ)についてはalloc/freeは面倒くさい、車輪の再発明は面倒くさい、という普遍的な悩みですから特筆することはないでしょう。引っかかるのは条件1(unsigned型の存在)です。
条件1がなくて困るのは「バイト列のMSB側からNビット取ってきて、数値として返す」処理(※)が返すべき数値が、signedだったり、unsignedだったりして扱いが面倒くさいことです。
例を挙げると、あるバイト列から3ビット取ってきて3'b101というビット列が得られたとします。得られたビット列を5と解釈すべき場合と、符号拡張して -3と解釈すべき場合があるということです。
(※)MPEGの仕様書なんかでgetbits() という関数が出てきますが、まさにアレです。
単にNビット整数値の符号拡張をしたいだけであれば、下記のようにすればunsigned型なんて要りません。
/**
* Sign extension.
*
* @param v Value
* @param n Bits of v
* @param s 0: don't sign extension,
* otherwise: do sign extension
*/
long long signext(long long v, int n, int s) {
long long sb, mb;
if (n == 0) {
return 0;
}
sb = 1LL << (n - 1);
mb = (-1LL << (n - 1)) << 1;
v &= ~mb;
if (s && (v & sb)) {
v = mb + v;
}
return v;
}
さらに言えばRubyのように無限長整数を扱える言語の方がオーバーフローを考えなくて良いという点で有利である、とすら言えるでしょう。
あれだけ長々書いたくせに自己解決しちゃったよ、非常に迷惑だね!
でも、なんだろうこのコレジャナイ感は…?
この記事にコメントする
| < | 2013 | > | ||||
| << | < | 06 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| - | - | - | - | - | - | 1 |
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | - | - | - | - | - | - |
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: