リスト：Windowsアプリ創るならこれくらいは読んでおこうよ を表示しています。（全 11 件）

プログラマ志望の人にはぜひ読んで欲しい。
プログラマになってしまうと、仕事が忙しくて読む時間がない人が大勢います。
学生のうちに読んでおくのがいいかもしれません。
goto文論争など基本的な情報の資料にもなっています。
すでにプログラマになっている人は、C言語プログラマだけに限らず、多くの方が読まれているとよいと思います。
会社が、本当にプロを養成するつもりなら、必ず読めというと思います。
会社が、読む時間を工面してくれるはずです。
会社が、一時的な金儲けだけを目指している場合には読めと言われないかもしれません。
プロとしての仕事を目指すのではなく、顧客の対応の時間を重視しているなら、読む時間を工面してくれなかもしれません。
そういう場合は隠れて読んで、３年たったら別の会社に行くのがいいかもしれません。
いずれにしても、プロとしてプログラムに向き合う時に必要なことがいろいろ搭載されています。
ps.
最初は全部理解しようと肩肘はらずに、気軽に読み進んだ方がいいかもしれません。
仕事で関係がありそうな話題になったときに、もう一度読み直してみましょう。（kaizen / 2007-12-26）

題名の通り、完璧なプログラミングコードを書くための指針をまとめたシリーズの上巻。
良いコードを書くために守るべき習慣（プラクティス）が次々と述べられており、自分で実践したくなることはもちろん、開発者仲間にも教えたくなるような事柄が満載である。
プログラミング言語は特に指定されておらず、例外は多少あるものの、基本的にどのプログラミング言語を使うときにでも共通に使用できるテクニックが中心に述べられている。
例として上げられている言語はVisual BasicとC/C++、それにJAVAが多いが、コードは簡単かつ明瞭に書かれているため、これらのプログラミング言語を使ったことがなくても、問題なく理解できるだろう。
非常にボリュームが豊富なため、読み切るのに苦労するかもしれない。
しかし、多くの内容が理路整然とわかりやすくまとめられているため、量が多くて苦痛になるという感覚はあまり感じなかった。
また、経験豊富な開発者なら、既に知っている内容も多く含まれているかもしれない。
だが、既知のテクニックを再確認できるという点で、読む価値は十分あるだろう。
完全な初心者には向かないかもしれないが、もっときれいで読みやすいコードを書きたい全ての開発者、プログラマの方々に是非手にとって欲しい１冊である。（the_world / 2005-07-31）

　　なんとなくノリに近い雰囲気でこの業界に入った．
　　プログラミング言語の解説本片手に，あるいはおじさんにいろいろ言われながら
　　プログラミングを覚えた．
　　もう自分は一人前の開発者だ！
というひとが読むと，自分が実はちっとも一人前ではないことや，
ただ動くコードと，それ以上の価値があるコードの違いが理解できる本です．
設計やテストなど，内容的にも大変網羅的で，無駄のない実践的な本です．
また，例として掲載されているコードはVBやC，Javaがほとんどですが，
細かい文法規則を論ずる本でもないので，これらの言語を知らなくても読むことに問題はないと思います．
一見するとボリュームはすさまじいですが，
この内容を経験のみから学ぶ非合理さ（バカバカしさ）を考えれば
むしろコンパクトにさえ見えてきます．
書架に置いといて，定期的に時間をかけて読み直したいと思う本です．（EVAM / 2006-10-01）

　第１版を読んだ時の感動を忘れることが出来ない。コンストラクション（広義の実装）についての「MUST」はカーニーハン等で知っていたが、「WHY」について、ここまで系統的にかつ実践的な書物が存在することに驚きを禁じ得なかった。ちょうど暗いトンネルに先に見える明かりを見つけた時の昂揚感とでもいうべき感情であったような気がする。
　第１版の出版から１０年が経過し、第２版が出版され、早速目を通してみた。第１版では抽象的な話題になりがちであった「ADT：抽象データ型」や「オブジェクト指向」がJAVAやVBによる実装例を得て、現実のソースコードとして記述されている。筆者の豊富な経験が盛り込まれている第２版は決して、第１版の焼き直しではないことを実感した。
　第１版を読んだことがない、新人プログラマー諸氏は第２版をまず読むことをお奨めする。２冊で１万円を超える投資は決して無駄にはならない。さらに本書の参考文献リスト（邦訳名が充実し検索がしやすくなった）を使って守備領域を拡大していくことが「職業としてのプログラマー」には必須であると確信している。
　（銀鼠 / 2005-05-03）

