画像収集する時に都合が良い、 マウスゼスチャの感度が丁度良い という理由でsylera、Operaってマイナーなブラウザ使ってたんだけど
・syleraは開発終わってる
・Operaは進化して画像保存のショートカットが 変わってしまったので使えない
・Operaは進化？してマウスゼスチャの判定がシビアすぎて使えない
もはやOpera使う理由も無くなった。
狐かChromeに乗り換えたほうがいいんだろうか…
ダメ元でOperaに要望でも出してみたらいいのかな、ショートカットとか使い慣れてるブラウザのままでいたいしなぁ…
ひさびさに更新。
Java始めた。 というかAndroid開発始めたらJavaしか選択肢が無かった。
ＵＩ貼り付けて選択にしたがって計算するだけのアプリケーション作ってるんだけど、たったそれだけでとても苦労しています。新しい開発環境はめんどくさいわー
C++で開発できるようにならないかね… 今作ってるものが完成したらC++でできるかどうか探してみようか、、
ライブラリ はＣで作れるみたいな情報は見たので、もしかしたらＣ＋＋で開発もできるのかもしれない。。。
仙台の友人が 「ガソリン入れるのに９時間並んだ」 とツイーットしていた、仙台でタクシードライバーやってる友達が居るんだけどそいつもさぞ苦しいことになっているのだろうと思ったら、友人のタクシー会社は半分以上がガス車とのことで被害ほとんど無いそうです。
こんな時だけガス車いいなぁと思ったり。
仙台で住んでた場所が山沿いであったため、友人知人がほぼ全員山沿いに住んでる、おかげで津波被害が無く「揺れただけ」という感じらしいので安心した、石巻に実家のある奴も家は浸水でダメになったけど、家族全員無事だったそうなので安心した。
水道が１週間ほど止まったのでその間風呂に入れなかったとか、トイレの水を近くの沼や川から汲んできて流しているとか、色々と苦労は多いみたいですけどね。
仕事始まったら少しでもいいので募金しよう…
最近は皆大学出るのが普通みたいで、卒業する人間全員が管理職志向というか、作業やるとかありえんみたいな志向な気がする、
なにかをやる時って、１０人中リーダーは１人 とか、そういう割合なんだから全員管理職志向とか成立するわけないよね。
不況だの就職難だのの原因って本当はその辺にあるんじゃないのかと思ってしまう。
いまの日本って 「作業しないけど僕はレベル高いでーす」 みたいなアホだらけなんじゃなかろうか
・プロジェクト管理には○○○を使う
・ソース管理には○○○を使う
CGIなんかでできたグループウエアであったり、マイクロソフトのなんとかかんとかであったり 、
CVSだったり、SubVersionであったり、と、ツールが色々と出てくるのはいいんだけど、
おまえら使えんの？
使いこなす気あるの？
ってのが問題なのね。
進捗管理はExcelなんかで雛形作っちゃえば週一テンプレに従った編集するだけじゃん？ツールに頼る必要あんの？
メールテンプレート作っておけば報告なんかも都度応用が効くからメールで十分じゃないの？
ソース管理とか毎日差分取って３ヶ月上前のは切り捨てとか、簡単なマクロ毎日実行するだけで十分じゃね？
とか、思っちゃうのよ。
僕はCVSでソース管理してた経験あるけど、結構敷居高いのね。
checkoutしてupdateするだけだったら簡単だけど、
分岐管理とかし始めたり、cvsのルールではなく人間的な感覚でバージョン統合したいなんて考え始めるとCVSって急に難易度高くなるのね。
ツール使おうとか主張する人は「ツール」って言いたかっただけじゃないのかな？
パズワード連呼して自己主張してるだけのゴミの言うことはどうでもいいので、現場で本当に必要か考えましょうね。というお話でした。
allocatorを作成していて、めんどくさいけど動作を調べないといけなかったので std::vector と std::list の動作について調べました。
－－－－－
std::vector はメモリ確保が必要になった時は 「最初に設定されたサイズ（最小 １）」 × ２のべき乗 × サイズ で要求してくる。
ということらしい。
g++ で検証しました。
std::vector<int> ilist;
ilist.push_back(1)
とかやると、４バイトｘ２ 、３個目をpush_backすると４バイトｘ４ってな感じで、（１，２，４，８…） * sizeof(int) の確保をしてあげれば良い。
std::vector<int> ilist;
ilist.resize(10);// reserve(10); でも良い
ilist.push_back(1)
とかやると、４バイトｘ２０ 、２１個目をpush_backすると４バイトｘ４０ってな感じで、（１０，２０，４０，８０…） * sizeof(int) の確保をしてあげれば良い。
という動きでした。
というわけで、厳密には、拡張が必要になったら、
（最後に resize や reserveで設定したサイズ） × ２のべき乗 × サイズ のメモリを要求してくる。
言葉だけだととても分かりづらいね…
－－－－－
ちなみに std::list はなにやっても一個ずつ確保でした。
int（サイズ４とする）のlist作った場合は常に４＋８の領域を確保して返してあげれば良いようです。
allocatorめんどくさいね。
色々悩んでたけど「処理は処理の集合である」という、ただそれだけのことであった。
組み込みアプリでもゲームプログラムでも同じ考え方で通る。
人間的な言葉で言い直すと「シーンが集合してひとつのシーンを構成する」とか、そんな感じ。
実装的な話をすると、あるクラスが自分と同じ型のクラスポインタの配列を持っているような設計で、多段ネストできる仕組み。
class Hoge {
public:
std::vector<Hoge*> vSub;
};
こんな感じ。
後は↑のメンバに処理・描画なんかの共通処理を virtual で実装してインターフェースクラスを作って、シーン別に派生クラスを作って組み合わせると。
ゲームプログラムへの実装テスト終わったんだけど、ソースを改めて見るとと後５，６年以上早くこの結果にたどり着けたんじゃないかと思えてしまうほどシンプルであった…
( ´～｀)
Powered by WordPress