はじめに はじめまして。 NTTデータ数理システムでリサーチャーをしている大槻 (通称、けんちょん) です。 C や C++ を使用しているとしばしばビット演算を行う場面が出て来ます。 計算機リソースが限られている状況では、ビットを用いることでデータ量を少なく済ませたり、計算コストを小さく抑えたりすることができるメリットがあります。 本記事では、ビット演算を用いて実現できる処理について、簡単なものから高度なものまで集大成します。極力わかりやすく頑張って執筆しました。特に前半 4 つはビットの説明の中でもかなりわかりやすい方だと思います。後半の 7 つのテーマは比較的高度なアルゴリズムの話題ですので、フラグ管理やマスクビットについて詳しく学びたい方は前半 4 つを中心に読んでいただいて、後半 6 つは必要に応じて読んでいただければと思います。反対にビットの知識はあってビットを用いたアルゴリズ
デザインの「悪い方がよい」原則 The Rise of "Worse is Better" rpg@lucid.com 日本語訳: daiti-m@is.aist-nara.ac.jp 私や Common Lisp と CLOS のデザイナーのほとんどは、MIT/Stanford 方式の設計に親しんでいる。 この方式の核心は、「正しい」やり方をせよ、という ことにつきる。デザイナーにとっては、以下の点をすべて正しく満たすことが 重要である。 簡潔性 デザインは実装と使用法の両面において単純でなければならない。 このとき、使用法が単純な方が、実装が単純なことより重要である。 正当性 デザインはすべての点において正しいものでなければならない。 誤りは許されない。 一貫性 デザインは一貫性を欠いたものであってはならない。一貫性を保つ ためには完全性は少しだけ犠牲にしてもよい。一貫性は 正当性と同
Rust is the future of systems programming, C is the new Assembly (Packt) Rust is the future of systems programming, C is the new Assembly (Packt) Posted Aug 29, 2019 16:33 UTC (Thu) by josh (subscriber, #17465) In reply to: Rust is the future of systems programming, C is the new Assembly (Packt) by roc Parent article: Rust is the future of systems programming, C is the new Assembly (Packt) I have,
DCL12-C. 抽象データ型は opaque な型を使って実装する 抽象データ型はオブジェクト指向言語であるC++やJavaに限られたものではなく、C言語でも、作成し使用されるべきものである。抽象データ型が最も効果を発揮するのは、プライベート(opaque)データ型や情報の隠ぺいを実現するときである。 違反コード 以下のコード例は CERT が開発した managed string library に基づく。[Burch 2006]この例では、managed string 型およびこの型に対して演算を行う関数が、以下に示す string_m.h ヘッダファイルで定義されている。 struct string_mx { size_t size; size_t maxsize; unsigned char strtype; char *cstr; }; typedef struct strin
C言語で、自作の構造体のメンバをユーザに開示しないテクニックとして、Opaqueポインタというものが知られています。今回は、書籍「C++のためのAPIデザイン」の3.1.6節を参考に、Opaqueポインタを使う簡単なサンプルを紹介します。 Opaqueポインタを使わない場合 人に関するデータを集めた構造体Personと、その構造体を使ったライブラリを作成することを考えます。以下にPerson.hのコードを示します。 #pragma once typedef struct _Person { int age; } Person; // 以下、Person構造体に関するAPI Person* createPerson(int age); // Person構造体のオブジェクトを生成 void printPerson(Person* ptr); // Person構造体を使った操作（メンバのプリ
unsigned int v; //only works if v is 32 bit v--; v |= v >> 1; v |= v >> 2; v |= v >> 4; v |= v >> 8; v |= v >> 16; v++;
おなじみC/C++から使えるJSONライブラリを紹介するコーナー。まずは過去のまとめ。 最速と言われる JSON パーサ「rapidjson」が本当に爆速なのか試してみた。 C言語から使えるJSONパーサ、parson が思った以上に良い仕事をしている。 僕がboost::asioとboost::property_treeを使いHTTPプロキシ環境下で非同期にGoogle Search APIから検索するまでにやった、たった一つの事。 C言語から使えるJSONパーサ、JSMNを試してみた。 何も見ずにC++でjsonパーサが書けるか試してみた。 ヘッダファイルだけでC++から使えるJSONパーサ「picojson」が凄い！ 最近は結構 matsuu さんのブクマから見つけて記事を書いてたけど今日はそうじゃない所からご紹介。 Jansson — C library for working w
何の話？ C, C++ での列挙宣言 enum について、列挙子の数が欲しいことがよくあります。例えば各列挙子に対応する情報を取り出すためのテーブルを以下のように簡単な配列で定義して対応付けを行いたい場合などです。 int PriceOf(enum Item x) { static int const price[NumItems] = { 123, // Item_A の値段 456, // Item_B の値段 789, // Item_C の値段 }; return price[x]; } この列挙子の数 NumItems を下記のように定義する手法があります。 enum Item { Item_A, Item_B, Item_C, NumItems }; このように NumItems を定義すると、このあと Item_D, Item_E, ... などが増えていっても NumIte
> この時点で変数valueには0xF000番地の値が正確に代入されてますでしょうか？ 根本的に間違っています。 やりたいことは、 value ← (0xf000) でいいんですね。 だとすれば、次のようにします。 const unsigned char *p_value = (const unsigned char*)0xf000; unsigned char value = *p_value; p_value = 0xf000;とした場合、p_valueというポインタ変数に0xf000番地を格納することになり、valueの中身には影響を与えません。 ところで、フラッシュメモリとのことですが、普通にアドレス空間にマッピングされていますか？ そのフラッシュメモリ特有の手順で読み込まないといけない（例えばコンパクトフラッシュのような）場合には、こんなに単純にはいきません。 > 正確に代入され
上記の様に、トークンは各識別毎に作られます。オブジェクトのキーおよび値もそれぞれのトークンとして格納されます。 jsmn_parse はトークンの量が不足している場合、エラー JSMN_ERROR_NOMEM を返します。例えば、どれだけの量のトークンが JSON 文字列として与えられるか分からない場合、トークンのサイズを広げる必要があります。この場合、jsmn ではパーサを再初期化する事なしに、トークンを広げて再度 jsmn_parse を実行する事でパースを続行出来る様になっています。 ただしどれだけの量が不足していたかは分からないので、適度な増減を考慮する必要があります。 今日は試しに twitter のパブリックタイムラインをパースしてみました。 #include <assert.h> #include <string.h> #include <memory.h> #include
「Linux愛好者の独り言」は，Linuxやプログラミングの，楽しさや初心者向け情報を配信するBLOGです。 CutterはC/C++用の単体テストユニットフレームワーク（所謂xUnit）だ。 評判が良いので，以前から使いたかったのだが，いかんせん，本家のチュートリアルが丁寧すぎてわかりにくく，使い方がわからなかった。 このチュートリアルでは，automake等を用いた本格的な使い方が書かれているので， てっきりCutterを使う時はいつもこのくらいの準備が必要なのかと思っていた。 ほんのちょっと，テストコードを書いて開発の補助にしたいだけなのに，いちいちMakefile.amだのconfigure.acだのを作るのは面倒だ。 (これが面倒でない人間はIDEなんて使わないだろう) 毎度，このチュートリアルに従うくらいなら，cxxTestでもを使うほうがましだと思った。 だが，どうやら，本家
このFAQについて 1 プロセス制御 1.1 新しいプロセスの生成: fork() 1.1.1 fork()は何をするのですか? 1.1.2 fork()とvfork()の違いは何ですか? 1.1.3 forkによる子プロセスを終了するときにexitよりも_exitを使うのはなぜですか? 1.2 環境変数 1.2.1 どうすればプログラム内で環境変数の値を取得・設定できますか? 1.2.2 どうすれば全ての環境変数を調べられますか? 1.3 どうすれば一秒未満のsleepができますか? 1.4 粒度の細かいalarm()はどうすれば得られますか? 1.5 どうすれば親プロセスと子プロセスの間で通信できますか? 1.6 どうすればゾンビプロセスができることを防ぐことができますか? 1.6.1 ゾンビプロセスってなんですか? 1.6.2 どうすればゾンビプロセスになることを防げますか? 1.7
Cでのポインタの読み方 Cのポインタの読み方は、ルールを知らないと摩訶不思議です。 ルールを覚えれば、 int (*p[5])[3]; char (*(*fp)(void))(int); なんてのも解読する事ができます。 大事な前程 ポインタを読む際には、「英語で読む」必要があります。 「え～、英語～」 と思う方もいるかもしれませんが、逆に日本語で読む方が大変です。 基本ルール ルール 後置演算子が優先。 関数の() 配列の[] 前置はあとで。 要は、「後ろに何かあったら、後ろが優先」です。 演算子の英語での読み方 * pointer to ... () function returning ... [] array of ... Lesson 1 まず、演算子が単独で出てくる場合です。 Lesson 1-1 pointer to ... int *p; これは、まずpを見ましょう。 i
プログラミング言語を以下の基準で分類してみよう。 高級 or 低級 高速 or 低速 高級言語の代表格はPythonでしょう。高速言語の代表格はC/C++でしょう。逆もその通り(低級=C/C++、低速=Python)。 JavaやC#などのVM言語は、その中間と言えるでしょう。 しかし、その他の面、「実績」や「言語対応」(ライブラリなどがその言語で使えたり、64bit対応が早かったりなど)を考えた場合、ダントツで、C/C++が最有力となる。 例えば、Python2.7ではpsycoが対応していなかったり、PyOpenGLのPython3版がなかったりなど。 結論として、「C/C++は世界の中心言語」と言えるでしょう。 次に、言語組み合わせを考えてみよう。 基本的に、「低級言語 ←(call) 高級言語」となっている。例えば、CとPythonの場合、CからPythonの関数を呼ぶのではなく、
フジテレビのノイタミナ枠アニメは毎期楽しませていただいているのだが、今やってる2本、「C」と「あの日見た花の名前を僕達はまだ知らない」は、とりわけお気に入りの中に入る。身の回りには後者、いわゆる「あの花」のファンが多くて、それはそれで同意なのだが、一応ファイナンス関係の人でもあって、「C」もなかなか面白く見ているので、こちらを応援する趣旨もこめて、ちょっとだけ取り上げてみる。 まあ、基本的には個人的満足だけど。 「C」で面白いのは、金融をめぐるもろもろの状況の、エッセンスの部分をアニメとして表現しているところにある。一部見逃したりしているので、理解がまちがっているところもあるかもしれないが、いくつか挙げてみる。 １ 私たちが住む現実経済とは別のところに金融の世界があって、そこでは現実経済とは違ったルールが適用され、巨額のお金が動いている。 「C」には「金融街」という特別な場所が出てくる。私
以下の文章は、Michael Feathers による On Loving C.. の日本語訳である。 文中の固有名詞などについて理解の助けとなるよう Wikipedia へのリンクを加えさせてもらった。 認めなければならないことがある。私は C を愛している。しばらくはそれを意識していても、忘れがちだ。Ruby、Haskell、OCaml、C++、Java、そして C# に心移りしたこともある――今も多くの言語に時間を割いているが、C の元に戻ってくると、私は故郷に帰ったような気持ちになる。 私は何十年も前に Kernighan と Ritchie の本をパラパラとめくったときのことを覚えている。C にはとても欲求不満を感じた記憶もあるが、とても満足を与えてくれたことも覚えている。C にはヘンなところがあるが、振り返ってみると、それは多くの他の言語のヘンさに比べれば不可解なところはずっと
LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #1/3 LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #2/3 LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #3/3 コンパイラ基盤 LLVM のブログで、未定義の動作という C 言語のダークサイドについての記事が3回シリーズで公開されている。 C 言語で未定義の動作を実行したら、「鼻から悪魔が飛び出しても文句が言えない」というジョークは有名で……いや、そんなのを知ってるのは年寄りくらいか（参考：nasa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く