コグノスケ

C++ の変数初期化

会社で大幅にソフトを置き換えるチャンスがあったので、思い切ってCからC++11（gcc-4.6で使える範囲だけ）に切り替えました。

まだまだ使いこなせてませんがC++98より見やすいです。それでもC++ は魔界だなーと思うこともありますけど…。

Effective Modern C++ にも出てますが、C++11で導入されたuniform initialization（波括弧 { a, b, c, } での初期化）は、丸括弧や等号を置き換えることができます。大抵の場合は、ですが。

コンテナ系などstd::initializer_listを引数に取れる場合は、丸括弧と置き換えると動きが変わってしまいます。

int i1(5);
-> 5
int i2{5};
-> 5

std::vector<int> b1(5);
-> size:5: 0, 0, 0, 0, 0,
std::vector<int> b2{5};
-> size:1: 5,

丸括弧は丸括弧で、引数が0個になるといきなり関数宣言扱いされる、クラスメンバ変数に使えないなど、一貫性がなくて使いづらいのです。

std::vector<int> a1();
-> a1 type is std::vector<int, std::allocator<int> > ()
std::vector<int> a2{};
-> size:0:

結局、コンストラクタがstd::initializer_listを取れるかどうかを意識して、丸括弧と波括弧を使い分ける必要がありまして、だいぶ難しいですね…。

メモ: 技術系の話はFacebookから転記しておくことにした。

高槻ドライブ

車を放置しすぎてバッテリーが上がり、今まで自宅に3回ほどJAFを呼んでいます。4回だったかもしれないが…。

あまりにも車が可哀想なので、1か月に1度はドライブに行くことにしました。今回は高槻市の北側を体験するコースです。

• 枚方亀岡線（府道6号線）を北へ
• The山道（府道733号線）を西へ
• 茨木亀岡線（府道46号線）を南へ

距離は30km程度、約1時間ほどです。ここまで書いておいてなんですが、あまりオススメしません。

46号線から一瞬だけ見える高槻市、茨木市の夜景は綺麗ですが、他は森ばかりで何も見えません。733号線は対向可能なのに車1台分しか幅がなく、横は崖で、二度と行きたくない道です。

もっとマシな道はねーのかよ？と思うのですが、高槻市は道路状況があまり良くないのです。

北は山道、南は淀川で通れず、東西は大阪〜京都を移動する車で渋滞だらけです。

その点言うと、つくば市は、土地が平らで、道が綺麗で、空いてて、広くて、とても良かったんですがねえ…。

意外と知らない日本語の一面

電車で隣に座った親子がしりとりをずっとやっていました。幼稚園くらいのお子さんは言葉が枯渇気味になったようで、お父さんに「あ」で始まるなら思いつく…とリクエストをしていました。

そのときお父さんは「た」だったので「た」で始まり「あ」で終わる単語が思いつかず、ずっと悩んでいたそうです。

…という話を、電車を降りたときに奥さんがするもんだから、「よっしゃ、俺らも考えるべし」と挑戦したものの、

• タスマニア
• タンザニア

くらいしか思いつかず何だかイマイチ…。くやしいので家帰ってから辞書引いたら、

• ターヘルアナトミア
• ターミナルケア
• タウンウェア

などがありましたが、外来語しかありません。

そんなバカなと思って「あ」で後方一致かけても、「あ」で終わる単語のほぼ全てが外来語です。

「あ」で終わる日本語って無いんですね。意外でした。

メモ: 技術系の話はFacebookから転記しておくことにした。

Androidは巨大な壁

自作エミュレータ、ARM9とはいえ、一応ARMをエミュレーションしているわけだし、いつかAndroidも動かせるだろうか？と思って、試しにAOSPをビルドしてみました。

生成されたイメージファイルを見てみると、アプリも何も入れていないのにsystem.imgが1.6GBもあります。

ちなみにVersatile PBのNANDは最大でも64MBですので、全くお話になりませんでした。eMMCに期待ですかね…。

メモ: 技術系の話はFacebookから転記しておくことにした。

光で測る

レーザー距離計（メーカーのサイトへのリンク）を買ってみました。BOSCHのGLM 50Cです。Amazonで1万5000円でした。もっと安い機種もありますが、どうせならスマホとつながった方が面白いだろうと思いBluetooth対応機種を選びました。

メタルの巻き尺と比べると、

• 断然早い、1秒で計測
• 自分から見えるところならどこでも測れる
• 天井などの手が届かない高さも測れる
• 角度計、水平器の代用もできる
• 測定値を書き写す必要がない

測定値は本体に記録され、Bluetoothでスマホに飛ばして写真上に値を書き写すこともできます（要、専用アプリ）。

引っ越しや、新たに家具を買う時に非常に便利そうです。活躍の機会は遠いと思いますけどね…。

メモ: 技術系の話はFacebookから転記しておくことにした。

Flash ROMのエミュレーション

自作エミュレータ（リンク）にFlash ROMのエミュレーションを実装しました。

未実装だらけですが、mkfsしてmountするくらいなら、とりあえず動いています。今はリセットすると中身が消えますが、ファイルに読み書きするように変更したら、ストレージとして使えそうです。

バースト書き込みモードがあって高速と思われるIntelのNOR Flashをエミュレーションしていますが、速度的には残念な感じです。

$ dd if=/dev/zero of=/dev/mtdblock0 bs=262144 count=10
10+0 records in
10+0 records out
2621440 bytes (2.5MB) copied, 17.980000 seconds, 142.4KB/s

ただ、これはエミュレータ自体が遅いのも原因ではあります。

$ dd if=/dev/zero of=/tmp/aaa bs=262144 count=10
10+0 records in
10+0 records out
2621440 bytes (2.5MB) copied, 0.830000 seconds, 3MB/s

最速でもこれくらいにしかならないはずです。

作ってみて感じたこと

Flash ROMをエミュレーションしていて思ったのは、単純なだけに書き込みに関してはかなり非効率的なデバイスだということです。

Flash ROMは独立したコマンド線を持ちません。CPUはコマンドもデータも混ぜてバスにWriteします。WriteされたデータはFlash ROM側の状態によってコマンドと解釈されたり、データと解釈されたりする仕組みです。

書き込みの際は、出来る限りデータだけ送る方が効率が良いですが、Flashの場合は仕様上コマンドWriteやステータスReadを必ず挟まなければならないため、効率が悪いです。

Flashの宿命として部分的な書き換えが出来ませんので、書き換えの際は必ずErase -> Writeが行われます。Eraseは256KBなどの大きな単位なのに、書き込みは最大でも128バイトしか書けません。これも効率が悪い原因でしょう。

将来への展望

次に何か足すとしたら、eMMCにチャレンジしてみようと思います。ストレージ専用のI/Fならば断然効率が違う…はずです。たぶん。

メモ: 技術系の話はFacebookから転記しておくことにした。