たしかに厚いし、小遣いで買うには高いかもしれない。
でもね、いいね、この本はいいねー。
読みやすいので、厚さに臆することなかれ。得られるものは計り知れず。
中立的な立場で書かれているのが気に入っている。
良いコード、悪いコードの対比も楽しい。
また、各章末で紹介されている関連書籍（寸評が参考になる）が良いんだなぁ。
この本を起点に、多くの有名書籍にめぐり合うことができました。（殿下 / 2006-08-08）

上巻が良い内容でしたので、迷わず下巻を読みました。
上巻よりは少し難しいかったですが、それでも大変読みやすい本でした。
内容は、テスト、デバッグ、リファクタリング、コードチューニング、ツール、
レイアウトについてで直ぐに実践できる内容ばかりで業務に生かせます。
上下巻合わせて手の届く場所に置いておくべき、プログラマ必須の本でした。（なか / 2007-02-05）

上巻はあまりそうでもないですが、下巻は第1版とは大分趣が違うように感じました。オブジェクト指向、C++、XP、PMBOKなど、最近の手法やプロセスについての記述が多く、職人技的な内容(個人的にはこちらが好み)の割合が少ないようです。まあ、この辺の新しい知識もこれからは必要ですが...。（ / ）

コードコンストラクションにまつわるトピックを完全に網羅しています。参考文献が豊富に紹介されており、変な入門書より役に立つでしょう。
値段が高めですがその価値はあると思います。
ITエンジニアには特にオススメです。（amazon_hk / 2007-03-30）

上巻と同様、これもMUSTです。
原著は1巻構成になっていることを考えると、上下巻を切り離して読む事は出来ません。
たとえば下巻では自分の経験や勘に基づいて当てずっぽうでパフォーマンスを上げようとしたり、最初からパフォーマンスを優先して人間に分かりにくいプログラム書いてしまったりするなど、フォーマンス問題にありがちなアンチパターンと、そうした問題に対する正しい対処方法が書いてあります。
また、何かに付けてコメントを付けまくるコーディングスタイルの問題点なども上げられています。この本を読んでからは、コメントを書くぐらいならコメントが無くても分かるようなコードを書こう、コメントを書く場合はどうしてもトリッキーなコーディングが避けられなかった場合だけにしよう、という考え方に変わりました。
下巻は他にもエンジニアにとって不可欠なノウハウが満載です。上巻だけで満足するのではなく下巻も手に取り、"自分のために"勉強しましょう。（伊藤淳一 / 2009-11-01）

上巻の前半までは仕事でプログラミングに関わる方なら皆読んだ方がよいです。
上巻の後半から下巻にかけては特にこの本ならではという内容ではありません。
目次を見て興味がある方だけ読めばよいと思います。（やすます / 2009-05-20）

デザインパターンを世に知らしめるキッカケになった本。誰もが名著だと認める一方で、説明の仕方が難解だとか、具体例が適切でないとかGUI関連のものに偏っているなどとも言われます。特に「デザインの再利用」という視点が強調されているため、説明がやや抽象的に進む感はあります。しかし、世の中のパターン絡みの本はほとんどすべて本書をベースに記述されていますから、本家本元にチャレンジする価値は高いのでは。最初の部分を除けば、基本的にパターンのカタログなので、本書を最初から順番に読み進める必要は一切ありません。最初に書かれているFactory絡みのパターンを理解するのに違和感があったら、もっと後に書かれているObserver、Command、State、Mediatorといったあたりへ飛んで読み進めるとより楽に読ませると思います。（鈴木純一 / 2002-11-30）

