shared_ptrまとめ - while( c++ );
日本語ドキュメントshared_ptr、weak_ptr boost勉強会http://www.ustream.tv/recorded/2981654 Smart Pointer Programming Techniques 実装してみた shared_ptrの実装1 - while( c++ ); shared_ptrの実装2 - while( c++ ); shared_ptrの実装3 - while( c++ ); shared_ptrの実装4 - while( c++ ); boost::shared_ptrっぽく。 shared_ptrの実装5 - while( c++ ); shared_ptr< void >を可能にする。 shared_ptrの実装6 - while( c++ ); 適当なクラス図とか。 shared_ptrの実装7 - while( c++ ); dele
今更ながらに Boost.SmartPointers を考える - 野良C++erの雑記帳
Smart Pointers というか主に shared_ptr ですが（scoped_ptr のこともたまには思い出してあげてね！）。 恐らくは散々ｶﾞｲｼｭﾂなネタですが、まー「検索するのが面倒だ」って人の手助けになればいいかと思います。僕も検索するの面倒ですし。 というかこの記事書いてるときもロクに検索してないです。間違いとかあったらすみません。 疑問点とか有りましたら、自分で調べるか、あるいは僕に知らせてもらえると助かります。では、始めましょう。 [最終更新] 応用例にカスタムアロケータでの参照カウント管理を追加: 09/12/16 基本的な使い道 まず基本的なことについては、僕が説明するより、この動画を参照した方が速いでしょう： http://www.ustream.tv/recorded/2981654 それに対するついったーでの突っ込み： http://kiwofusi.sa
メモリ破壊の現場を見つけるTips - I am Cruby!
RubyAdventJP, GC, Ruby（この記事はRuby Advent Calendar jp: 2009 : ATNDの4日目です。前日はmrknさんでした） 健全なるRubyistであれば、RubyのGCをいじることが週に一度はあるでしょう。そのときに困るのが、GCをいじってしまったことによるバグの修正です。GCをいじるというのは想像以上に難しく、少しでも書き間違えるとメモリ破壊が発生します。そのときに使えるTipsをこの記事で書くことにします。 みなさんご存じの通り、メモリ破壊というのは原因を特定するのが困難です。これは問題が発覚する場所とメモリ破壊が起こった現場が位置的に遠いことに起因しています。偉大なるハッカーのまつもとさんですら、その発見は困難です。 [ruby-dev:38628] Re: [BUG: trunk] called on terminated objec
オレオレアロケータ - 神様なんて信じない僕らのために
newとかmalloc()した領域をひっくるめて保持しておいて、リクエストに応じて区別無くfreeでブチ殺すとか、何か使い道ないかなあ(まだゆーか) 404 Not Found 釈迦に説法かもしれませんが、 ありますよ、オレオレアロケータ！！（ドラえもんの声で） と、newは引数を使ってオーバーロードできるのでクラスに対してnew operatorとdelete operatorを制御することで、 一気にメモリを確保して、一気に解放できます。 static void* operator new( std::size_t size, CAllocator& allocator ) { と宣言して、自前のアロケータを指定してやればOKでございます。 書き方によっては暗黙で使っても良いです。使う人はそれを知ってないと駄目ですが。 for文で回しているところは、こういう感じに一気にとるならnew
malloc(0)の話 - Hello, world! - s21g
malloc(0)の戻り値は、NULLもしくはサイズが0のメモリ領域へのポインタのいずれかとなっています。どちらが帰ってくるかは処理系に依存するので、一見malloc(0)を使うとプログラムの移植性を損なうような気がします。 しかし、mallocで確保された領域を realloc や free で操作する場合、reallocもfreeもいずれも、サイズが0のメモリ領域へのポインタに対する操作とNULLポインタに対する操作を許容するので、実際には問題ありません。
C(++)言語: valgrindの使い方 (memcheck)
(2-1) Memcheck: メモリエラーを検出する Memcheckが検出出来るエラーには以下のようなモノが有る。 メモリリーク 初期化されていない値の使用 freeされた領域へのアクセス mallocされた領域より後の領域へのアクセス 不正なスタック領域へのアクセス malloc/new/new []とfree/delete/delete []の対応の不一致 memcpyでsrcとdestの領域が被っている (2-1-1) Memcheck: メモリリーク static char *s; void leaking(void) { s = (char*)malloc(100); s[0] = 'a'; } int main(void) { leaking(); leaking(); leaking(); } ==29024== LEAK SUMMARY: ==29024== defin
operator newとoperator deleteを書くときは規約を守ろう 8項 - higepon blog
operator new を自分で作成するならば、いろいろ約束を守ろうという話。 自分もMonaでなんとなく new をユーザーランド向けに実装しているが以下のルールを一部守っていない気がする。 newのお約束 0byteの要求に対しても正規のポインタを返さなければならない(実装例では0byte要求は1byte要求として扱っている) エラー処理関数を呼ばなければならない std::bad_allocを投げないといけない Monaは例外をサポートしていないので今のところ無理p deleteのお約束 NULLポインタのdeleteを安全に行わせる。 つまりこれは よく見かけるコード if (somePointer != NULL) delete somePointer; は これでよい delete somePointer;ということになる。 追記: Monaのユーザランドで、newの0割り当
#perl - $Config{usemymalloc} : 404 Blog Not Found
2009年10月16日00:30 カテゴリLightweight Languages #perl - $Config{usemymalloc} それを返さないかは、その perl が受胎(conceive)したとき、平たく言えばどうConfigureされたかによって決まります。 Perl5 doesn't release SV's memory - SVアリーナのメモリ領域確保は一度おこなわれたら、「もう一生離さないぜ」な件 - TokuLog 改めB日記 Perl5 はメモリプールをもってる」ってのは、Perl Monger なら誰でもしってるわけですが、30MB とか領域確保したら、それはプールしないで、すぐ返すだろ JK とおもってたら、返してなかったので、それについて調べたときのメモ。perl がメモリーを返してくれるかどうかは、以下の簡単なscriptでチェックできます。 use
グーグルの研究が示すメモリエラーの真実--明らかになった高い発生率
どうしてまたコンピュータがクラッシュしたのかと不思議に思ってはいないだろうか。Googleの実環境での研究によれば、それはメモリが原因かもしれないという。この研究では、メモリのエラー率が、これまでの研究で示されていたよりも高いことが分かった。 Googleは、同社のデータセンターにある膨大な数のコンピュータを使って、それらのマシンの実際の稼働状況についての実環境データを大量に収集することができる。それがまさに、エラー率が驚くほど高いことを明らかにした研究論文のために、同社が行ったことだ。 トロント大学教授Bianca Schroeder氏と、GoogleのEduardo Pinheiro氏ならびにWolf-Dietrich Weber氏の共著である同研究論文によれば、「メモリエラーの発生回数や、さまざまなDIMMにおけるエラー率の範囲が、以前報告されていたよりもずっと高いことが分かった。メ
クロージャの解放 - Pixel Pedals of Tomakomai
gist落ちてるのでここにメモ。 package DONE1; sub DESTROY{ warn 'd1:', shift; } package DONE2; sub DESTROY{ warn 'd2:', shift; } package DONE3; sub DESTROY{ warn 'd3:', shift; } package DONE4; sub DESTROY{ warn 'd4:', shift; } package DONE5; sub DESTROY{ warn 'd5:', shift; } package main; use strict; use warnings; use Scalar::Util; my ($inner, $outer); { my $d1 = bless {}, 'DONE1'; my $d2 = bless {}, 'DONE2'; b
第8回 Windowsの仮想メモリーを見てみよう
「仮想メモリー」をご存じですか？ ハードディスクの一部をメモリーとして使うことで，メモリー（物理メモリー）の不足を補う仕組みです。 仮想メモリーの仕組みは，OSが提供してくれます。したがって，私たちがプログラムを作るときには，仮想メモリーを意識したコードを記述する必要はほとんどありません。もしも，メモリーが足りなくなったら，Windowsがメモリーの一部をハードディスクに移して，メモリー空間を空けてくれるからです。 Windowsさんありがとう！ などとお礼を言って終わりでは，ちょっともの足りない気がします。仮想メモリーが実際にどんなものか，一度は見ておきたいですね。今回は，仮想メモリーに関する実験をやってみましょう。 最初にちょっとだけお勉強 実験を行う前に，仮想メモリーの勉強をしておきましょう。仮想メモリーには，大きく分けて二つの方式があります。「セグメント方式」と「ページング方式」で
glibcの脆弱性で大量のメモリが割り当てられる – セキュリティ専門家は基盤ソフトウェアに期待させてはならない
(Last Updated On: 2016年2月18日)最近この種のエントリがありませんでしたが、個人的に面白いとセキュリティ系の話題はできるだけ書いていきたいと思っています。 glibcのstrfmon関数の実装に脆弱性があり、簡単なスクリプトで大量のメモリが割り当てられる脆弱性があるようです。影響するglibcは2.10.1以下なので影響範囲は非常に大きいです。 最初はBSDのlibcで脆弱性が発見され、glibcでも影響があることは脆弱性の発見者には分かっていたようです。詳細はアドバイザリに記載されています。 http://packetstormsecurity.org/0909-advisories/glibc-format.txt 参考：セキュアプログラミングの７つ習慣 詳しい説明はアドバイザリを読んで頂くとして、当初はBSD系OSのglibcで問題が発見されたそうです。Net
CとC++の動的メモリー管理（1）、malloc関数とnew演算子の違いを知る | EE Times Japan
C言語とC++言語では、動的にメモリーを確保したり解放したりする手法は異なり、それぞれ長所と短所がある。もちろん、安全性を最重要視する組み込み機器では、動的に確保したメモリーを利用すべきでないという考え方には心から賛同する。リスクが利点を上回ってしまうからだ。しかし場合によっては、動的なメモリーを適切に管理することで改善できることも多いのではないかとも考えている。 C言語やC＋＋言語に標準的に用意されているメモリー管理向け関数の動作が意図した通りでない場合は、メモリー管理関数を独自に開発するとよい。独自のメモリー管理関数の仕様と振る舞いは、できる限り標準関数と同じにすることが理想である。標準関数のメモリー管理方法と違ってしまう場合でも、関数の引数と返り値の数と型は、可能な限り標準関数にそろえるべきである。関数の仕様を同一にしておくことで、最初は標準のメモリー管理関数を使って開発し、必要に応
malloc関数の使い終わった後の開放について
malloc()はOSからメモリを借用するのではなく、malloc()用に確保された大きなメモリブロックから、要求されたサイズの小さなメモリブロックを切り出す関数です。 free()は「小さなメモリブロックを再利用可能な状態にする」という関数でOSに対して何か影響があるような関数ではありません。 プログラムが終了するとき、malloc()用に確保してある大きなメモリブロックは全て適切に処理されます（どう処理されるかは処理系依存です）。 よって、プログラム終了のときはmalloc()済み、malloc()待ちに関わらずゴミのメモリブロックは残りません。 これはANSI-Cのライブラリ仕様ですからmalloc(),realloc,calloc()とfree()の関連でのみ成立します。 その他のメモリ関連関数/APIでは、プログラム終了時に断片化されたメモリブロックが起こってしまう可能生がありま
Manpage of MMAP
Section: Linux Programmer's Manual (2) Updated: 2008-06-05 Index JM Home Page roff page 名前 mmap, munmap - ファイルやデバイスをメモリにマップ/アンマップする 書式 #include <sys/mman.h> void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset); int munmap(void *addr, size_t length); 説明 mmap() は、新しいマッピングを呼び出し元プロセスの仮想アドレス空間に作成する。 新しいマッピングの開始アドレスは addr で指定される。マッピングの長さは length 引き数で指定される。 addr が NULL の場合、カーネ
コンピューター：C言語講座：mmapについて
コンピューター：C言語講座：mmapについて 概要 mmapはファイルをメモリにマッピングするものです。わかりやすく言うと、UNIXのOSが行なっているページングやスワッピングを自プロセスで行なうようなものです。 これを使うメリットとしては、メモリ確保サイズが確保開始時に決定できない場合、簡単にはmalloc()で適当な量を確保し、足りなければrealloc()を使用して拡大することになりますが、realloc()を繰り返すとメモリ領域中に空きが出来やすく、大規模なシステムでは実際使用しているメモリより空き空間の方が数倍大きくなってしまい、メモリ不足で実行不可能になる場合があります。mmapを使用すれば、別々に拡大していくような管理が可能なので、また、スワップスペースとは別の位置に置くことにより、多数の動的メモリを必要とする場合に安全に動作することが可能になる場合があります。ただし、基本的
メモリ管理
プログラムはデータです。データを実際に解析(解釈)してみて始めて命令コー ドか単なるデータかわかります。プログラムを起動するというのは、プログラ ムファイルを解析しながらメモリの中に並べ、並べ終ったら、開始位置(Entry Point)と言いますから、命令を CPU に送り込み始めることです。 CPU は命令をメモリから順に呼んで、それを解釈して動きます。 メモリの中にプログラムがどういう風に並ぶかを理解しましょう。 プログラムの中には命令と変数があります。どちらも単なるビットの並びです。 区別は尽きません。だから分離して並べます。命令が並ぶ区画(セグメント) と変数が並ぶ区画があります。 変数には種類があります。これはどの区画に置かれて、どう管理されるかが違 うからです。変数が置かれる区画はさらに小さな区画に区分けされているとい うことです。スタック、ヒープ、グローバル(スタティックも同
メモリ管理を理解する（前編）
メモリ管理を理解する（前編）：Cocoaの素、Objective-Cを知ろう（7）（1/2 ページ） iPhone用アプリケーション開発で注目を集める言語「Objective-C」。C++とは異なるC言語の拡張を目指したこの言語の基本を理解しよう（編集部） あらゆるアプリケーションは、システムのメモリ上に展開されて動作します。 メモリは限られた資源なので、アプリケーションは資源を無駄に消費しないよう自己管理しながら動作する必要があります。この動作を実現するのが、開発者によるメモリ管理の実装です。 新しく登場した言語のなかにはメモリ管理が自動で行われる（言語のエンジン部分で暗黙的にメモリ管理がされている）ものが多いため、開発者がメモリ管理を意識することが少なくなっています。 実際、Objective-Cでも、Objective-C 2.0から（Mac OS X 10.5 から）はガベージコレ
Linuxmania: Linux Fedora8 32bit版で4GB以上のメモリを使う(Fedora,CentOS)
Linuxでは、PAE機能を有効にした kernel-PAE というカーネルで起動することで、32ビット版でも４GB以上のメモリを認識することができます。（同様に一部のWindows OSでも (Windows Server 2003など)、PAE機能を有効にして4GB以上のメモリを認識することができるようです） ※PAE (物理アドレス拡張) メモリアドレス空間を拡張することで、32ビットOSで大容量メモリを 認識可能にするインテル・アーキテクチャの機能です。 参考:物理アドレス拡張 - Wikipedia(外部リンク) 1. PAE有効カーネルのインストール # yum install kernel-PAE 2. grub設定 DG33BUなどマザーボードによっては、カーネルオプションでメモリ容量を明示的に指定する 必要があるため、ここでは mem オプション指定の例を紹介します。(下
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2009/10/30/20091029where-are-all-the-great-android-games-the-answer-is-simpler-than-you-think/
