ある程度経験を積んだC++プログラマは絶対にvirtualデストラクタのないクラスを継承しない？ - 神様なんて信じない僕らのために
ある程度経験を積んだC++プログラマは絶対にvirtualデストラクタのないクラスを継承しない C++では基底クラスにvirtualデストラクタを書こう - ＊「ふっかつのじゅもんがちがいます。」withぬこ はよくある間違い。あるいはC++初心者の勘違い。 継承する可能性のあるクラスにはすべてvirtualデストラクタを作る C++では基底クラスにvirtualデストラクタを書こう - ＊「ふっかつのじゅもんがちがいます。」withぬこ ということが否定されていることは言われるようにEffective C++を読んでいればわかること。 C++では、コピー不可にするために以下のようなクラスを書いたりするが、 （コピーコンストラクタとコピー代入演算子を無効にする） class Uncopyable { protected: Uncopyable() {} ~ Uncopyable() {}
Boost.勉強会#4で「ゲーム開発のC++」を話してきました - 神様なんて信じない僕らのために
とりま、 アップロードしました。 スタッフの皆さん、参加者の皆さんお疲れ様でした。 アキラさんには直前まで資料作っていてご心配をおかけいたしました。orz... Boost study#4View more presentations from Isoparametric !.
使いもしないのにC++のtemplateを毛嫌いする全ての人に - 神様なんて信じない僕らのために
C++AdventCalendarの記事です。 さて、 生配列使ってますか？ tr1::array（boost::array） 使ってますか？ 生配列使っていると答えた貴方、 →まず死ね。 はい、arrayが常識ですよね。 さて、とはいえ、 「テンプレートを使うと遅いしコードがでかいし」 「生配列が一番速いしコードが小さいし」 「なのでテンプレート禁止」 なんて話を聞くこともあるかと思いますが、 こういう事をいう人は大抵「テンプレートを書いたことがない」のに言ってます。 なぜか？ こういう人が本当に心配しているのは「テンプレートが肥大化すること」じゃないのです。 「テンプレートが書けないし読めないのを認めたくないからです」 多くはCの老害だからですが、そういう人は放っておいてC++な人はきちんとテンプレートを使いましょう。 だって多くのテンプレートのコードは大きくもなければ非効率でもないか
PythonのWebフレームワーク使うなら知っておきたいデコレータ - 神様なんて信じない僕らのために
最近「ｵﾜﾀ＼(^o^)／」で有名なDjangoしか触ってないダメ人間です。 こんにちは。 Djangoとかどうでもいいがな、 Webフレームワークとかめんどくさいがな、 という最近なのでDつながりでDecoratorの話をします。 ナウでヤングなPythonistaのホットな話題はGCの参照カウンタ、 ではなくてFlaskとかかもしれないですが、 @app.route("/") def hello(): return "Hello World!" こいつも多分に漏れずDecoratorを使います。 Djangoでも、 @require_GET とか @require_POST とか使ったり見たことがあるんじゃないかと思います。 で、意外と魔法っぽいデコレータですが、 これっていったいどうなってんの？ って事を知らない人が割といたりします。 「とりあえず指定しろって言われたから指定してます
Visual Source Safeを使用するのは狂気の沙汰 - 神様なんて信じない僕らのために
きっかけ。 元ネタ。 俺はVSSを使用しようというプログラマを信用しない。（と宣言しておく） 割と適当訳なのでご了承ください。 時々現れる、どのバージョン管理ツールをつかうのかという宗教的議論の中で、 私はマイクロソフトのVisualSourceSafeが一貫して叩かれている事に気付きました。 私はこれほどまでに憎悪を集めるような別のソフトウェアプロダクトを考えることができません。 私のプログラミングキャリアの日々では幸運なことに、svnを使う場所で働いていおり、さらに最近ではgitだったので、私はVSSを一度も経験したことがないということです。 VSSは本当に皆が主張するくらいに悪いものですか？ はい、そのとおりです！！ 私はgit、svn、cvs、tfs、及びvssを使いましたが、VSSは最も悪かったです。 それには、みんなで作業を分離するという概念が全くありません。 ファイルを操作す
Visual Source Safeについてチェックしておきたい５つのTips - 神様なんて信じない僕らのために
こんなTB（）を戴いていたので。 別に VSS をディスル post じゃないです。お間違いなく。 ……ということでVSSを使う場合にチェックしておきたい５つのTipsです。 １．なんとしてもVSSを使わないようにしよう VSSは有料ですし、無料でさらに高性能なSubversionやGitがあるのでそちらを使いましょう。 できるだけVSSを避ける、というのが鉄則です。 ２．VSSを使っているふりをしてSubversion/Gitで管理しよう VSSをいれるように言われたらVSSで管理するふりをしてSubversion/Gitで管理して、 作業ツリーを適当にVSSにいれて誤魔化しましょう。 あたかもVSSで管理されているかのように見せかけることが大事です。 ３．VSSを強要されたらAdmin権限を得よう VSSにはAdmin権限を得ることでいくつかの設定を変えることができます。 （Visua
自分の書いたソースには過去の自分の見識しかなく、先人の書いたソースには先人の見識がある - 神様なんて信じない僕らのために
このように数多くのプログラマが「車輪の再発明」の罠に悩まされているのですが，車輪の再発明（より正確に言うと，車輪の再実装）にはそれなりに意義もあります． 車輪の再実装 - Life like a clown id:tt_clownさんの反応に対してですが、 まず、自分も「車輪の再発明」ではなく「車輪の再実装」はすべきと考えます。 既にある機能を実装する事を「車輪の再発明」といって嫌う話もありますが、 実際にそれは「既にあるものを発明（新たに考える）する必要はない」という意味で 「既にあるものを実装する必要がないわけではない」と考えています。 自分は「車輪の再発明」と「車輪の再実装」は完全に異なると考えていて、 「車輪の再発明」で無駄に頭を悩ませる必要はないですが、 寧ろ「車輪の再実装」は非常に重要だと考えています。 ただ、「車輪の再実装」は習作でしかないことも多く、 習作は習作だということ
returnはCommitで、throwはReset？ - 神様なんて信じない僕らのために
うーん、 returnをすることもthrowをすることも、 実際には上位に対して何らかの状態を伝えるために戻る、ということをするわけで、 bool File::open(const char* path) { if (!FileSystemOpen(&handle_, path)) { return false; } ... }はダメで、 bool File::open(const char* path) { if (!FileSystemOpen(&handle_, path)) { throw io_error_exception("IOError"); } ... }は良い、というのがいまいちわからない……。 例外は例外的な何かを呼び出し元に伝えるためにあるけれど、 戻り値を持つreturnは呼び出し元に戻り値を伝えるためにあるわけで、 別物ではあるけれど、returnはダメでthr
やはりCのポインタは難しいものだ…… - 神様なんて信じない僕らのために
ポインタと配列は一緒のもの？ 違うよ、全然違うよ。 前に、同じ年の人が一時的に今の職場に来て、C言語できる。というから、ポインタと配列の違いが解かります？って聞いたら 「え？ポインタも配列も同じじゃないっすか。」 と言われた。 そうだよね。理解してる人に取っては、特に何でもないものなんだと思う。 char szMsg1[]; char *szMsg2; という宣言があったら、 C言語のポインタを理解している人に取ってはszMsg1 とszMsg2 は同じ物じゃないだろうか？ なんか、前もこんな話があったような気がするけど、これらは全然違うよ。 少なくとも「ポインタ変数」は対象となる変数の場所（アドレス）を格納可能な変数であり、 「配列変数」は配列の領域を確保し、配列としての名前を持つ変数である。 ポインタは代入可能だが、配列名に対し代入することはできない。 また、配列は関数に渡すこともでき
メンバ変数（インスタンス変数）の命名 - 神様なんて信じない僕らのために
職場で話題になったこと。 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の影響）になったんですが、
!C言語知らない奴ってプログラマじゃなくね？ - 神様なんて信じない僕らのために
そういえばC言語を知らない人に 「C言語って文字列型がないんだよ」 と言ったら驚いていた。 確かにC言語は配列は自身の長さを知らないし、 文字列も自分の長さを知らない。 正規表現だって標準ではない。 僕はこれが当たり前と思うけれども、 そうでない言語から入った人は文字列型があるのが普通で 配列だって長さがわかるのは当たり前で、 正規表現だって使いたいし……、 「なんでそんな不便なの？」って思うだろう。 nativeなCはそれ自体が豊富なライブラリや機能を持つわけではないので 「新ANSI C言語辞典」を片手に何か作ろうとしても限度がある。 初心者がnativeなCで役に立つツールを作ろうとすることに既に無理がある。*1 まだプログラマに成り立てな人に簡単なGUIツールをつくって貰おうとしたとき、 「nativeCでつくって」とは口が裂けても言わないだろう。 実際C言語でやりたいことなんてい
つまらなくて役に立たない物を作るということ - 神様なんて信じない僕らのために
最速の人が何か書いていたのでこそっと書いておこう。僕はもうゲームプログラマではないけど。 Webで役に立つツールをつくれる人はみんなから「凄い」と言われることが多いような気がする。 ぶっちゃけゲームなんて役にたたないし、たぶん大部分のゲームは「誰か」にとって面白くない。 すべてのゲームプログラマが何万ポリゴンとか動かしたりしないし、 シナリオテキストをパースしたり、正規表現で構文解析したり、マップエディタをつくったり、パーティクルジェネレータをつくったり、そういうのが得意な奴もいる。 ゲームの人らがみんな秒間３億ポリゴン動かしてウハウハだなんて思わないでほしい。 ちまちましたことをやっている人だっているのだ。 なんでこんなちまちました敵のパラメータ設定や挙動のプログラムを組まなきゃならんのだ、とかどうしていちいちマップエディタとかシナリオスクリプトとかメニュー表示や挙動の制御を作らなきゃい
お前は実装の達人になってから現場に赴くのか？ - 神様なんて信じない僕らのために
元ネタはベルセルクの「お前は剣術の達人になってから戦場に赴くのか？」だったような気がしますが定かではありません。 多分、ガッツ（熟達の剣士）が未熟な剣を振るうイシドロ（未熟な剣士）に言った言葉。 要するに戦場に赴くのなら「お前はいまお前にできることをしろ」って事ですな。 似たような事を思う事が僕にもあって、 「本を読み鍛錬を積み重ねその知識を把握してからプログラムを書くべきか」 「ただ目の前にある実装を片付けるべく邁進すべきか」 と考えたりします。 仕事のコードでなくても、 休日でも時間があるときはコードを書こうか、 本を読もうか迷ったりするわけです。 要するに常に 適切な知識を身につけたり適切なコードを書けるようになってからコードを書くべきかや？ という葛藤があります。 反面、コードを書かずに成果を出さなければ意味はないよな、という思いもあります。 これは剣術でもそうですが、 ただただ何
プログラマに組織を正すことはできない - 神様なんて信じない僕らのために
最近はプログラマが組織に不満を抱いた場合に、 よし組織を改善しよう、と思ったとしても それは既に構築されていて稼働しているシステムのプログラムを常に動かしながらソースコードを変えていく行為の難易度に等しい、 のだな、という事を思った。 後ろ向きすぎる、ネガティブすぎる、と思われるだろうけれども、基本的に悲観的な人間であるので。 で、給与、待遇、といったものは常に「既にある組織」にはあるべくしてあるもので、 それらを自由に設定、交渉できる権限をプログラマは持たない。 なぜなら組織の決定や、組織の意志に逆らえないから。 で、 相応の給与を払ってもらえない、待遇を与えられない、 というような組織がある場合に実質的にプログラマが選びうる選択肢は 「改善」 「我慢」 「転職」 なんだろう、きっと。 「改善」はまさに前述のように手が出ない範疇がありえ、 かつまた即時効果はでることはない。 ないものはな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
