I had to get there eventually. I had a blog post called “I Wrote a Fast Hashtable” and another blog post called “I Wrote a Faster Hashtable.” Now I finally wrote the fastest hashtable. And by that I mean that I have the fastest lookups of any hashtable I could find, while my inserts and erases are also really fast. (but not the fastest) The trick is to use Robin Hood hashing with an upper limit on
← Why should I have written ZeroMQ in C, not C++ (part I) Just to be clear from the very beginning: This is not going to be a Torvalds-ish rant against C++ from the point of view of die-hard C programmer. I've been using C++ whole my professional career and it's still my language of choice when doing most projects. Naturally, when I started ZeroMQ project back in 2007, I've opted for C++. The main
1. Optimizing software in C++ An optimization guide for Windows, Linux, and Mac platforms By Agner Fog. Technical University of Denmark. Copyright © 2004 - 2024. Last updated 2024-03-15. Contents 1 Introduction .......................................................................................................................3 1.1 Why software is often slow......................................
It works in all operating systems including Windows, Linux, OSX, FreeBSD, and others, and it can target any platform, including desktop, server, and cross-building for mobile (Android and iOS), as well as embedded and bare metal devices. It integrates with other tools like Docker, MinGW, WSL, and with all build systems such as CMake, MSBuild, Makefiles, Meson, SCons. It can even integrate with any
C++を書くときにデバッガを使うことが多いので,gdbについてメモしておきます.gcc+gdbによるプログラムのデバッグ 第1回 ステップ実行、変数の操作、ブレークポイントgdb を用いたデバッグ方法GDB.gdbinit を公開してみる - アスペ日記gdb + Emacs でおいしいデバッグ生活。 - trial and error Emacs + GDB チートシート - ひげぽん OSとか作っちゃうかMona-私もC/C++はWindowsで書くことが多かったので,gdbの機能に不満が多いですね…ブレークポイントの条件が設定しやすかったりするのは便利ですが,エディタと連動していないとどうも使いにくく感じてしまう.これまでvimで頑張ってきましたが,こういう用途にはemacsのほうが向いているようなので,乗り換えようか検討中です.追記:vim上でgdbを使えるようにした - Chee
Information 2013/12/25 書籍『プログラミングの魔導書 Vol.3』の発売 (書籍版の予約受付は終了しました) 2013/12/03 書籍『プログラミングの魔導書 Vol.3』の予約受付開始 2011/12/01 ブログを開始 2011/11/30 著者からの指摘を受け、書籍 『プログラミングの魔導書 Vol.2』PDF版を改訂 2011/11/02 書籍 『プログラミングの魔導書 Vol.2』の壁紙公開 2011/10/05 書籍 『プログラミングの魔導書 Vol.2』を発売 (書籍版の予約受付は終了しました) 2011/9/15 書籍 『プログラミングの魔導書 Vol.2』の予約受付開始 技術トレーニングサービスを開始 2010/8/07 書籍 『プログラミングの魔導書 Vol.1』を販売開始 2010/6/01 書籍情報を公開しました 2010/2/28 今年5月
Note: the text on this page was almost entirely written by Niall Douglas, the original author of the patch, and placed on nedprod.com. This copy in the GCC wiki has some corrections that may not be present on Niall's site. Why is the new C++ visibility support so useful? Put simply, it hides most of the ELF symbols which would have previously (and unnecessarily) been public. This means: It very su
Source Code Beautifier for C, C++, C#, ObjectiveC, D, Java, Pawn and VALA Introduction The goals of this project are simple: Create a highly configurable, easily modifiable source code beautifier. Features Indent code, aligning on parens, assignments, etc Align on '=' and variable definitions Align structure initializers Align #define stuff Align backslash-newline stuff Reformat comments (a little
C++ で、論理型言語(GHC)コンパイラを書く 論理型言語コンパイラを作る理由 基本ポリシー: いろいろ諦める GHC の基本 実装関連 C++ を使う理由 論理変数を実装する ゴールのコンパイル ゴールキューと疑似マルチタスク 疑似マルチタスクから本当のマルチタスクへ 最適化 ガベージコレクション Boehm GC を C++ で使うための調査 ガベージコレクションの実装 JavaScript で GHC [JavaScript] 8-queen [JavaScript] Canvas を使った描画 [JavaScript] 組み込み述語の書き方 (メモ) KLIC との比較 GraphViz と GHC オブジェクト構造の可視化(案) GraphViz によるグラフィカルデバッグ GHC プログラミング 入出力と順序制御 竹内関数と遅延評価 [JavaScript] wait/1 と
C++の練習はあんまり進んでいないのだけど、がんばろうという気持ちはあります!!1という昨今ですが、id:kazuhookuさんが作成したC++リファレンスビューワであるところのcpprefが素敵な感じだったので、やっぱりEmacsで使いたいなーってんで、同じような動作をするものを書いてみました。 http://github.com/kentaro/emacs-cppref cppref.elへのパスを通したあとに(require 'cppref)と書くだけでM-x cpprefできます。プロンプトがでるので、Perl版と同様、適当に入力してみるといい感じにドキュメントを拾ってemacs-w3mで表示します。 ざっくりでっちあげただけなのでいろいろ微妙ですが、どうぞご利用ください。というか、僕がちゃんと利用するようにしよう……。
背景 C++は、コード規模の増分に対して指数的にコンパイル・リンク時間が増大します。 以前、C++とJavaのビルド時間比較で調査したデータid:torutk:20071104と、id:torutk:20071107から、C++のコード規模によるビルド時間の違いをまとめ直したのが以下の表です。 対象プログラム名 総行数 命令行数 ファイル数 ビルド時間 ACE 5.6.1 307,819 79,930 1,248 00:10:40 ACE+TAO 5.6.1 1,066,708 247,391 2,592 2:35:30 コード規模が3倍でビルド時間は15倍となっています。 ビルド時間を短縮するアプローチ ビルド時間を早めるための工夫がいくつか存在しています。 キャッシュ等前回実行した結果を活用して処理時間を短くする コンパイル済みのオブジェクトはソースが変更されていなければ再コンパイルし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く