開発にオブジェクト指向言語を使用する大きな利点の一つはクラス(階層)の再利用性であるが、現実にはそのようにクラス設計をする事は難しい。本書は再利用性を念頭に置いてクラス設計の手法(デザインパターンと呼ぶ)を経験に基づいて体系化した名著である。Javaをご存知の方は、Javaの各クラス・ライブラリ階層が本書のデザインパターンと酷似している事にお気付きであろう。
本書ではデザインパターンを大きく次の三つに分けている。
(1) 具象クラスを生成するための抽象(インタフェース)パターン
(2) 構造に関するパターン
(3) 振舞いに関するパターン
例えば、(3)で説明されるIteratorパターンはJavaでその名前のまま出て来る。また、(1)で説明されるFactoryパターンが(呼称はともかく)恐らく一番ポピュラーな手法で、具象クラス群の生成を念頭に置きながら、特定の具象クラスに依存しない真に共通な要素を抽象的に定義するパターンである。
本書の内容は学術的に導いたものではなく、経験則に基づいたものだけに実践的である。それでいて、体系的に美しい。機能的に優れたものはデザインも美しいという見本のようである。本デザインパターンの考察にあたっては、建築学を参考にしたというのも面白い。本書を順に全て読む事は容易ではないが、本書の内容を身に付ける事で具象化や継承によるクラスの再利用性が格段に向上する事請け合いである。オブジェクト指向言語を使用してプログラミングをする方にとっては必読と言って良い名著。（紫陽花 / 2007-04-27）

確かにこの本は予備知識なしに読むのは難しいですね。
まず、"デザインパターン"とは何かということを、そしてその記述の仕方(パターン名、問題、解決、結果)を第1章で説明されていますが、事前に知っておいたほうが読みやすいと思います。
第2章ではLexiというTexに似たドキュメントエディタのなかにどんなデザインパターンが使われているか書かれています。個人的にもデザインパターンを説明するにはテキストエディタや描画エディタが最適だと思い、2章も押さえておくと以降も理解しやすいです。
第3章以降でやっとそれぞれ(生成、構造、振る舞い)のデザインパターンが紹介されています。"生成"、"構造"、"振る舞い"というのが何を意味しているのか初めはよくわかりませんでしたが、各パターンを見ていくうちにこの区別の仕方が理解できます。
ただし各章を順番どおりに読んでいくのではなく、後へ先へページを何度もめくっていく中で理解していくことができるでしょう。
「デザインパターン」を学ぶ上で、結城浩氏の「Java言語で学ぶデザインパターン入門」やW.J. ブラウンの「アンチパターン―ソフトウェア危篤患者の救出」もお勧めです。（sire / 2005-09-27）

この本はデザインパターンのバイブルとして名高く、ソフトウェア技術者は一度は目を通すべき本でしょう。
しかし、読みやすくは有りません。例や参照している文献はいかにも研究者向けの難解なものが多いし、本題とは関係のないところで躓くことも多いです。それでも辛抱して読む価値はあります。判りやすさを優先した本は他にあるのですが、この本のようなパターンの「深い」情報を提供してくれる本が他にないからです。
原著が出版されて7年、主流の言語も移り変わり、OOPの図の表記もOMTからUMLに変わりました。そろそろ、深さのレベルを保ったままより判りやすく改訂した第2版がでれば良いなと思います。 （中村拓男 / 2002-09-05）

すべてC++ベースで論じてあり、Javaに関してはC++から変換したJavaコードしかない、よってJava特有の実装上の考慮点は自分で気づかなくてはならない。これは本書の責任ではなく、GoF95も6年の歳月による経年劣化ともいえる。UML表記も然りで、UML1.1以前の表記なので、多少本書のクラス図の書き方に目を慣らす必要がある。だが基本的教科書として、今なお、必須の書だろう。（nemo_kaz1 / 2001-11-30）

Effective C++シリーズで有名な、スコットメイヤーズ先生の本です。
Effective C++同様の語り口で、STLの解説をされています。
STLの入門書では、コンテナ・アルゴリズム・反復子の説明の後、
vector・list・set・mapなど個々のコンテナや高度なアルゴリズム
の解説がされているというスタイルが多いと思います。
これだけを学習するのも結構大変なのですが、いざSTLを使って開発
しようとすると、学習した内容以上の使い方をすることになってしま
います。例えば、ポインタのlistなど。
ポインタのlistはありがちですけど、入門書では触れられていません。
しかし、普通に使ってしまうと、メモリリークを起こしたりします。
そんな実際に開発するときに陥ってしまいそうな罠に対して、鉄則という
形で救ってくれるのが本書です。筆者の長年の経験や情報収集によって、
有益なことが厳選して載せてあります。
まず、入門書でSTLを学習した後、本書を読むと効果的だと思います。（ / ）

