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_); こ
C++ Coding Standardsはどう述べているか、という蛇足 - 神様なんて信じない僕らのために
egtraさん曰く。（コメント欄 これに限らずデストラクタが非virtualな多態的に使うつもりはない基底クラスはコンストラクタ・デストラクタをprotectedにするのがよい（そしてunary_functionもそうすべきだった）ということは確かC++ Coding Standardsに書いてあったと思います。 std::unary_functionの存在意義がよくわからなくなった。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ 調べてみた。 50. 基本クラスのデストラクタは public 仮想か protected 非仮想にする 削除すべきか、否か。それが問題だ：基本クラス Base へのポインタを介した削除を許す場合は、Base のデストラクタを public 仮想にしなければならない。それ以外の場合は、protected 非仮想にする。 なるほど。 「あらゆる基本クラス
デザインパターンにまつわるエトセトラ - 神様なんて信じない僕らのために
社内でデザパタが盛り上がっていたので、社内勉強会でLTしました。 その資料です！ 基本的に自分はデザインパターンは「言語に依存しない設計に名前をつけたもの」だと定義しています。 なので、よくある「デザインパターンってJavaじゃないと役に立たないよね」なんていう意見には反対です。 勿論、言語によっては適応する意味の無いパターン、意味の薄いパターンもありますが、 GoFのパターンだけがすべてではないですし、 "設計に名前をつけて共有する"というスタンスこそが最高のものだと思っています。 （酒井姐さんは社内のエンジニアです） デザインパターンとは何か？ View more presentations from Isoparametric ! 最後でも紹介していますが、この本が超オススメです！ デザインパターンとともに学ぶオブジェクト指向のこころ (Software patterns serie
Effective なんとかを読めば良いというものではない - 神様なんて信じない僕らのために
何となく思ったこと。 なんとか、の話になったとき、 Effective なんとかを読まずになんとかは語れないとか、 やったとは言えないとか、まずは読むべき、とか色々と耳にしたりする。 かくいう自分も C++の本で何が良いと言ったら、 プログラムの経験がある人なら、Effective C++は勧める本の中に入ると思う。 ただ、この本を読んだからといって、 見違えるようにC++が書けるようになるわけでもない。 かといって、読まなくても良いかというとそうでもない。 そんなこといったら 「Exceptional C++」も読むべきだし、 「Exceptional C++ Style」だって読んで欲しいですよ、ですし、 「C++ Coding Standards」だって、ねえ。スタイルがさー。 いやいや、「Effective STL」は外せないでしょう、STL使わないってありえないし、 とか、ならな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
