Linus「C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが 簡単に生産されるようになってる」
/15 [4] (21:54) 原文: http://lwn.net/Articles/249460/ From: xxx To: xxx Subject: Re: [RFC] builin-mailinfo.c をマシな文字列ライブラリを使うようにすること Date: Thu, 6 Sep 2007 18:50:28 +0100 (BST) Message-ID: <alpine.LFD.0.999.0709061839510.5626@evo.linux-foundation.org> On Wed, 5 Sep 2007, Dmitry Kakurin wrote: > > Git のソースコードを最初に見たとき、ヘンだと思ったこと: > 1. C++ じゃなくてただの C を使ってる。理由は謎。移植性がどうとか言わないで、 > そんなのウソに決まってるから。 *あんた* のほうこそ
http://google-styleguide.googlecode.com/svn/trunk/google-c-style.el
;;; google-c-style.el --- Google's C/C++ style for c-mode ;; Keywords: c, tools ;; google-c-style.el is Copyright (C) 2008 Google Inc. All Rights Reserved. ;; ;; It is free software; you can redistribute it and/or modify it under the ;; terms of either: ;; ;; a) the GNU General Public License as published by the Free Software ;; Foundation; either version 1, or (at your option) any later version,
strchr() ではまった話 - bkブログ
strchr() ではまった話 標準Cライブラリに strchr() という関数があります。文字列の先頭から指定した文字を探すという単純な関数なのですが、先日、意外な仕様を知りました。 以下のコードを見てみます。 if (strchr("+-*/", c)) { // c は四則演算の記号かな? ... } この if 文は c が + - * / のいずれかの場合に条件が真となり、ブロック中が実行されます。…と、思いきや、実は条件が真になるケースがもうひとつありました。c が '\0' の場合です。 まさかと思って手元の Linux の man を見ると、文字列の終端のナル文字 ('\0') の扱いは明記されていません。 The strchr() function returns a pointer to the first occurrence of the character c i
A Memory Allocator
by Doug Lea [A German adaptation and translation of this article appears in unix/mail December, 1996. This article is now out of date, and doesn't reflect details of current version of malloc.] Introduction Memory allocators form interesting case studies in the engineering of infrastructure software. I started writing one in 1987, and have maintained and evolved it (with the help of many volunteer
2004-10-11
2chのマルチスレッドスレッドで興味深い議論があった。見ていただければわかるが、「C++でdouble checked locking(DCL)は安全か」という話題を、CPU毎に検討している。各CPUのmemory modelの話に立ち入った、楽しい議論だ。特に、リンクされている Double-Checked Locking, Threads, Compiler Optimizations, and More http://www.nwcpp.org/Downloads/2004/DCLP_notes.pdf なるScott Mayersさんのペーパーがイケてると思う。最近書かれたばっかり。ここを読んでいなかったら当分知ることはなかっただろうな。ラッキー。 というわけで本題も興味深いのだが、とりあえずスレッドの中でいくつか示された「DCLに代わる高速なシングルトンの実装方法」が実際どの程度
UNIX上でのC++ソフトウェア設計の定石 (3) - memologue
鉄則3: マルチスレッドのプログラムでのforkはやめよう マルチスレッドのプログラムで、「自スレッド以外のスレッドが存在している状態」でfork*1を行うと、さまざまな問題を引き起こす可能性があります。「問題」の典型例としては、子プロセスのデッドロックが挙げられます。問題の詳細を把握しないまま、マルチスレッドのプログラムで不用意にforkするのはやめましょう！ 何が起きるか 実例から見てみましょう。次のコードを実行すると、子プロセスは実行開始直後のdoit() 呼び出し時、高い確率でデッドロックします。 void* doit(void*) { static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_lock(&mutex); struct timespec ts = {10, 0}; nanoslee
UNIX上でのC++ソフトウェア設計の定石 (1) - memologue
UNIXは、Windowsなどの“開発者に優しい”OSと比較すると、シグナルやスレッドの利用に関して制限事項が多いですが、それを知らずにアーキテクチャ設計および実装を行ってしまうケースが散見されます。これは、再現困難なバグの温床となるでしょう。 そこで、罠に嵌らないための「鉄則」を何回かに分けて書いてみようと思います。 鉄則1: シグナルの送受に依存しない設計にしよう 他プロセスおよび自プロセスに対し、非同期シグナルを配送して処理の流れを変える設計はやめよう 非同期シグナルとは、SIGUSR1・SIGUSR2・SIGINT・SIGTERM などの、killシステムコールによって生成・配送されるシグナルのこと 単に無視(SIG_IGN)するのは問題なし スレッドとシグナルの併用もやめよう 動作の予測が困難、デバッグが困難 説明： 同期シグナルとは、SIGSEGV,SIGBUS,SIGPIPE
OBB vs AABB - Radium Software Development
iPhoneの一般修理店は予約なしでも来店できる？ 基本的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、
type punning と strict aliasing - memologue
/.JのGCC-3.4リリースの話題を追っていたら、GCC3では-O2で-fstrict-aliasingが有効だから注意せよというポスト(http://slashdot.jp/comments.pl?sid=175355&cid=537217)があった。 strict aliasing については、Radium Software Developmentさんが詳しい。これは気にしておいたほうがよさそうだ。GCCの -fstrict-aliasing の説明は次。 コンパイルされている言語に適用可能な別名規則（aliasing rule）のうち最も厳密なものをコンパイラが前提することを許します。これによって、 C（およびC++）では式の型に基く最適化を動作させることになります。例えば、ある型のオブジェクトが別の型のオブジェクトと同一アドレスに位置することは、それら2つの型がほとんど同一でない
マルチスレッドと共有変数 (続き) -- およびvolatile修飾の必要性 - memologue
複数のスレッドで変数を共有し、さらにその変数に対してread/writeの両方のオペレーションが行われるとき、その変数の操作は、上で書いたとおり、 read/writeともにmutexで保護するべき volatile修飾だけで済ませるのはNG mutexで保護するならvolatile修飾は不要 です。その根拠を、規格を引きながら見てみましょう。 The Open Group Base Specifications Issue 6 の 4.10 Memory Synchronization には、 Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thr
マルチスレッドと共有変数 - volatile?なにそれ。 - memologue
複数のスレッドから共有する変数(典型的にはグローバル変数)を操作する際、どんな注意事項があるか？という話題です。プラットフォームはPOSIXを仮定します。pthreadのお話です。 まず、一口に「複数のスレッドで変数を共有」といっても、おおまかにいって次のような状況が考えられます。 読むスレッドしか存在しない 読むスレッド、書くスレッドの両方が存在する 書くスレッドは、read-modify-write動作を行う 書くスレッドは、read-modify-write動作を行わない 変数の更新(メモリ操作)がアトミックに行える*1 変数の更新(メモリ操作)がアトミックに行えない*2 順に見ていきましょう。観点は、「(1) volatile修飾が必要か」「(2) mutexによるロックが必要か」の2点です。 まず、「1. 読むスレッドしか存在しない」ケース。例えば、 static const c
localtimeやstrtokは本当にスレッドセーフにできないのか (1) - memologue
googleから私の日記に、localtime_r や strtok_r, getpwnam_r などのキーワードで飛んでくる方が結構多いので、ちょっと関連する話題を書いてみます(内容の割に長い…)。 さて、8/9の日記で、POSIXのlocaltimeという関数(下記)を取り上げ、 struct tm *localtime(const time_t *timer); この関数を複数のスレッドが同時に使うと処理が破綻すると書きました。また、この関数はシグネチャが腐っているので、libcの外側でmutexを使っても処理の破綻を回避することはできず、localtime_rという代用関数を使うしかないとも書きました。POSIXで示されている代用関数(TSF)の一覧は、8/21の日記に書いた通りです。 本日は視点をちょっと変えてみて、「localtimeのシグネチャは本当にダメダメなのか？」に焦点
非同期シグナルとanti-pattern - memologue
sigsafeというUNIX向けの小さなライブラリがあります。これは、「シグナルを正確に取り扱うのは非常に難しい、俺たちのライブラリを使うと随分楽になるよ」といった趣旨の、アセンブラとCで書かれたライブラリで、それなりの種類のOS、CPUがサポートされています。 このライブラリ自体の使い方、使い勝手、あるいはどう実装されているかについてはまだ把握しきれていないのですが、ドキュメントに有用な部分があるのでご紹介します。 http://www.slamb.org/projects/sigsafe/api/patternref.html です。非同期シグナルを使用したコーディングを行う際の、一種のアンチパターン集になっています。 悪い例1: signal safe ではない関数をシグナルハンドラから呼んでしまう void unsafe_sighandler_a(int signum) { pri
memologue - UNIX上でのC++ソフトウェア設計の定石 (2)
鉄則2: シグナルハンドラで行ってよい処理を知ろう sigaction関数で登録したシグナルハンドラで行ってよい処理は非常に限定されている 次の３つの処理だけが許されている 自動変数の操作 “volatile sig_atomic_t” 型の大域変数の操作 「非同期シグナルセーフ」関数の呼び出し これ以外の処理を記述しないこと！ 説明： シグナル受信時に何らかの処理を行うためには、シグナルハンドラと呼ばれる関数を用意し、それをsigaction関数でシグナル名と紐付けておけばOKです。しかし、シグナルハンドラ内で行ってよい処理は、上記の通り非常に限定されています。これを把握しないまま奔放なコードを書くと次のような現象が起き得ます： 問題1: プログラムがデッドロックする危険がある タイミングに依存する、再現困難なバグの原因となる デッドロックの発生が典型例だが、それ以外にも関数の戻り値不正
memologue - C++でsynchronized methodを書くのは難しい (1)
Javaにはsynchronizedという便利なキーワードがあります。このキーワードを使うと、例えば次のように簡単にメソッドを「同期化」することができます。同期化されたメソッドは、複数のスレッドで同時に実行されることがありません。 public class Foo { ... public synchronized boolean getFoo() { ... } さて、C++ (with pthread) で同様の機能を実現するにはどうしたらよいでしょう？まず、一番単純な方法は次のようなものです。 // 方法 a void Foo::need_to_sync(void) { static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_lock(&mutex); // 処理 pthread_mutex_un
プログラムを書くときに便利なEmacsコマンド
Meadow/Emacsスーパーチュートリアル (Front Programmer Series) 作者: 松下晃久出版社/メーカー: 秀和システム発売日: 2004/10/29メディア: 単行本 クリック: 62回この商品を含むブログ (18件) を見る 会社にあったこの本を手にとってパラパラとめくっていたらいつの間にか夢中で読んでいた。 知らない便利なコマンドとの出会いがいっぱいの本でした。 その中でもプログラムを書く上で便利そうなコマンドを紹介します。 カーソル系 カーソルの移動は入力とかかわる肝なので覚えたいですね。 Emacsを使わない人から見ると魔法のように見えるかも? C-M-f 現在のインデントと同レベルの次の括弧へ C-M-b 現在のインデントと同レベルの前の括弧へ C-M-n 次の括弧へ C-M-p 前の括弧へ C-M-e 次の関数へ C-M-a 前の関数へ C-M-h
Cのプログラムの中でブレークポイントを設定する - bkブログ
Cのプログラムの中でブレークポイントを設定する Cのプログラムをデバッグする際には GDB などのデバッガが役立ちます。通常、ブレークポイントはデバッガの中から設定しますが、デバッグ対象のCのプログラムの中で設定することもできます。 Linux なら #include <signal.h> して、任意の箇所に raise(SIGTRAP); を挿入すれば OK です。 raise() 関数を用いて SIGTRAP シグナルを発生させています。 あるいは x86 限定なら __asm__("int3"); でも OK です。ここでは SIGTRAP を発生させるために int3 (0xcc) 命令を埋め込んでいます。GDB もソフトウェア的にブレークポイントを設定するときは当該箇所に int3 を書き込んでいるので、やっていることは割と似ています (GDBの場合は int3 を書き込む部分の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dW : Linux : C99を使ったオープンソース開発