STLの利用経験のある方向けです。
本書の最初でも一応、STLについて簡単に触れてくれているのですが
STLについてまったく知識の無い方は
まずは【STL標準講座】などの書籍で
STLをある程度使えるようになってから本書を読むことで
さらにもう１歩、STLについての知識が深まると思います。
実際、これを読む以前でもSTLを【とりあえず使える】レベルだったのですが
もっと利口な使い方があったのだなと色々収穫がありました。
余力と興味があれば【Boost】についても学んでみるつもりです。（ふりらんす / 2006-09-29）

STLの入門書ではありません。STLについて何の知識もない人はこの本を選ぶべきではありません。
プログラミングである程度STLを使い慣れた人にとって目新しいことは少ないでしょうが、知識を整理するには役立つと思います。
取り立てて購入すべきメリットが見つからない本でした。（amazon_hk / 2009-03-13）

STLの世界の注意点ををSTLの世界から解説した本。
STLをより良く使うためには、一般的なプログラミングやコンピュータの知識に加え「実装」が関わってきてしまう、という事実を知らせてくれる本です。
ベンダ毎に違う実装に気を配る、というコストを支払っては「Effective」とはいえない、というのが私の個人的意見。
実装依存なSTLを「標準仕様」としてプッシュするあたりも、鼻に付きました。
ーーこの類いの本は世の中にある自分以外のフレームワークに一切触れずに、自分の良い所、できる事だけを伝えようとするので、
その辺りは読む人が気をつけないといけない所ではありますが。
STLを使うなら手元に置いておきたい本ですが、値段的には割に合わない感じがします。
開発者の目的は「標準仕様」のソフトウェアを書くことではないからです。
STLを効果的に使いたい、という欲求が純粋ならば良い本だと思います。（jiji / 2008-05-06）

～本書は、２分冊の上巻である。
上巻は、一般的なセキュリティの概要とそのコーディングテクニックについて述べられている。サンプルコードはCやC＋＋(一部C＃、XMLなど)で記述されている。
説明は、Windowsの例が多いが、そのほかのOSに適用できる例についても述べられている。そのため、コーディングする技術者及びレビューを行う管理者全般にも参考になる内容と～～なっている。
参考文献も豊富であり、同様のジャンルの書籍やドキュメント等をさがす手助けとなる。～（ / ）

セキュリティについてそれほど深い知識がなくても理解できる内容であるにも関わらず、セキュアなアプリケーション開発に必要な知識が漏れなく記載されている良書と思います。特にセキュリティテストやセキュリティコードレビューについては、実務に即適用できて非常に助かりました。（Yazin / 2006-06-05）

・本文が締めるページ数は、523ページ中450弱。
　コードの掲載が多いため、実際はさっくり読める（15-20時間読了）。
・文章はですます調。翻訳は細かな部分を除けば問題ない。
・演習問題の解答は掲載されていない。
・オープンソースの実用コードを例に挙げる点、さらにそのコードを付録CDから
　参照可能である点が非常に良い。オープンソースが身近になった。
・コードリーディング以外に関して、「共用体の応用」「Makefileの書き方」など、
　初級者を抜け出したいコーダにとって痒い処に手が届く内容は、悪くない。
　また、オープンソースがコード例として優れており、理解が深まる。
・ひとつの言語・OSに偏らない解説（それぞれの環境に言及する）で、広く楽しめる。
・コードリーディングに関して、特別な方法論を提唱する類ではない。
・前半、易しすぎる内容が目に付く。Cライク未経験者に対してか、
　制御文に関する章に関して、それぞれのステートメントの解説から入る。
コードに慣れ親しみ、且つコードの理解に必要な周辺知識（言語仕様・データ構造など）や
暗黙知（イディオム・名前付けなど）を学ぶことで、コードリーディングを啓蒙する書。
コードを読むことに慣れていないような、学生・新社会人・初学者にお勧め。 （shom / 2008-08-18）

CodeCompleteとCodeReadingを併せて読むとよいと、
組込み系のSESSAMEプロジェクトのメーリングリストと、
OS系のTOPPERSプロジェクトのメーリングリストで推薦を受けました。
CodeCompleteは読んだことがあったので、CodeReadingを読んでいます。
オープンソースを仕事にしているので、たいへん役立っています。
MISRA-Cは研修で取り上げてきたので、本書も研修の資料としても取り上げるように準備中です。（kaizen / 2008-01-05）

