id:Dr_Caligariさんから面白い反応があったので、 俺も思ったことに対してつらつら反応してみます。 普通にコメントしようと思ったのですが長くなったのでTB返しで。 私が書くのはゲーム業界のプログラマーという狭い世界で生きている人間が思った事 ということで、俺もゲーム業界の片隅で生きていた事はあるのでその観点で反応してみます。 ディレクトリ構成が機能単位でなくプログラマの名前幽霊 これ実際に見たことあります。 アセンブラを使っていて、プロジェクトの規模が小さかった時代の名残らしいです。 恐らく俺が見たプロジェクトもアセンブリの頃の名残でした。 プロジェクト管理とかソース管理という構成管理の概念がなかったころなら、 別に良いとは思うのですが、今でもこれを引き継いでいてこれを「本気で」良いと思っている人がいることが恐ろしくもあります。 バージョン管理システムを使わない幽霊 そろそろ分散

きっかけ。 元ネタ。 俺はVSSを使用しようというプログラマを信用しない。（と宣言しておく） 割と適当訳なのでご了承ください。 時々現れる、どのバージョン管理ツールをつかうのかという宗教的議論の中で、 私はマイクロソフトのVisualSourceSafeが一貫して叩かれている事に気付きました。 私はこれほどまでに憎悪を集めるような別のソフトウェアプロダクトを考えることができません。 私のプログラミングキャリアの日々では幸運なことに、svnを使う場所で働いていおり、さらに最近ではgitだったので、私はVSSを一度も経験したことがないということです。 VSSは本当に皆が主張するくらいに悪いものですか？ はい、そのとおりです！！ 私はgit、svn、cvs、tfs、及びvssを使いましたが、VSSは最も悪かったです。 それには、みんなで作業を分離するという概念が全くありません。 ファイルを操作す

このように数多くのプログラマが「車輪の再発明」の罠に悩まされているのですが，車輪の再発明（より正確に言うと，車輪の再実装）にはそれなりに意義もあります． 車輪の再実装 - Life like a clown id:tt_clownさんの反応に対してですが、 まず、自分も「車輪の再発明」ではなく「車輪の再実装」はすべきと考えます。 既にある機能を実装する事を「車輪の再発明」といって嫌う話もありますが、 実際にそれは「既にあるものを発明（新たに考える）する必要はない」という意味で 「既にあるものを実装する必要がないわけではない」と考えています。 自分は「車輪の再発明」と「車輪の再実装」は完全に異なると考えていて、 「車輪の再発明」で無駄に頭を悩ませる必要はないですが、 寧ろ「車輪の再実装」は非常に重要だと考えています。 ただ、「車輪の再実装」は習作でしかないことも多く、 習作は習作だということ

