Visual Source Safeを使用するのは狂気の沙汰 - 神様なんて信じない僕らのために
きっかけ。 元ネタ。 俺はVSSを使用しようというプログラマを信用しない。（と宣言しておく） 割と適当訳なのでご了承ください。 時々現れる、どのバージョン管理ツールをつかうのかという宗教的議論の中で、 私はマイクロソフトのVisualSourceSafeが一貫して叩かれている事に気付きました。 私はこれほどまでに憎悪を集めるような別のソフトウェアプロダクトを考えることができません。 私のプログラミングキャリアの日々では幸運なことに、svnを使う場所で働いていおり、さらに最近ではgitだったので、私はVSSを一度も経験したことがないということです。 VSSは本当に皆が主張するくらいに悪いものですか？ はい、そのとおりです！！ 私はgit、svn、cvs、tfs、及びvssを使いましたが、VSSは最も悪かったです。 それには、みんなで作業を分離するという概念が全くありません。 ファイルを操作す
とある愚直のアロケータ - 神様なんて信じない僕らのために
前置き。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
Boost.勉強会#4で「ゲーム開発のC++」を話してきました - 神様なんて信じない僕らのために
とりま、 アップロードしました。 スタッフの皆さん、参加者の皆さんお疲れ様でした。 アキラさんには直前まで資料作っていてご心配をおかけいたしました。orz... Boost study#4View more presentations from Isoparametric !.
使いもしないのにC++のtemplateを毛嫌いする全ての人に - 神様なんて信じない僕らのために
C++AdventCalendarの記事です。 さて、 生配列使ってますか？ tr1::array（boost::array） 使ってますか？ 生配列使っていると答えた貴方、 →まず死ね。 はい、arrayが常識ですよね。 さて、とはいえ、 「テンプレートを使うと遅いしコードがでかいし」 「生配列が一番速いしコードが小さいし」 「なのでテンプレート禁止」 なんて話を聞くこともあるかと思いますが、 こういう事をいう人は大抵「テンプレートを書いたことがない」のに言ってます。 なぜか？ こういう人が本当に心配しているのは「テンプレートが肥大化すること」じゃないのです。 「テンプレートが書けないし読めないのを認めたくないからです」 多くはCの老害だからですが、そういう人は放っておいてC++な人はきちんとテンプレートを使いましょう。 だって多くのテンプレートのコードは大きくもなければ非効率でもないか
Python Hack-a-thon 2010.07で「本当にあった怖い話」をしてきました - 神様なんて信じない僕らのために
土曜日のPython Hack-a-thon 2010.07で「本当にあった怖い話」をしてきました。 会場を提供してくださったオラクルさん、 そして、スタッフの皆さん、色々準備ありがとうございました。 また、参加者の皆さんお疲れ様でした！ （レポートは別途書きます） で、俺のプレゼンは完全にネタなので、ご了承ください。（特にC++erの皆さん） 前半は前振りなので、あまり気にしないでください。 プレゼン中で某C++な人達の写真や、Twitter発言が引用してありますが、 もし問題があればお知らせください。 「ソースを読もう」とか意味ないですので飛ばすの推奨。 また、なんか話したいなあ。 C++の話（本当にあった怖い話）View more presentations from Isoparametric . あと、プレゼン中で「C++の設計と進化」を勧めていますが、 C++のことわからないと
自分の書いたソースには過去の自分の見識しかなく、先人の書いたソースには先人の見識がある - 神様なんて信じない僕らのために
このように数多くのプログラマが「車輪の再発明」の罠に悩まされているのですが，車輪の再発明（より正確に言うと，車輪の再実装）にはそれなりに意義もあります． 車輪の再実装 - Life like a clown id:tt_clownさんの反応に対してですが、 まず、自分も「車輪の再発明」ではなく「車輪の再実装」はすべきと考えます。 既にある機能を実装する事を「車輪の再発明」といって嫌う話もありますが、 実際にそれは「既にあるものを発明（新たに考える）する必要はない」という意味で 「既にあるものを実装する必要がないわけではない」と考えています。 自分は「車輪の再発明」と「車輪の再実装」は完全に異なると考えていて、 「車輪の再発明」で無駄に頭を悩ませる必要はないですが、 寧ろ「車輪の再実装」は非常に重要だと考えています。 ただ、「車輪の再実装」は習作でしかないことも多く、 習作は習作だということ
俺はこの本を楽しみにしていましたよ - 神様なんて信じない僕らのために
きじねこの高木さんの本です。 http://www.kijineko.co.jp/node/444 組込み現場の「C++」プログラミング 明日から使える徹底入門 作者: 高木信尚出版社/メーカー: 技術評論社発売日: 2009/03/23メディア: 単行本購入: 3人 クリック: 16回この商品を含むブログ (10件) を見る いやはや、これをどういったら良いのでしょう？ C/C++で組込をやっている人は必読であり、 そうでない人には全く用事がないという、そんな本です。 自分が特に良いなと思ったのは、 例外を有効にしている際に、組込環境にとってどのような影響があるかということ。これはでかい。 例外なんて切っちゃえ、と思っている自分ですが、 例外を適切に使えるなら例外は正義です。 しかし、大抵の人が使いこなせません。使いこなせないなら、使わないでおくのが正義というものです。 例外の他にも、C
mix or join（集団に溶けこめない人たち） - 神様なんて信じない僕らのために
以前に森博嗣の小説で見かけたこと。 欧米の集団の繋がりはjoinだが、日本の集団は「俺も混ぜてくれ」という言葉通り、mixなのだと言うこと。 これはとても印象に残っている。（出典となる小説は失念） 確かに欧米はjoinによって繋がっていくリンクリストみたいな感じがして、そのjoinの連鎖が数多く発生していて、最終的には複雑に絡み合ったチェーンみたいな気がしている。 これは、直接その集団に触れた訳ではないので思いこみも入っているだろうけれど、Webサイトにおける繋がりも欧米のコミュニティも、それらの人々が書く書籍にもそうした色が濃く現れているように感じる。チェーンの中をけたたましくエネルギが行き交う感じがして仕方がない。 そして、やっぱり日本はmixであって集団に溶けこむ事で個を失っていくというか、mixiのように繋がっていても集団の中で個は打ち消されていくような感じをうける。 自分が自分で
オレオレアロケータ - 神様なんて信じない僕らのために
newとかmalloc()した領域をひっくるめて保持しておいて、リクエストに応じて区別無くfreeでブチ殺すとか、何か使い道ないかなあ(まだゆーか) 404 Not Found 釈迦に説法かもしれませんが、 ありますよ、オレオレアロケータ！！（ドラえもんの声で） と、newは引数を使ってオーバーロードできるのでクラスに対してnew operatorとdelete operatorを制御することで、 一気にメモリを確保して、一気に解放できます。 static void* operator new( std::size_t size, CAllocator& allocator ) { と宣言して、自前のアロケータを指定してやればOKでございます。 書き方によっては暗黙で使っても良いです。使う人はそれを知ってないと駄目ですが。 for文で回しているところは、こういう感じに一気にとるならnew
STLのqueueとかstackとかが好きになるたった一つの方法 - 神様なんて信じない僕らのために
全国1,000,000人のSTLファンのみなさんに朗報です。 STLのqueueとかstackとか使いにくくないですか？ あれって、中身はlistとかqueueとかvectorのくせに使いにくくないですか？ 触れるインターフェイスが少なすぎ、とか思ってないですか？ 渡したコンテナを触れないときどうしてますか？ １．渡すコンテナを独自で作成し、インターフェイスは実装し中身は気合いでいじる できますが、queueやstackで渡されるコンテナは「コピー」なので相当醜いことになります。却下。 ２．queueやstackをprotected継承してインターフェイスを拡張する 正解！！ 移植性はないけど正解！！ 移植性がないのはSTLには環境によって独自の実装があるからです。 しかし、多くの場合ちょっと書き換えるだけでこのテクニックが使えます。 これを使うと、 swapができるqueue（シュリンク
もしかしてCの奴らは代入やキャストでポインタのアドレスが変わらないとか思っているのか？ - 神様なんて信じない僕らのために
class A { public: A (){} virtual ~A (){} }; class B { public: B (){}; virtual ~B (){}; }; class C : public A, public B { public: C (){} virtual ~C (){} }; int main() { C* c = new C(); A* a = c; B* b = c; printf("c:%p\n", c); printf("b:%p\n", b); printf("a:%p\n", a); delete c; return 0; } a,b,cが全て同じアドレスであると思っている奴はクソして寝ろ。 って、怖い人が言ってました＞＜
メンバ変数（インスタンス変数）の命名 - 神様なんて信じない僕らのために
職場で話題になったこと。 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の影響）になったんですが、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