私はプログラマではありません。コンピュータの運用保守の仕事をしています。でも、自分たちの使用しているオープンソースのソフトウェアがどんなコードで書かれ、それがどのような仕組みで動作しているのかを知っておくことは決して無駄なことではないと思います。業務でオープンソースのソフトウェアを使用した運用保守をしている時、コードのレベルで動作を知っていればと痛感する場面は多くあります(セキュリティホールが発見されたとき、修正パッチが出るのを待って、それを適用することだけが保守の仕事ではありません)。運用保守の技術者がデベロッパの視点を持つことができれば、受身がちだと思われがちなこの保守サービスをもっと能動的なサービスとして提供できるようになるのではないかと思っています。私はずっとこのような本が出るのを待っていました。C言語等の熟達者(あるいはデベロッパ)向けの本かと思いますが、是非、そうでない方も手にとって読んでみてください。（ / 2004-06-12）

「人が書いたソース・コードを読む」ということは、プログラマにとって最も重要な訓練だということは常々言われてきました(他の人か書いた文章を読まずに、良い小説が書けるでしょうか?)。しかし、プログラムを書くためのの教科書がこれだけ多く発刊されていながらも、他の人の書いたコードを読むための教科書は今まで書かれてきませんでした。この "Code Reading" は、その「人が書いたコードを読むための本」です。
オープン・ソース・ソフトウェアを題材としているため、(OSS で最も人気のある) C言語、C++、Java が解説の中心になっています。しかし、各言語に特化したいくつかの章を除けば高級言語からアセンブラまでの全ての言語、全ての規模のプロジェクトに適用可能な内容です。一方、C 言語に特化した章では C 言語のイディオムや注意点が幅広く紹介されているため、中級レベルを目指す C プログラマが入門書の次に読むテキストとしても適切でしょう。
著者は「コードを読むには目的(技術の向上、構造の解析など)が大切」と解く一方で、「小説のようにコードを読む楽しみ」を訴えています。なかなかその域には達っせそうにありませんが、数ある OSS の中から厳選されて CD-ROM に収められた 1700万行のソース・コードは、当面の欲求を満たすのには充分すぎる量だと言えるでしょう。翻訳も日本を代表する大ハッカーの監訳で非の打ち所がありません。全てのプログラマにお勧めできる一冊です。（heita / 2004-06-13）

開発の現場にいると、意外に他人のソースを読む機会が多いもの。また、オープンソースを扱っていると、トラブル時の原因究明だったり、あるは、自分の勉強のために読む、ということもあるでしょう。
そういう場面におすすめなのがこの本....と思っているとちょっと違います。意外に中身はプログラミング・テクニックがメインです。しかも、実践を積んできた人なら、いつの間にか身につけているテクニックだったり、あるは、プログラミングの教科書に載っているような、データ構造やアルゴリズムに関した話だったり。
なので「Code Reading」というタイトルよりも「オープンソースから学ぶプログラミングテクニック」というサブタイトルの方が、適切に中身を表していると思います。
それよりも、この本のカバーをはずしてみると....（july-mori / 2004-11-06）

COMをやっていてこの本を読んでいない開発者は、今すぐコードを書くのをやめて、この本を手に取るべきだ。COMは難しいテクノロジーだが、Don Boxはそれを重要度の高い順に解説してくれる。インターフェイスがわからない人は本書を今すぐ手に取ってほしい。（fumiaki_y@hotmail. / 2001-08-23）

C++, Visual Basic, スクリプティング言語、いずれの言語を使うにせよ、COMを用いて開発を行うならば、この本はCOMの仕様に続いて、精読すべき一冊と言えます。（isis / 2001-09-11）

初めてCOMを学習する目的としては難しい。C++の知識があっても全部理解するのは困難。COM初心者には薦められない。（ / ）

COMを使用してプログラミングを行っている技術者に向けた、「こういうときはこういう書き方をした方が良い」「こういう書き方はやめたほうが良い」というTipsを集めた本である。すでにCOMを習得して実際の開発を行っている技術者向けということで、内容は高度なものが多いが、「なぜそうしたほうが良いか」「なぜだめなのか」も含めて解説されているので理解しやすい。（jbd03052 / 2005-07-22）

内容が高度で詳細にわたっている。
ただし、.NETのデバッグテクニック本だと思って読まないほうがよい。
前著「Windowsプログラマのためのデバッグテクニック徹底解説」の増
補改訂版といったほうが正しい。つまり、VisualC++/MFCでのデバッグ
作業は、.NETという実行環境でVisualStudioを利用するとこういう風に
なりますよ、といったほうが的確かと思う（だからC++の記述にかなり
ボリュームが割かれている）。
とはいえ、前半の章やVisualStudioのTIPSなどは私のようなやっと中級
になったばかりの.NET使いにも大いに役立つが。（エパメイノンダス / 2006-05-22）

