本当に怖いC++erとC++という糞言語 - 神様なんて信じない僕らのために
かつて、ゲームプログラミングはアセンブリが主流で、8bitのCPUは掛け算や割り算すらないものでした。割り算がないCPUっていつの時代だよ、っていう人たちもおりますが、ゲームボーイアドバンスに搭載されているARM7TDMIは除算の命令を持っていません。（故に除算を書くと死ぬほど遅いので、乗算で代用したりする） また、浮動小数に対する演算ユニットを持っていないハードウェアもあります。ニンテンドーDSに搭載されているARM946E-Sですら、浮動小数演算ユニットはありません。（CPUの機能としてはオプションで存在する）そのために固定小数点といった技術もあるわけですが、古くさい話です。 これらはCとC++の機能を駆使していかにパフォーマンスを出すかを余儀なくされた時代です。 さておき、最近はスマートフォンでのゲーム開発も進化しており、C++がiPhoneとAndroidの両方で動くということもあ
ネイティブ開発アンチパターン - 神様なんて信じない僕らのために
ということで、最近はC++触ったりObjective-C触ったりJava触ったり、Lua触ったりしているわけですが、cocos2d-xに関してgumi Studyで話しました。とはいっても、中身は殆どcocos2d-xに関係ありません。 割と当たり前のことしか書いてないのですが、コンシューマゲームでも踏んだ「基本的な罠」について書いてあります。 cocos2d-xを触っていると、かなりの人たちがC++を知らずにC++を書いているという現実に出くわします。そういうとき「動いているから」で突き進むのではなく、１度止まって、自分がそれを理解しているのかを考えて見てはどうでしょうか。 ネイティブ開発アンチパターン from Isoparametric !
Boost.勉強会#4で「ゲーム開発のC++」を話してきました - 神様なんて信じない僕らのために
とりま、 アップロードしました。 スタッフの皆さん、参加者の皆さんお疲れ様でした。 アキラさんには直前まで資料作っていてご心配をおかけいたしました。orz... Boost study#4View more presentations from Isoparametric !.
Python Hack-a-thon 2010.07で「本当にあった怖い話」をしてきました - 神様なんて信じない僕らのために
土曜日のPython Hack-a-thon 2010.07で「本当にあった怖い話」をしてきました。 会場を提供してくださったオラクルさん、 そして、スタッフの皆さん、色々準備ありがとうございました。 また、参加者の皆さんお疲れ様でした！ （レポートは別途書きます） で、俺のプレゼンは完全にネタなので、ご了承ください。（特にC++erの皆さん） 前半は前振りなので、あまり気にしないでください。 プレゼン中で某C++な人達の写真や、Twitter発言が引用してありますが、 もし問題があればお知らせください。 「ソースを読もう」とか意味ないですので飛ばすの推奨。 また、なんか話したいなあ。 C++の話（本当にあった怖い話）View more presentations from Isoparametric . あと、プレゼン中で「C++の設計と進化」を勧めていますが、 C++のことわからないと
面白かったので怖い話の反応に反応してみる - 神様なんて信じない僕らのために
id:Dr_Caligariさんから面白い反応があったので、 俺も思ったことに対してつらつら反応してみます。 普通にコメントしようと思ったのですが長くなったのでTB返しで。 私が書くのはゲーム業界のプログラマーという狭い世界で生きている人間が思った事 ということで、俺もゲーム業界の片隅で生きていた事はあるのでその観点で反応してみます。 ディレクトリ構成が機能単位でなくプログラマの名前幽霊 これ実際に見たことあります。 アセンブラを使っていて、プロジェクトの規模が小さかった時代の名残らしいです。 恐らく俺が見たプロジェクトもアセンブリの頃の名残でした。 プロジェクト管理とかソース管理という構成管理の概念がなかったころなら、 別に良いとは思うのですが、今でもこれを引き継いでいてこれを「本気で」良いと思っている人がいることが恐ろしくもあります。 バージョン管理システムを使わない幽霊 そろそろ分散
2010-01-23 - 神様なんて信じない僕らのために
ということで、とりあえずスライド紹介。 PythonなのにLua！ PythonなのにLua！ いや、本当になぜPythonでLuaなのか訳がわかりませんが、 #1, #2とデスマってて約束が果たせなかったのでやっと果たして参りました。 基本的な機能に関しては網羅しているような感じではありますが、 実際には駆け足で抜けもあるので何かあれば質問してもらえれば解る範囲で答えられるかもしれません。 というか機能網羅する必要ないよな、という気もしつつ、速度とかサイズだけ語ってもLuaはLuaたりえないので なるべくLuaっぽいところを話したつもりでする。 最速の言語Lua ~Python Hack-a-thon #3~View more documents from Isoparametric. 最速の言語と銘打ってますが、実際にはPawnというもっとミニマムで高速な言語があったりします。 が、実
配列をポリモルフィックに扱ってはいけない - 神様なんて信じない僕らのために
元々は 今日の仕組まれたバグ こちらを見たときにずっと書こうと思っていたネタです。 num が 1 の状態でしか確認されてなくて、いざ使うことになって2以上にした途端に Segmentation fault するとか嫌がらせだろｗ ただの凡ミスなんだろうけど、なんかテストに出そうな問題だなーとか思ったのでネタにしてみた。 これ、ほぼバグになるんだから警告ぐらい出てくれてもいいのに、と思わなくもない。配列 new とアップキャスト。こんなにシンプルなアップキャストでメモリを壊そうとできる言語ってそうは無いよなーｗ これだから C++ 大好きだｗｗｗ C++はどうしてもメモリに依存するところが大きいのと、 クラス情報が最小なので致し方がないところではありますが、 こういうのは警告でても良いよね、と自分も思います。（PODでないクラスを見極めて！ で、このバグの面白いところ（嫌なところ）は「うま
クラスをSTLコンテナにいれると恐ろしい事が起こるぞ！ - 神様なんて信じない僕らのために
C++に慣れている人にとっては考えもつかないことですが、 クラスをコンテナにいれる、ということを試したくなる時期があります。 コンテナにクラスのポインタをいれるとポインタ管理が面倒だし、 クラスの実体をいれておいたら便利じゃない？ というのがその発端です。 さて、クラスはコンテナにいれてもいいものなんでしょうか？ じゃ、やってみましょう！ C++ code - 32 lines - codepad 予想と違う結果がでたぞ！！！ と思いませんか？ なぜデストラクタが呼ばれる回数が想定より多いのでしょう？ そして、コンストラクタの呼び出される回数とデストラクタの呼び出される回数が一致していません。 むむ？ 訓練されたC++はここであることに気付きます。 「vectorが拡張されている時に恐ろしいことが起きているのではないか？」 では、やってみましょう。 拡張されないようにreserveです。
STLのqueueとかstackとかが好きになるたった一つの方法 - 神様なんて信じない僕らのために
全国1,000,000人のSTLファンのみなさんに朗報です。 STLのqueueとかstackとか使いにくくないですか？ あれって、中身はlistとかqueueとかvectorのくせに使いにくくないですか？ 触れるインターフェイスが少なすぎ、とか思ってないですか？ 渡したコンテナを触れないときどうしてますか？ １．渡すコンテナを独自で作成し、インターフェイスは実装し中身は気合いでいじる できますが、queueやstackで渡されるコンテナは「コピー」なので相当醜いことになります。却下。 ２．queueやstackをprotected継承してインターフェイスを拡張する 正解！！ 移植性はないけど正解！！ 移植性がないのはSTLには環境によって独自の実装があるからです。 しかし、多くの場合ちょっと書き換えるだけでこのテクニックが使えます。 これを使うと、 swapができるqueue（シュリンク
STLのvectorに文句を言わずに自分で頑張る方法 - 神様なんて信じない僕らのために
１．自分でvectorを書く 死亡フラグ。／(^o^)＼ イテレータも使えないカスコンテナができる可能性99.9%。 今すぐ死んだ方が良い。 ２．STLのvectorをprotected継承してカスタマイズする 例えばこんな感じ。 C++ code - 40 lines - codepad これは最初からreserveしておくSTLのvector、インターフェイス制御可。 これをすることで、例えばpush_backの際にcapacityが変化したか、といったような事を監視できるし、 （ただし、insertなどのメソッドでもcapacityは変化する） 使わせたくないインターフェイスを公開しない、という事もできるし、 HogeList().swap(hogeList_); といったようなswap技法によるクリアや、 HogeList(hogeList_).swap(hogeList_); こ
インターフェイスについて深く考えたり、定量化を考えたりする - 神様なんて信じない僕らのために
ために、この２つの本を読むべき。 誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書) 作者: ドナルド・A.ノーマン,D.A.ノーマン,野島久雄出版社/メーカー: 新曜社発売日: 1990/02メディア: 単行本購入: 29人 クリック: 807回この商品を含むブログ (267件) を見る ヒューメイン・インタフェース―人に優しいシステムへの新たな指針 作者: ジェフラスキン,Jef Raskin,村上雅章出版社/メーカー: ピアソンエデュケーション発売日: 2001/09メディア: 単行本購入: 11人 クリック: 457回この商品を含むブログ (59件) を見る ソフトウェアのインターフェイスのデザインについて真剣に考えたことある？ なんとなく、感覚で良い、悪いを決めていない？ 好みは入っていない？ 好き嫌いはない？ インターフェイスに定量化の概念を持ち込んでる？
勉強会やりたいよー - 神様なんて信じない僕らのために
で、最後にデザインパターンの存在自体を紹介して、もっと勉強したけれは オライリーの HeadFirstデザインパターン で独習してね、と生徒に丸投げして終了です。（手抜きだなぁ） 我が家のOOPの研修 - みねこあ みねこあさんのこの勉強会に憧れを抱きます。 某所で勉強会が必要だというと、勉強をすべきは小手先のワザだったりで 恐れを感じます。 ……ということで、この記事に影響されて読みました。 Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本 作者: Eric Freeman,Elisabeth Freeman,Kathy Sierra,Bert Bates,佐藤直生(監訳),木下哲也,有限会社福龍興業出版社/メーカー: オライリージャパン発売日: 2005/12/02メディア: 大型本購入: 9人 クリック: 271回この商品を含むブログ (85件) を見
俺はこの本を楽しみにしていましたよ - 神様なんて信じない僕らのために
きじねこの高木さんの本です。 http://www.kijineko.co.jp/node/444 組込み現場の「C++」プログラミング 明日から使える徹底入門 作者: 高木信尚出版社/メーカー: 技術評論社発売日: 2009/03/23メディア: 単行本購入: 3人 クリック: 16回この商品を含むブログ (10件) を見る いやはや、これをどういったら良いのでしょう？ C/C++で組込をやっている人は必読であり、 そうでない人には全く用事がないという、そんな本です。 自分が特に良いなと思ったのは、 例外を有効にしている際に、組込環境にとってどのような影響があるかということ。これはでかい。 例外なんて切っちゃえ、と思っている自分ですが、 例外を適切に使えるなら例外は正義です。 しかし、大抵の人が使いこなせません。使いこなせないなら、使わないでおくのが正義というものです。 例外の他にも、C
途中でreturn編 ちょっとりふぁくと - 神様なんて信じない僕らのために
とりあえず、関係のないところでつっこまれたのでちょっとりふぁくと。 あー、やっぱり。予想通り「ながら」処理の典型的なのが出てきました。「ながら」処理というのは複数の事を一度に実行しようとする実装です。 「ステータスを変更する必要があるかどうか？」を判断しながら「遷移先のステータスを決め」ながら「ステータスを変更する」という。わかりやすく言えば、一輪車に乗りながら頭にボールを乗せてバランスを取りながら焼きそばを食べるという必要性がほとんど説明できないコード。 困った事にC言語系だとこれが普通なんですが、こいつが多くのメンテナンス不能なコードとバグを生み出しているフリーザ級の悪の親玉。 http://d.hatena.ne.jp/y_nakanishi/20090123/1232728337 codepad それはそれでいいとして、 nextのStateの決定を処理するところは残る。 で、「途
メンバ変数（インスタンス変数）の命名 - 神様なんて信じない僕らのために
職場で話題になったこと。 m_value mValue this.value(self.value) _value value_ value と色々あるわけですが、 世の中では 「m_ or mでメンバである事を明示する派」（m派） 「mは冗長だから_だけで表すよ派」（接頭辞アンダースコア派＝マーチン・ファウラー派） 「言語機能に乗っ取ってthisつけて表すよ派」（this派） 「前置_は言語処理系に予約されている（c/c++）ので後置_にするよ派」（接尾辞アンダースコア派） id:nattowさんの指摘で追記。 「つけないと区別できないのは設計がまずいから俺はつけないよ、てか接頭辞も接尾辞もきもいよ派」（設計上正しければ区別必要ないよ派） がいるような気がします。 （Rubyの@派とかは知らぬ） で、割と最近「後置_派」（C++ Coding Standardsの影響）になったんですが、
静的よりも無名、グローバルインスタンスよりグローバル関数 - 神様なんて信じない僕らのために
最近、やっと意識していること。 static HogeManager hogeManager_; ではなく、 namespace { HogeManager hogeManager_; } とする。 HogeManagerは静的でありたいわけではなく、 ファイル内アクセスをしたいだけに過ぎないから正当な機能である無名名前空間を使う。 （Cだとstaticにせざるをえないけど） Hoge* hoge = HogeManager::getInstance()->create(...); ではなく、 Hoge* hoge = ::CreateHoge(..); を使う。 Hogeをつくるために、 HogeManagerのインスタンスをグローバルにする必要はない。 関数で十分。 グローバル関数は悪ではないが、 グローバル変数は悪だ、という理念に従えばこれは当然の理となる。 CreateHogeの中
Cはワンマン向け - 神様なんて信じない僕らのために
だと考えるようになった。 いや、あくまで自分の中ではです。 今、Cで作られたものを参考にしてC++に移す作業をしていたりするんだけれども、 至る所に出現する、 void* コールバック 謎フラグ hoge->foo->bar->ptr ううーん。 これだけをして、ダメというのは何かもしれないけれど、 void*は至る所で何かに化ける。 根底にあるのは汎用ワークだからして、 その場その場で姿が変わる。 メモリマッピングとしてはそれが当然だからして当然なのだが、 型安全性とは真逆。 コールバック、 StateやStrategy風なことをしようとしてコールバックの嵐になるんだけれども、 あっちやそっちやこっちに飛んだりして遷移が読みづらい。 何でもかんでもコールバックで指定すりゃ良いってもんでもない。 謎フラグ、 至るところにあるhoge_flag & HOGE_FOO_BAR、 フラグの名前だ
Lua、Trac様々 - 神様なんて信じない僕らのために
Tracを色々とカスタマイズしながらぽちぽち。 SQL周りをきちんとするとレポートもかなり見やすくなるし、 JavaScriptで色々とやってあげると便利ということに気付いた。 Tracはいつも表示がださい、とか言われちゃうんで、 なんか考えないと、って感じでやっていて、 プラグインとかで色々とカレンダーいれたり、jsいれたりとかしてるんですが、 見た目はRedmineの方が良いよね、やっぱり。 ただ、Tracのカスタマイズ性にはかなり惹かれていて、 担当者がユーザ設定のフルネームにできるといいなあぁ、と日々探してます。 FlexibleAssignToPluginが良さそうなんだけど、どうもうまくうごかんのですよ。 担当者のドロップダウンを変える事はできるんだけれど、実際にPOSTすると担当者がassignされないとか。 http://trac-hacks.org/wiki/Flexib
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デストラクタがvirtualじゃないクラス、例えばvectorは継承しちゃだめなんだぞー！ - 神様なんて信じない僕らのために
突き進めればgotoは使わない機能になる - 神様なんて信じない僕らのために