C++ で気軽に時間測定がしたい - iwiwiの日記
プログラムの一部分の所要時間をちょっと調べたいと思っても，前で時間を調べて，後ろで時間を調べて，引き算したものを出力して，と色々書かねばならず，意外と面倒です． Ruby の benchmark はいいなあと思っていたら，id:tanakh さんの PFI セミナーを思い出したので，それっぽいものを C++ で実現してみました． （2/21 19:30 頃に「もう少し便利に」のバージョンの問題点と解決について追記しました） 例 int main() { benchmark { sleep(1); } benchmark { sleep(2); } } こんな感じで書くと 1.000013 sec 2.000009 sec こんな感じで標準エラー出力に表示． ソースコード これを上に書いておけば OK です． #include <sys/time.h> struct __bench__ {
Javaバイトコードの読み方 - プログラマーの脳みそ
Javaのデバッグをしていて、ステップ実行中にステップインを繰り返したらソースコードのないところに行き当たったことがあるだろう。あるいはEclipseでF3キーでクラスやメソッド・フィールドの宣言元を辿っていってソースコードのないところに行き当たったことがあるだろう。 Eclipseの場合、"Class File Editor"というものが開く。そこにはJavaのバイトコードのニーモニックがズラズラと並んでいて、「これは読めないや、ワケが分からない」と投げ出してしまったりしていないだろうか。 怖がることはない。ちょっとコツを掴めばすぐに読めるようになる。 Class File Editorの開き方 自前のJavaクラスの場合、ビルドして出来上がったclassファイルを開く必要がある。"Package Explorer"だとclassファイルは隠されていて見えないのでWindow -> Sh
ソースコードを読むための技術
$Id: readingcode.html,v 1.13 2003/12/06 00:01:08 aamine Exp $ 2006-05-02 gonzui 追加。thanks: 冨山さん 2003-12-03 ltrace と sotrace を追加 2003-12-03 ツールのところに DDD を追加。thanks: 和田さん 2003-05-27 VCG, SXT などについて追加。thanks: 梅沢さん 2003-05-27 これもすっかり忘れていた strace, ktrace, truss, etags などについて追加 2002-08-30 すっかり忘れていた ctags を追加 2002-07-07 匿名希望さんからメールでいただいた情報を追加 (動的コールグラフ) 2002-06-13 日記経由でいただいた意見をもとに文章を追加。thanks: 柳川さん、まつもとさ
Java SE 6 じゃじゃ馬ならし
第一幕 虫退治と管理 OutOfMemoryError でお悩みのあなたに (改訂 Feb. 2007) OutOfMemoryError のハンドリング MXBean を作ってしまおう (改訂 Feb. 2007)ユーザ定義 MXBean より便利になった JConsole (Feb. 2007)JConsole JConsole をカスタマイズしよう (Feb. 2007)JConsole API 管理に使える便利なツール (Feb. 2007)jinfo, jmap, jstack, jhat 第二幕 脚本 言語の中の言語 (Nov. 2005)Scripting 第三幕 机の上 ネイティブアプリにアクセス (改訂 Feb. 2007)Desktop システムトレイが使える (Nov. 2005)TrayIcon 起動を華麗に (Nov. 2005)SplashScreen タブにボ
はじめてのひき - PortableBinaryHacks
Binary Hacks は GNU/Linux & x86 メインですが、 それ以外だとどんな感じだろうってことを書くところです。 私が個人的にいじってるものですが、 他の人にいじってもらっても問題ありません、 というか知らないことだらけなのでありがたいです。 1. イントロダクション Binary Hack入門 Binary Hack用語の基礎知識 file でファイルの種類をチェックする od でバイナリファイルをダンプする 2. オブジェクトファイルHack ELF 入門 静的ライブラリと共有ライブラリ ldd で共有ライブラリの依存関係をチェックする readelf で ELF ファイルの情報を表示する objdump でオブジェクトファイルをダンプする objdump でオブジェクトファイルを逆アセンブルする objcopy で実行ファイルにデータを埋め込む nm でオブジェク
C++ Portability Guide - MDC Doc Center
この後に、多くのマシンやコンパイラを横断して移植可能な C++ のコードを作る上で役に立つ規則・ガイドライン・TIPS の集まりが続きます。 この情報は、25 にものぼる異なるマシンと１ダース分以上の C++ コンパイラを横断して多くのコードを移植した結果として生まれたものです。これらのうちいくつかはあなたを苛立たせ、もうお手上げだと感じて「えい、<愛用の C++ 機能を追加>できないのはヘボコンパイラだ」と叫びたくなるかもしれません。しかし、これが移植性の高いコードの現実です。あなたがルールを守るなら、あなたのコードはすべての Mozilla プラットフォーム上でシームレスに動作し、新しいマシンへの移植も容易となるでしょう。 私たちは情報を最新に保つよう努力しています（例えば、ときどきコンパイラの改定で制約が取り除かれるかもしれません）。これらの tips に関する最新情報や、追加の情報
Let’s use doxygen!
はじめに プログラマには、ドキュメント、とくにプログラムの内部仕様書を書くのが苦手、 という人が多い。 その理由は明らかであって、そもそも、ソースコードに (バグも含めて)*1 すべての仕様が子細もらさず書かれているのに、なぜ、さらにそれと独立した仕様書が必要なのかと、 (半ば本気で) 思ってしまうからである。 ソースコードと独立にメンテナンスをしなければならないような仕様書は、 いずれソースコードと整合性が取れなくなって、無意味ならまだしも、 かえって害をなす存在となり果てることもある、ということを、 彼らは経験的に理解しているのである。 (*1) Ruby の作者である、まつもとゆきひろ氏は、 その著者『オブジェクト指向スクリプト言語 Ruby』の中の「付録C Ruby 用語集」で、 次のように書いている: ドキュメント まつもとの苦手なもの。彼は普段から「ソースがドキュメントだ。
プロ・アマ・プログラミング言語を問わずに今までの4倍のスピードで学習する方法 - Craftworks Tech Blog - Branch
私が実践して、とても効果が上がった学習方法を紹介します。 どんなプログラミング言語でも関係なく通用するやり方だと思います。 この学習方法に切り替えてからの 1 年の学習量は、それ以前の 4 年分に匹敵すると感じています。 以下にその方法を紹介します。 ソーシャルブックマークのホッテントリのフィードを購読する 特に気になったサイトの人気エントリにざっと目を通す 特に気になったブログを個別に購読する 流行のライブラリ、フレームワーク、アプリケーションのソースコードを読む カンファレンスなどのスライドに目を通す 特に気になった人のブックマークをお気に入り登録する 得た情報を元に実際にコードを書いてみる 評判の書籍を読む ソーシャルブックマークのホッテントリのフィードを購読する ホッテントリとは人気の記事のことを言います。沢山ブックマークされ、それだけ注目度が高いということです。 特定分野の人気記
Shibu's Diary: 「ソースコードをきれいに書く唯一の方法」は４つある
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 taken by Manuel_Marin なんとなく書いたら、アクセス数が10000件超えたソースコードをきれいに書くための方法の記事。r-westさんの「きれいなソースコードを書くために必要な、たったひとつの単純な事」と、uwiさんの「誰がためのきれいさ？」と、フォローのトラックバックまで頂きました。僕のも含めてそれぞれスタンスが違いますが、どれが正しいとか、どれが一番いいかというのはないと思っています。人によってどっちがいいかは別れるはずです。人によっていちばん苦労がなくて、モチベーションがあがる方法がそれぞれの人にとっての正解である、というのが僕の考えです。 モチベーションマネージメントというのがよく言われるけど、「モチベーションを上げろ」と言われて上がる人なんていませ
あなたのソースを汚くして生産性も下げている、たったひとつの間違い - よくわかりません
この内容には私も全面的に賛成で、クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。 http://blog.livedoor.jp/lalha/archives/50261226.html 先のエントリは、danさん*1やlalhaさんにまで言及いただき大変光栄で、なにより多くの人に読んでもらえた。多謝。 一方で、自分で読み直すと「先のエントリ」は、いくぶん観念的でいまいちよく分からないところもあるかなと思った。というわけで、より実践に結びつきやすいように、「何に気をつければいいのか」「どういう考え方でコードを書けばいいのか」を書いてみる。 lalhaさんがエントリで強調したかったという (1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い への包括的な対策であり、 (2) たく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Javaメモ目次(Hishidama's Java Memo)