VS.NET/VC++ で開発するなら必携と言えると思う．
かなりディープなところまで突っ込んだ説明や，具体的なデバッグテクニックが豊富に掲載されている．
初心者には難しいが，２章（デバッグ入門）・３章（コーディングとデバッグ）を（ざっとでよいので）目を通すだけでも相当参考になる．
ネイティブC++ の開発当初に ７章（VS.NETを使った高度なネイティブコードデバッギング）を読み非常に役立った．（たこ / 2004-12-01）

かなり高度なトピックをあつかっているので初心者向けではありません。
しかしVisualStudio.NETを使用したデバッグのテクニックについては.NETでの開発してる人にとっては有益だと思います。
またネイティブコードのデバッグの方法なども細かく書いてあるのでVC++ユーザーにもおすすめです。（ssl / 2004-09-15）

この本を読むまで、バグの原因というものはデバッガでプログラムの挙動を追いかけながら見つけるものだと思い込んでいました。ところが、この本で紹介されていたのは、バグの検査を自動化するコードをそのプログラム自身に埋め込み、テストランによってバグの箇所をすぐに特定できるというやり方だったのです。バグを後から見つけるのではなくバグが入り込むのをプログラム作成時に防ぐ、という考え方に私は強い衝撃と感銘を受けました。この本に書かれた「退屈なコードを書こう」というポリシーは、今でも私のプログラミングスタイルの基本になっています。
Kent Beckのテスティング・フレームワークが現れた今となっては内容に古さが感じられますが、根底にある思想の大切さは今でも変わりません。アサーションを使ったことがなくデバッグ情報をprintfで表示させたりしているレベルのC言語プログラマがこの本から学ぶことは多いでしょう。一読をお奨めします。（ / ）

C言語開発のノウハウがぎっしりつまった本である。
例えば、C言語で短いコードが、機械語で短い命令群になるとは限らないことを述べているところが気に入った。結果として、
「論理式に対しては”｜｜”を使用せよ。条件式に対しては？：演算子を使用せよ。
　条件文に対してはifを使用せよ。」
教訓を導き出している。
付け加えるとすれば、始めて各パターン、始めてコンパイルするコンパイラ（CPU)では、
１度はアセンブラに直して確認しなさいと書いて欲しかったかもしれない。
ps.
自動車向けのコーディング標準であるMISRA-Cでは十分カバーできていないところを、
本書では述べている点がいくつかあるようなので、併せて取り組むとよいと思った。
MISRA-Cでは、C言語の落とし穴とSafer-Cを参照している。
本書も参照文献の一つに加えるとよいと思う。（kaizen / 2008-02-27）

私はソフトウェア開発の仕事を始めてから20年以上になりますが、最近の傾向として、様々なAPIの習得が最重要とされ（仕事に必要なので止むを得ない）、「如何にコードを書くか」という、ソフトウェア技術者にとって最も重要な訓練が軽視されているような気がします。
以前はKernighanやPlaugerなどが書いた本を多くの技術者が読み、「コードの信頼性を如何に上げるか」、ということが多大な関心時でした。計算機資源が限られていたことや、オンラインデバッガが未成熟だったこともあり、初期のコードを如何に洗練させるか（要するに、バグの発生を如何に初期に食い止めるか）、ということに日々頭を悩ませたものでした。
今も勿論そうだとは思うのですが、誰でも一日中自身の計算機を使える環境にあること、オンラインデバッガの機能が著しく向上したことにより、とにかく早くコードを作り、バグが出ればその都度修正する、というスタイルに必然的に移行していると思われます。
C/C++は難しい言語で、ちゃんと訓練を受けた人でなければ扱えません。最近のソフトウェアの信頼性の低さは、C/C++が広まった割には、それを使いこなせる技術者が相対的に減っていることにあると、個人的には思っています。
本書だけで十分というわけではないでしょうが、現在軽視傾向にある問題を見つめる上で、再認識されても良い書物です。冒頭でKnuth（今知っている人がどれだけいる？）のTeXに関する文章が引用されていますが、これを理想とすることが現在正に望まれます。（加納 裕 / 2004-03-20）