最近こんなやりとりがあった。 「Cって標準のコンテナ（双方向リストや可変長配列など）がなくて不便。 Cのプロジェクトってコンテナ自体ないこともあるし、コンテナがないとプログラムって書きにくいよね。 その点C++はSTLが(ry」 ... 「コンテナ？　STL“も”いいけど、自分で書きたい」 正直、自分は「え？　何を言っているんだ？」と思った。 STL“も”いいけど、“自分で書きたい”だって？ その人はプログラマとしては十年選手だが、C++に関して、特にテンプレートに関しては稚児に等しいレベル。 で、どうして「自分で書きたい」ということになるんだろう？ それを使わされる人の苦労はどうなる？ それともプロジェクトに同一の事をするための複数のコンテナが存在するのか？ 俺俺コンテナを書きたい理由はなんだ？ 要するにここにおいて「自分で書きたい」はSTLがよく解らないので、 機能や動きを隅々まで把握

なんだってー！！！！(；ﾟдﾟ） (ﾟдﾟ；（ﾟдﾟ；） いや、過言かもしれませんが、C++の存在がdlmallocを書く切っ掛けになったのは確かです。 dlmallocは現在はLinuxなどのデフォルトのmalloc実装ではありませんが、 dlmallocは本当に優れたアルゴリズムを持っています。 まずは「はじめに」の日本語訳を引用として載せておきます。（この記事自体は非常に古いもので現在のmallocの実装の詳細を反映してはいませんが、今なお使うに値するアロケータだと俺は信じますし、使っています） http://g.oswego.edu/dl/html/malloc.html はじめに メモリアロケータはソフトウェア工学のインフラにおける興味深いケーススタディを形成します。 私はそれを1987年に書き始めて以来、維持と発展に努めてきました。（これは多くのボランティアの方々の助けがあって

前のエントリで線形探索のメモリアロケータは駄目だ駄目だ、と言いました。 で、まず線形探索の何が駄目って、メモリは以下のようになっています。 最初は「未使用領域（青）」しかありません。ここからどう領域をとっても良いです。 ただ、使っていくうちに「使用領域（赤）」と「未使用領域（青）」の数珠つなぎになりがちです。 new/deleteの順番を意識すればこういったメモリの配置問題が解決できることもありますが、 実際には「クラスがメモリの状態に束縛される」とすると非常に面倒です。 なので、効率的なアロケータは必須なのです。 あなたが下のような断片化した領域をつなぐ双方向リストを持っていると仮定してください。 ここから効率よくメモリを探すことは絶対にできません。 ソートしておくといったことも考えられますが、ソートすると解放された領域のマージが困難です。 （freeされた隣接した領域はより大きなメモリ

前置き。dlmallocについて書くぞ！と言っておいて書いてなかったので。orz...すみません。 あろけーたをじぶんでかいてはいけません！！ なぜ、って大抵糞だからです。 例えば、こんな管理構造を持ったアロケータをよく見るんですが、 typedef struct _Allocator { unsigned char* pPool; // メモリプール int nPoolSize; // メモリプールのサイズ struct _SMemChain* pHead; // 番兵 struct _SMemChain* pTail; // 番兵 struct _SMemChain* pLast; // 最後に追加されたチェインタグ } Allocator; typedef struct _SMemChain { struct _SMemChain* pPrev; // 前のチェインタグ struct

C++に慣れている人にとっては考えもつかないことですが、 クラスをコンテナにいれる、ということを試したくなる時期があります。 コンテナにクラスのポインタをいれるとポインタ管理が面倒だし、 クラスの実体をいれておいたら便利じゃない？ というのがその発端です。 さて、クラスはコンテナにいれてもいいものなんでしょうか？ じゃ、やってみましょう！ C++ code - 32 lines - codepad 予想と違う結果がでたぞ！！！ と思いませんか？ なぜデストラクタが呼ばれる回数が想定より多いのでしょう？ そして、コンストラクタの呼び出される回数とデストラクタの呼び出される回数が一致していません。 むむ？ 訓練されたC++はここであることに気付きます。 「vectorが拡張されている時に恐ろしいことが起きているのではないか？」 では、やってみましょう。 拡張されないようにreserveです。

C++は厨二病なので、 テンプレートを憶えたてのプログラマはすぐに 「ぼくがかんがえたさいこうのはいれつ」を書きたがります。 STLがあるじゃん？ というと、使いにくいと言います。 で、ぼくがつかいやすいはいれつくらすをかきます、と言い出して配列を書き始めます。 これはほぼ九分九厘糞です。 でも本人はSTLより優れていると思っているんです。 微笑ましいですね。 よく見られる特徴。 イテレータがない そもそもiteratorの重要性を理解していない。故に用意する事をそもそも考慮すらしない。 メソッド名をSTLにあわせない STLを糞だと思っているので、メソッド名をあわせません。インターフェイスがむちゃくちゃです。 便利メソッドがたくさんある 突っ込みどころが満載な便利メソッドを追加してあります。おいおい。 immutableなメソッドをconst修飾しない そんなことは別にどうだって良いんだ

何を抽象化しようとして、 例えば、 非仮想関数を束ねて、例えば、 図形の ObjectSphere や ObjectBox、 はたまた、ObjectRenderXXXX なんかを統合して、 ObjectShapeとして、 メソッドにvirtualを付けて メソッドをインターフェイスに公開する時の違和感は異常。 要するに、こうすると基底にはできない操作を公開することになる。 これは継承方式としてあるまじき行為ですらある。 描画を行いたいものは沢山あって、 描画形状も様々なものがある。 要するに、単なる箱や球体から、 キャラクタの形状をしているもの、 はたまたビルボードなど。 これらに対して適切で統合されたインターフェイスをObjectShapeに集約すれば すべてのオブジェクトに対して可能である操作しかもたない役立たずクラスか、 可能ではない操作をObjectShapeに追加し神様クラスにな

STLは実装依存*1だし、 Boostだってうぎゃああああ、 RTTI？　exception？　そんなものまともに動くのかい？ boostをincludeしたらRTTIがdisableで怒られる！ exceptionがdisableで怒られる！ ああああああ、.textはもう一杯だ。 だって、templateで似たようなコードが型の違いで.textにたくさん落ちるから！ メモリだって空いてないよ。空いてないよ？ ヒープもスタックも一杯だ！ 多重継承？　だってInterfaceはないんだよ！！ 単一継承のC++なんて死んでしまえ。 virtual継承だってなんだってやってやろうじゃないか！ Observer？ Command？ State、Strategy、Factory、えとせとらえとせとら、 Cでまともにこれらを書ける人がどれだけいるんだろう。 型安全はどこいった、 ジェネリクス！　ジェ

んなわきゃねー、 きちんと動いているようなもののソースをみてみると こいつバカじゃないのか、なんていうコードが眠っている。 なぜ、こんなことになってる？ 愛だ、愛が足りないんだ！ 動く物をつくれるからといって、 その人間がプログラマとして優秀だとかまともだとか、 そういうことはないなと思うような事があって、 うーん、と唸っている。 こういうことって当たり前だよね、 っていうことが出来ていないプログラマがいて、 しかも、そのプログラマは後ろ足で砂をかけるような行為を平気でしたりする。 fuck you くたばれ。 自分は前の腐ったプロジェクトから解放されて スタートダッシュからギロチン台、というプロジェクトだが、 メインプログラマとして、自分の好きにできるのは楽しい。 好きにできる、というのは勿論、独裁ではなくて、 ある程度みんなの考えた好きなように、っていう感じでできるのが楽しい。 思いつ

にいってきました。 今回は良くも悪くも、 「C/C++へのLua組み込みの実践」は Luaっていうのはどんなものなんだろう？ と思った人向けになっていたと思います。 本を既に読んだ人にとっては目新しい事はなかったですが、 これを機に採用事例が増えれば良いなと思いました。 会場にはプログラマが沢山でしたが、説得材料として動的リロードのところはいけると思います。 まぁ、動的リロードはLuaじゃなくても（言語ではなくてデータでも）できますけどね。^-^; 動的言語で型チェックが実行時であることの不安感をなくすには動的リロードによる即時チェックだと考えられるので。 個人的には 「コンシューマにLuaを適応したらこんな問題が起きた」 「ただし、こういうメリットもあり良かった」 「メモリやパフォーマンスチューニングはこうした」 なんてことが聴きたいですね。 実体験に基づいてくると絶対面白いと思うので！

が欲しい。 といつも思っているんだけれど、 なかなかそうはいかないのよね、というお話。 デバッグ用のメモリ確保ルーチンなどには、 そのメモリブロックが何の用途で使われているのかヘッダに記憶しておいたりする。 要するに、 new (__LINE__, __FILE__) Hoge(); みたいにnewの引数にそれと解るものを書いておく。そして、それをメモリの頭に隠しておく。するとメモリの把握に大変便利。 ただ、こんな書き方をみんなしたい訳じゃない。 めんどくさい。めんどくさい。かっこ悪い。だいたい、デバッグ時だけでいいんだ。わかるのわ。 じゃ、 #define new new (__LINE__, __FILE__) ？ こんなことをしたら、これは、 Hoge* hoge = new (buffer) Hoge(); なんてことをしたときに、 Hoge* hoge = new (666,"H

元々は、LinkedListとArrayListのメモリ効率のお話。 ArrayListとLinkedListのメモリ効率 - ori’s diary 404 Not Found メモリ効率というと通常、「メモリ空間をどれだけ占有するか？」というイメージで捉えられると考えられるため、 ArrayListが効率が良い筈。 （LinkedListはprevや、nextを持ち、要素を指すための新たなクラスをnewしているため） で、 問題は、odzさんが ArrayList より LinkedList のほうがメモリ効率が良いなんてことは多分ない。 STL の vector と list なら list のほうが効率が良いこともあるかもしれないけど。 なぜかはちょっと考えてみると良い。 ArrayList と LinkedList - odz buffer なんておっしゃっていること。 いやあ、

だと考えるようになった。 いや、あくまで自分の中ではです。 今、Cで作られたものを参考にしてC++に移す作業をしていたりするんだけれども、 至る所に出現する、 void* コールバック 謎フラグ hoge->foo->bar->ptr ううーん。 これだけをして、ダメというのは何かもしれないけれど、 void*は至る所で何かに化ける。 根底にあるのは汎用ワークだからして、 その場その場で姿が変わる。 メモリマッピングとしてはそれが当然だからして当然なのだが、 型安全性とは真逆。 コールバック、 StateやStrategy風なことをしようとしてコールバックの嵐になるんだけれども、 あっちやそっちやこっちに飛んだりして遷移が読みづらい。 何でもかんでもコールバックで指定すりゃ良いってもんでもない。 謎フラグ、 至るところにあるhoge_flag & HOGE_FOO_BAR、 フラグの名前だ

きむら(K)さん経由！ What makes a bad programmer? I work with about 30 developers and everyone has strengths and weaknesses, but I can't say that any of them fall into that "bad" programmer category. So what really makes a bad programmer? 404 Not Found 何が悪いプログラマを作るんだろうね、というお話。 皆に長所と短所があって、そのどれが悪いプログラマをカテゴライズするためのもの、 ということができないですよ、と。 で、じゃ、何が悪いプログラマを作るんでしょうね？ それによる幾つかの定義。 プログラミングに対して情熱的ではない 詳細に注意を向けない ユーザーが何

全く気付いてなかったので、細々と。 多分、悪い人間じゃなければ何をしても良いって訳じゃないんだよねえ、きっと。 凄い行動力があるんだなあ、っていうのは解るんだけれど、 例えば、 もの凄い行動力のあるプログラマで、でも基礎知識はしっかりしてない、っていう人が 自分のプロジェクトの中にいて、 自分のソースを凄い勢いで無茶苦茶なソースコードに書き換えていって、 それでも表面上は動いている、 以前より動くようになった、 みたいになったとき、 それを応援したりすることができるか、ってことなのかなぁ、とか思った。 自分はできないし、 しかるべき対処をすべきだと考える。 ここでいうプロジェクトを世界に拡大したら、どうなる？ ってことを考えた。 まぁ、事は収まったようなので単なるつぶやき。

Javaは良い言語であった。*1 登場時のJavaは WORA（Write once, run anywhere）を体現しWeb向け言語としてもプログラマ達に夢を見せた。 今見てしまえば冗長で可読性の低いC系構文に 糞のようなクラス構文とゲロのようなインターフェイス構文であるが それでも当時はセンセーショナルだった。 しかし、その後、Javaには悲劇が起きる。 あまりにもセンセーショナルなデビューのおかげで それを金に換えようとしている奴らに目を付けられてしまった。 人月計算とExcelとスーツで出来ている奴らだ。 奴らは、 Javaをいかに簡単であるか宣伝し、 役に立たない講習会で金を取り、 再帰やポインタが何なのかすらわからない人間を大量に生み出した。 そうやって生み出されたJava脳人間は 「動くコードが正義」の負の面を体現し スパゲティを更に絡ませたclassとinterfaceを

ある程度経験を積んだC++プログラマは絶対にvirtualデストラクタのないクラスを継承しない C++では基底クラスにvirtualデストラクタを書こう - ＊「ふっかつのじゅもんがちがいます。」withぬこ はよくある間違い。あるいはC++初心者の勘違い。 継承する可能性のあるクラスにはすべてvirtualデストラクタを作る C++では基底クラスにvirtualデストラクタを書こう - ＊「ふっかつのじゅもんがちがいます。」withぬこ ということが否定されていることは言われるようにEffective C++を読んでいればわかること。 C++では、コピー不可にするために以下のようなクラスを書いたりするが、 （コピーコンストラクタとコピー代入演算子を無効にする） class Uncopyable { protected: Uncopyable() {} ~ Uncopyable() {}