std::(unordered_)map でメモリ使用量を見積もる - ny23の日記
以前，トライと STL コンテナの比較をした際，std::map, std::tr1::unordered_map についてはメモリ使用量をちゃんと測っていなかったが，都合により，コンテナ本体のメモリ使用量を見積もる必要が出てきたので gcc 4.7 の実装を眺めてみた． 結論から言うと，gcc では std::map <_Key, _Tp> のメモリ使用量は， template<typename _Val> struct _Rb_tree_node { _Rb_tree_color; // ノードの色 (enum; int) _Base_ptr; // 親ノードへのポインタ _Base_ptr; // 左ノードへのポインタ _Base_ptr; // 右ノードへのポインタ _Val; // value_type (std::pair <const _Key, _Tp>) }; -> si
査読における不採録コメントの取り扱いの難しさ - ny23の日記
2月に入ってから一週間の間にジャーナルの再査読3件と論文の締切りが重なってやや忙しかったが，今日やっと全てを片付けて一段落した．今回は再査読なので本当は一回目の査読より楽なはずなのだけど，実際には一回目より大変な査読になった．その一番の理由は不採録としたコメント（2件）の取り扱われ方（今回は両方とも再査読することになった）． 一つのジャーナルではそれがそのまま著者に渡ってしまっており，著者らは対応しようと苦慮しているのだけど（不採録コメントでは単に問題点を指摘しているだけで，どう直せば良いか具体的な方針を示していない項目もあって）十分に対応できているとは言えない箇所も多く，そのまま再査読するなら不採録（か良くて照会後判定）とせざるを得ない．ただ，不採録コメントに直接対応しようとすること自体にそもそも無理があって，これで採否を判断するのは忍びないと感じる．再査読に回すのであれば（採録のための
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
