From 8794cbcd5f2dfc0cea343f3a3bf5590bf42c6d97 Mon Sep 17 00:00:00 2001 From: Hiroyuki Kurosawa Date: Sun, 20 Jan 2019 23:01:47 +0900 Subject: [PATCH 1/8] add japanese translation - of_philosophy - cplusplus_basics --- chapters/cplusplus_basics/chapter.ja.md | 1431 +++++++++++++++++++++++ chapters/of_philosophy/chapter.ja.md | 105 ++ 2 files changed, 1536 insertions(+) create mode 100644 chapters/cplusplus_basics/chapter.ja.md create mode 100644 chapters/of_philosophy/chapter.ja.md diff --git a/chapters/cplusplus_basics/chapter.ja.md b/chapters/cplusplus_basics/chapter.ja.md new file mode 100644 index 00000000..bb5097ed --- /dev/null +++ b/chapters/cplusplus_basics/chapter.ja.md @@ -0,0 +1,1431 @@ + + +# C++ 言語の基礎 + +_by [Jetty Nimoy](http://jtn.im)_ + + + +> 未来の魔術師は数式を用いるであろう +> +> **--アレイスター・クロウリー, 1911** + + + +## 気をつけて！ + + + +このチャプターでは C++ 言語を用いて小さなコンピュータプログラムを書きます。事前の知識はとても少ないことを想定していますが、その他のトピックの大部分はこれの上に立脚しますので、このチャプターから得られるリテラシーはこの本の後続のチャプターの理解に直接的に影響します。さらに、ここでのレッスンは累積的なものなので、つまりトピックを飛ばせば迷子になってしまうでしょう。一つの概念で詰まってしまった場合、次のトピックに移動する前に理解できなかったパートを特に理解するための助けを得てください。このようにある意味厳格にレッスンを続けることで、openFrameworks だけでなくコンピュータ一般を最大限に活用できるようになるでしょう。 + + + +## イテレーション + + + +長いポニーテールに段のついた刈り上げと丸メガネを着けていて、リキテックス・ベーシックスのアクリル絵の具が飛び散り、浴び、こぼれ落ち、染みの無い衣服など着たことがなかった 90 年代の中盤の高校でのアートの AP 学生時代に私はドローイングやペインティングの多くを行いました。経済の授業に飽き飽きして TI-82 型グラフ計算機で遊んでいた時に、私は心の内に電気の灯るような物事を発見しました。生まれ育った家に転がっていた小さな計算機と違い、TI-82 には分厚い取扱説明書がありました。このマニュアルの中、三角法の関数やその他の無味乾燥な手の届かないサイエンスの章の間に、何か：図 1 に示すような、一回り小さな逆さまのピラミッドがその内側に無限にネストされているセクシーな白黒のピラミッド、が私の飢えた若き眼を奪いました。 + + + +![Figure 1: TI-82 rendering of the Sierpinski triangle, Courtesy of Texas Instruments](images/sierpinski-fractal-ti82.png "Figure 1: TI-82 rendering of the Sierpinski triangle, Courtesy of Texas Instruments") + + + +このフラクタル、有名な [Sierpinski triangle](https://www.wolframalpha.com/input/?i=sierpinski+triangle) には完全なシェルピンスプログラムを構成する 25 行あまりのコンピュータの命令が添えられていました。私は幾つかの数値演算も見ながらコードを仔細に調べました - 何も高度すぎることはなく、ほとんどのものは命令する言葉で、「これをせよ」や「もし何々ならば他のことをせよ」のようなものでした。私は書籍からグラフ計算機のコードに打ち込んでグラフ計算機でプログラムを実行することができました。最初はただの空白の液晶パネルです。徐々にいくつかのランダムなピクセルがあちこちで黒く切り替わりますが特に法則性は見出せません。さらに何秒かするとシーンが満たされ、すでにトライアングルの輪郭がかすかに見えてきます。十分な時間が経過すると、計算機はついに書籍のものとぴったり一致しました。私の気持ちははっきりとぶっ飛びました。はっきりとは意味がわかりませんでした。どのような自然の神秘がこんなにわずかな命令からこのような複雑な形態を生み出すのか？画面には 6,000 ピクセルがあり、わずか 25 行の命令がこの驚くべき生物のようなアートワークを生み出すに足るのだろうか？これは誰のアートワークなのか？私は新しい作品をそこから派生しうるのか？それまで私はごくわずかの仕事からこれほどの魔法のような褒美を得られたことはほとんどありませんでした。私は新たな礎を発見しました。私はそれが重要（だと私が決めたので）プログラムを理解する必要性を感じました。私はコードに戻って数値のいくつかを変更し、プログラムをもう一度実行しました。スクリーンは空白になり、異なった画像を描きました。今回だけは左に歪み、ビューポートからはみ出してしまいました。私は勇気を出して英語の命令の一つを変更し、そしてマシンはエラーを出し、実行に失敗しました。 + + + +![Figure 2: The human loop of a programmer.](images/programmer-cycle.png "Figure 2: The human loop of a programmer.") + + + +図 2 に示しているサイクルは私が何十年も実行する楽しみを感じており今なお愛している無限に繰り返されるループです。プログラムを作成することが何を意味するのか、そしてソフトウェア芸術を創ることが何を意味するのかを追求する中で、どんな新しいサイクルも私を驚かせなかったことはありません。コンピュータ命令のリストが繰り返し進化していくプロセスは芸術的な報いであると同時にロジカルな挑戦でもあります。これらの挑戦は、特に他の皆との協働や支援を得られる時、または問題をより小さな課題に分割できるときにはほとんど解決できないということはありません。もし Processing や JavaScript、または HTML と CSS などの他の環境でコードを書いたことがあれば、この最初の大事なレッスンはわかりきったものかもしれません。 + + + +![Figure 3: Don't get the wrong idea.](images/profit-not.png "Figure 3: Don't get the wrong idea.") + + + +小さなプログラムを記述することにこれから慣れ親しんでいく皆さんにとって、コードを書くプロセスにある繰り返しの性質を理解することは大切です。図 3 の挿話はこのプロセスでは「ありません」。エディタにたった一度だけコードを記述し、コンパイルを叩いて完成品を期待できることはほとんどないでしょう。これは自然で、小さなプログラムから始め、多くの失敗（バグ）を持っていて、望む結果や挙動に向かってゆっくりと進化していくことが通常受け入れられています。事実、事前の推測は全くのプログラマのミスであることはよくあることです。プログラムが紙に書かれていた昔の時代でさえも、作者は執拗にコードを睨みつけて間違いを直す必要がありました：つまりこのプロセスは反復的なものなのです。C++ 言語を学ぶにあたって、私はあなたのマシンでコンパイルできる小さなコードサンプルを提示します。変則的なパートはこの本からエディタにコードをタイプすることですが、（あなたの指が滑らない限り）プログラムは魔法のように動作します。私はわざと問題解決の経験を除いていますが、C++ 言語そのものの問題によるものを分離するためです。続いて、トピック毎によくある「デバッグ」（エラーの修正）作業にとりかかります。 + + + +## 最初のアプリをコンパイルする + + + +できる限り最も小さく、直接的な C++ プログラムから始め、その便利な環境をこのチャプターを通して C++ コードをテストするために利用しましょう。このために私たちは「コンパイラ」が必要ですが、これは何らかのコードを実行可能なアプリ、しばしば実行可能ファイルとも言われるものに翻訳します。C++ コンパイラの大部分は無料でダウンロード可能で、多くの場合がオープンソースです。私たちが生成するアプリは自動的に Apple の App Store、Google Play、Steam、Ubuntu Apps Directory や Pi Store のような場所には現れません。その代わり、それらは個人的でプライベートなプログラムであり、後から手動で共有することにあなたは責任を持っています。続くチャプターの "oF Setup and Project Structure" では、コンパイラはあなたのローカルコンピュータに存在し、オフラインで動作するでしょう。今は我慢して、Sphere Research Labs による便利なツールで 簡単な C++ を Web 上でコンパイルしましょう。ブラウザを開いて [ideone](http://ideone.com) (http://ideone.com) に行きましょう。 + + + + + +![Figure 4](images/where-is-says-java.png "Figure 4") + + + +プログラミング言語のリストのドロップダウンメニューが開きます。図 5 に示すように C++14 を選択します。 + +![Figure 5](images/choose-c14.png "Figure 5") + + + + + +エディタのコードが変化し、図 6 のようになることに注目してください。 + + + +![Figure 6](images/empty-template.png "Figure 6") + + + +これはただの空のコードの雛形で、何もせず、エラーも起きません。左手の溝の数字はコードの行数を示しています。"Run" というラベルのついた緑のボタンを押します。コメント欄にコードのコピーと "Success" が現れ、"stdin"（標準入力）とラベルのあるエリアは空っぽです。"stdout"（標準出力）も同様に空です。 + + + +### タイポグラフィについての余談 + + + +Web 上の大部分のフォントは可変幅であり、つまり各文字は異なった横幅です；目には読み易いです。フォントには固定幅のものもあり、これは全ての文字（W と小文字の i でさえも）が同じ横幅です。これはタイプライターのように変わって奇妙に見えるかもしれませんが、重要な目的を担います。固定幅のフォントはテキストのブロックをゲーム版のようなもの、たとえばチェス盤や方眼紙のようなものにします。コンピュータプログラムのコードは通常固定幅の書式設定で表示されますが、これはそれがアスキーアートの様式だからです。インデント、ホワイトスペース文字、および繰り返しパターンは重要であり、保存して肉眼で比較することを容易にします。芸術家の Jeremy Rotsztain を除く私の知る全てのプログラマは彼らのコードに単一幅のフォントの何らかの様式を用いています。タイプフェイスの提案の例は Courier、Andale Mono、Monaco、Profont、Monofur、Proggy、Droid Sans Mono、Deja Vu Sans Mono、Consolas、そして Inconsolata などです。今後`このインラインスタイル` . . . + + + +```cpp +nそしてこのブロック中のスタイル . . . +``` + + + +. . . に、フォントスタイルが変化することに気づくでしょうが、これはあなたが何らかのコードを見ていることを意味します。 + + + +### コメント + + + +さて、コードエディタの左上の _Edit_ (図 7) を押下してください。 + + + +![図7](images/ideone-edit.png "図7") + + + +わずかに異なる編集設定がありますが、同じテンプレートのコードが上部で編集可能になっているでしょう。今度はコードを編集してみましょう。5 行目を探すと、このようになっています： + + + +```cpp +// コードをここに書きます。 +``` + + + +2 つのスラッシュから始まる行はコメントと呼ばれます。あなたが理解できる方法で注釈をつけるために、何で記述することができます。スラッシュを 2 つ前方に置くことで"コードのコメントアウト"をすると便利なことがあります、なぜならばこれで C++ のコードを削除せずに無効化することができるからです。C++ でのコメントは複数行に渡ったり、タグのように挿入されることもできます。コメントモードの開始と終了の構文は異なります。`/* と */`の間の全てがコメントになります： + + + +```cpp +/* +これは複数行コメントです。 +まだコメントモードです。 +*/ +``` + + + +5 行目のコードを削除して以下の宣言に置き換えてください： + + + +```cpp +cout << "Hello World" << endl; +``` + + + +このコード行は暗黙の _標準出力_ (別名 _stdout_)として知られるテキスト空間に "Hello World" と言うように命令しています。プログラムを記述するときに、_stdout_ が存在することは期待しても安全です。このプログラムはそこにテキストを"プリント"するでしょう。別の時には、ただのトラブルシューティングに使われるコーディング環境のウインドウペインとなります。 + + + +引用符の間にはほとんどどんなものでも入れることが可能です。引用されたフレーズは文章の _文字列(string)_ と呼ばれます。より厳密には、これは*C 文字列リテラル* です。ストリングについてはこの章の後ろでさらにカバーします。このコードで `cout <<` の塊のパートは「以降のものを標準出力に整形して出力せよ」という意味です。最後の `<< endl` のパートは「キャリッジリターン（行の終わり）文字を hello world メッセージの末尾に追加せよ」の意味です。最後に、このコード行の一番最後にセミコロン(;)があります。 + + + +C++ では、セミコロンは文の終わりの終止符あるいはピリオドのようなものです。それぞれの宣言の最後にはセミコロンをタイプしなければならず、これは通常はコードの行の末尾にあります。もしセミコロンをタイプするのを忘れた場合、コンパイルは失敗します。セミコロンは 1 行に複数の宣言があることや、一つの宣言で複数の行を使うことを許容し、プログラマがホワイトスペースによって柔軟で表現豊かであると感じることができるために有用なものです。セミコロンを追加することで、コンパイラが混乱しないことを確実にします：あなたが手助けをして、どこで宣言が終了するかを示してあげるのです。始めて C や C++ を学ぶ際、セミコロンを忘れることはとてもよくあるミスたり得ますが、それでもこれはコードをコンパイルするために必要なものです。十二分に注意してコードの宣言はセミコロンで終了するようにしてください。 + + + +タイプすると、テキストが自動でマルチカラーに色付けされることに気づくかもしれません。この便利な機能は _シンタックスカラーリング_（またはシンタックスハイライト）と呼ばれ、コードを読んだり、変なシンタックスのトラブルシューティングや検索を支援する能力を潜在的に向上させます。ツールはそれぞれ独自のシンタックスカラーリングシステムを持っているので、もし色を変えたいと思った場合、色がドキュメントそのものに追加されるようなワープロと同じではないと考えてください。コードエディタは "TRON.TTF" フォントを光るアクアカラーを `endl` （これは行末を意味します）_だけ_ に割り当てることを許しません。代わりに、シンタックスの種類全部のために特別なスタイルを選び、それがそのタイプのコードである限りコードの全てのパーツがその方法でスタイル付けされて見ることができます。このケースでは、`cout` と `endl` の両方がキーワードと見なされるので、ツールはそれらを黒く色付けします。もしこれらが他の場所で別の色で現れた場合も、コードは以前と同じであることを信じてください。なぜなら異なるコードエディタは別のシンタックスカラーリングを提供しているからです。今はコード全体はこのように見えています： + + + +```cpp +#include +using namespace std; + +int main(){ + cout << "Hello World" << endl; + return 0; +} +``` + + + +今度は右下の角にある緑の _ideone it!_ ボタンを押下し、コードエディタの下半分、ちょうど緑のボタンの上の出力コンソールを見ましょう。 「コンパイル待ちです(Waiting for compilation）」「コンパイル（Compilation）」「実行中（Running）」というようなオレンジのステータスメッセージが表示されるでしょう。すぐ後に、プログラムはクラウド上で実行されて標準出力が Web ページに表示されます。図 8 にあるメッセージが出るでしょう。 + + + +![図8](images/hello-world.png "図8: Hello World が出力ウインドウに表示されている") + + + +ここまでやりきりました。あなた自身を褒めてください。あなたはたった今最初の C++ コードを書きました；分析し、コンパイルし、実行し、出力をご覧ください。 + + + +## Hello World を越えて + + + +これで私たちは第一歩を踏み出しましたので、後戻りしてコードの他の部分を分析してみましょう。最初の行は include 宣言です： + + + +```cpp +#include +``` + + + +Java や CSS での _import_ と同様、`#include` はコンパイラに _iostream.h_ というファイルから他の有用なコードをファイルのその場所にカット＆ペーストするように告げるようなものなので、あなたの新しいコードはそのコードに依存することができます。このケースでは、iostream.h は `cout` と `endl` を私のコードの中で、それらの名前をタイプするだけで利用できるツールとして _提供_ します。C++ では、**.h** で終わるファイル名はヘッダファイルと呼ばれ、これはファイル名が **.cpp** で終わる C++ の実際の実装ファイルでインクルードするであろうコードを含んでいます。標準ヘッダが C++ には沢山組み込まれて様々な基本的なサービスを提供しています - 事実、ここで挙げるには多すぎます。もしそれで十分でなければ、プロジェクトに外部のライブラリを、そのヘッダをインクルードすることで追加することはよくあることです。あなたが記述する」k〜どの一部としてヘッダファイルを定義することもできますが、構文はやや異なります： + + + +```cpp +#include "MyCustomInclude.h" +``` + + + +openFrameworks では、ダブルクオートはシステムのインストールの一部でないヘッダファイルをインクルードするときに使われます。 + + + +### # 付きは何? + + + +これが全体像ですが、概念は理解する価値があります。include 宣言は実際には C++ コードではありません（セミコロンがないことに注目してください）。これは完全に分離されたコンパイラのパスの一部分で _プリプロセッサ_ と呼ばれます。これは実際のプログラムの命令が処理される前に行われます。これらはコンパイル後に実行されるコンピュータへの命令に対して、コードのコンパイラに対する命令のようなものです。ポンド/ハッシュ記号をこれら _プリプロセッサ命令（preprocessor directives）_ の前に使うことで、人はファイル中で明確かつ十分な理由をもって、これらを見つけることができます。これらは異なる言語が、実際の C++ コードに混ざっているように見えるでしょう。C++ プリプロセッサ命令は多くはありません - それらはほとんどその他のコードを集めることに関連します。これらのいくつかを見るでしょう。 + + + +`#define` +`#elif` +`#else` +`#endif` +`#error` +`#if` +`#ifdef` +`#include` +`#line` +`#pragma` +`#undef` + + + +実験してみましょう。コードエディタで、1 行目の include 命令をコメントアウトし、コードを実行してください。コードの行をコメントアウトするには、連続した 2 つのスラッシュを行の始めに挿入します。 + + + +```cpp +//#include +``` + + + +シンタックスカラーリングが全て緑に変わって、今はこれがコメントに過ぎないことを意味します。右下にある大きな緑のボタンを押してコードを実行すると、出力ペインの何か新しい物に気づくでしょう。 + + + +``` +prog.cpp: In function 'int main()': +prog.cpp:5:2: error: 'cout' was not declared in this scope + cout << "Hello World" << endl; + ^ +prog.cpp:5:27: error: 'endl' was not declared in this scope + cout << "Hello World" << endl; + ^ +``` + + + +コンパイラがエラーを発見し、プログラムは実行されません。代わりに、あなたがこれを修正するのを助ける為の試みとして、コンパイラはどこでわからなくなったかを示します。最初のパート、_prog.cpp_: はエラーのあるファイルを教えています。このケースでは、ideone.com がデフォルトのファイル名であなたのコードを保存しています。次に、`In function 'int main()'`: +　とありますが、エラーを含んでいる特定の部分を示していて、この例では、_main_ という関数の {中括弧} の中です。（関数と中括弧については後ほど触れます）次の行には、`prog.cpp:5:2:`とあります。5 はファイルの最初から何業あるか、そして 2 は行の始めから右方向に何文字あるかです。次に、`error: 'cout' was not declared in this scope` というものがあります。これは何がコード中でエラーと思われているかを記述しています。この例では、これはかなり正しいです。iostream.h が無くなっていて、それにより `cout` が我々に提供されておらず、したがって "Hello World" を送信しようとした時に、コンパイラが失敗しているわけです。続く 2 行には、疑わしい `cout` を含むコード行があり、そしてその下の行には小さな上向きのキャレットがあって、これはコード中の文字を指している矢印と推察できます。このケースではこの矢印は `cout` の `c` を指しています。システムはどのトークンが誤りか視覚的に示しているわけです。二つ目のエラーが表示されていて、今度はコンパイラは endl が無いと訴えています。もちろん、このエラーを修正するには `` をインクルードすることを私たちは知っていますので、これをやりましょう。1 行目のコメントを解除してコードを再実行してください。 + + + +```cpp +#include +``` + + + +openFrameworks を使う際には、あなたが選択したツールとプラットフォームがあります。それぞれはエラーを異なった方法で表示します。あるものはコードを開いてハイライトし、追加情報のためのエラーのフキダシを出すでしょう。または、エディタは何も表示せず、コンパイル出力が上記に似たような生のエラーを表示するでしょう。時にコンパイラから複数のエラーを受け取ることは有用ですが、報告された最初のエラーだけを理解して修正することにフォーカスすると落胆の多くを受けずに済むでしょう。最上部のエラーを修正すると、後続のエラーは最初の修正によりカバーされて綺麗に消えてしまうことが多いです。最上部のコード 1 行をコメントアウトすることで、2 つのエラーが発生したのです。 + + + +### はじめての名前空間（namespace） + + + +2 行目には以下があります： + + + +```cpp +using namespace std; +``` + + + +とある SNS に入会して、ユーザー名を選択するように言われたとしましょう。私の名前は Mx. Jetty Nimoy なので - ユーザー名は JNIMOY でしょうか。私はページを送信するとエラーが返され、私の父である Joseph Nimoy が以前に登録して彼がすでに JNIMOY を取得してしまっていたので、そのユーザー名はすでに取得されていて別のものを選択しなければならないと言われました。ですので私はミドルネームのイニシャルである T を用い、固有な JTNIMOY というユーザー名を作成します。私は _名前空間（namespace）の衝突_ を生み出し、解決しました。名前空間は固有な名前のグループで - 一つとして重複していません。同一の名前が存在することは、それらが別の 2 つの名前空間にある限りにおいて可能です。名前空間はプログラマが他人のシンボルを上書きしてしまったり、良い名前を占有するなどしてお互いに不愉快になることの無いように助けてくれます。名前空間はまた、探しているものを見つけることを助けるためのすっきりと整理された管理システムを提供しています。openFrameworks では、全て `of` から始まっています . . . `ofSetBackground` とか `ofGraphics` のような感じです。これは名前空間を分割する一つのテクニックで、なぜならば他人が作成した別の名前が `of` から始まることはあまりなさそうだからです。同じテクニックが OpenGL でも使われています。OpenGL API（Application Programming Interface）の全ての名前は `glBlendFunc` や `glPopMatrix` のように `gl` から始まっています。C++ ではしかしながら言語が名前空間の構文を提供しているため、名前に必ずしも厳密にお行儀の良い接頭辞を付ける必要はありません。2 行目では、`using namepace std;` がコンパイラにこの .cpp ファイルは全ての名前を `std` 名前空間の中で使おうとしていることを伝えています。ネタバレ注意！これらの 2 つの名前は `cout` であり `endl` です。実験として 2 行目をコメントアウトし、実行してください。コンパイラはどんなエラーを返すと思いますか？ + + + +```cpp +/* using namespace std; */ +``` + + + +前ととても似たエラーで、`cout` や `endl` が見つけられていませんが、今度は、メッセージリストに提案された選択肢が表示されています。 + + + +``` +prog.cpp:5:2: note: suggested alternative: +In file included from prog.cpp:1:0: +/usr/include/c++/4.8/iostream:61:18: note: 'std::cout' + extern ostream cout; /// Linked to standard output + ^ +``` + + + +コンパイラは「ねえ、`cout` を探したんだけどファイルでインクルードされている名前空間の一つから見つけたよ。これがそれさ。`std::cout`」といっていて、この例ではコンパイラは正解です。`cout` とタイプする際に _より明示的に_ することを求めていますので、それの名前空間である `std`（standard）を左側に示し、2 つのコロン（::）を続けます。これは私自身を `Nimoy::Jetty` と呼ぶようなものです。実験を続け、5 行目を編集して `cout` と `endl` に明示的な名前空間が付加されるようにしましょう。 + + + +```cpp +std::cout << "Hello World" << std::endl; +``` + + + +コードを実行すると、正常にコンパイルされて、"Hello World" とプリントすることに成功すると思います。`using namespace std;` と書いている行はコメントアウトされているのにです。歌の歌詞をランダムに生成するプログラムを書いていると想像してください。明らかに、`cout` をかなり使うと思います。全ての `cout` の前に `std::` とタイプすることはとても退屈ですし、プログラミング言語がこの機能を追加している理由の一つはタイプ量を減らすことです。ですので 2 行目の `using namespace std;` は必須では無いのですが、それが（他の `using namespace` 宣言と共に）存在することで、C++ コードを暗黙的なコンテキストによって読み書きしやすくできるのです。 + + + +私がマンハッタンでのスクラブルのパーティに居るとして、私はただの JT だけ、としましょう。人々は私のターンの時に JT とだけ呼ぶことができます。しかし、もし James Taylor（別名 JT）がディナーの後に参加した場合、少しややこしくなるので、明確にするために Jetties を姓名で呼び始めるでしょう。C++ でも同様のことが言えます。私は `Nimoy::JT` で、彼は `Taylor::JT` なのです。二つの `cout` の名前があり、一つは `std` 名前空間、もう一つは `improved` 名前空間から来ていて、双方が明示的な名前空間で `std::cout` や `improved::cout` のように示されていればそれは全く正しいです。事実、そうでなければコンパイラは不満をいうでしょう。 + + + +2 重コロンの構文（::）についてはクラス（class）の紹介の時にさらに見るでしょう。 + + + +## 関数 + + + +続いて、4 行目を見ていきましょう： + + + +```cpp +int main() { +``` + + + +これが初めての開始と終了を持つコード片で、ですので他のコード片を "包んで" います。しかしより大事なことは、関数はその中に入っている宣言を _代表している_ ということです。この _関数（function）_ の終了は 7 行目の閉じかっこです。 + + + +```cpp +} +``` + + + +C++ では、図 9 の単純化された図のように、関数の中にコード宣言のグループを閉じ込め、それぞれの関数はより大きなプログラムの中にある小さなプログラムのように見えます。 + + + +![図9: たくさんの関数](images/program-anatomy.png "図9. プログラムにはたくさんの関数があり、それぞれの関数にはゼロ以上の宣言が含まれています。") + + + +これらの関数にはそれぞれ、呼び出し可能な名前がついています。関数を呼び出すとは、その関数の中に含まれているコード宣言を実行することです。基本的な利便性はタイピングが少ないことですが、その他の利点については後ほど述べましょう。ボードゲームのように、プログラムには開始地点があります。より厳密には、プログラムにはコンパイラがそこにあると期待している _エントリーポイント_ が存在します。そのエントリーポイントは _main_ と呼ばれる関数です。_main_ 関数の中に書かれたコードがプログラムの中で最初に実行されるコードであり、したがってこれはプログラム中の他のいかなる関数を呼ぶことにも責任を持ちます。誰が _main_ 関数を呼ぶのでしょうか？オペレーティングシステムです！このデモの main 関数の構文をブレークダウンしてみましょう。繰り返しますが、Processing のプログラマにとってはこれは古いニュースです。 + + + +![Figure 10: The Function](images/function-anatomy.png) + + + +関数を定義する際、最初のトークンは宣言された戻り値の型です。関数は値を戻すことができますが、質問に対する答え、問題に対する解法、タスクの結果、または加工処理の生産物のようなものです。このケースでは、 _main_ は分数や少数の無い数字の全体を指す `int`、または _整数値_ の一つを返すと約束しています。次のトークンは関数の名前です。システムは "main" という語は全て小文字であることを期待しますが、後ほどあなた独自の関数を定義し、名前付けに取り組みましょう。次は始めおよび終わり丸括弧です。そうですね、これには何も中に無いので、そこに存在することが奇妙に見えるかもしれません。後でここになにが入るのかを見ていきましょう - しかし関数から括弧を省くことの無いようにしてください、なぜならばある意味でこれは人間に対してこれが関数であるという主要なヒントだからです。事実、今後私は関数を名前で読んでいきます。そして例えば関数が引数を必要としない場合には `main()` のようにそれに()を付加し、関数が一つかそれ以上の引数を要求する場合には `main(...)` のようにそれに(...)を付加します。 + + + +続いて、始め波括弧があります。この始め波括弧はその前の終わり丸括弧と同じ行にあることもありますが、そうでない場合にはそれ自身の新規の行に書きます。これは個人的なプログラマ、プロジェクトやグループに依存しますが - どちらでも結構です。異なるインデントスタイルの完全なリファレンスについては Indent Style についての Wikipedia の記事(http://en.wikipedia.org/wiki/Indent_style)を参照してください。 + + + +この始め波括弧と終わりの間に、私たちはコンピュータに何かをさせる具体的な命令となるコード宣言を書きます。この例では、一つの宣言だけがあり、それは必要とされている `return` です。もしこれを戻り値の型が `int` の関数において省略すると、コンパイラは整数を返すという約束をあなたが破ったとして文句を言うでしょう。このケースでは、オペレーティングシステムは 0 を「つつがなく実行された」と解釈します。面白半分、0 を 1 に変更してコードを実行し、何が起こるかご覧ください。 + + + +## カスタム関数 + + + +私たち自身の関数を定義して言葉のテンプレートとして使ってみましょう。サンプルコードをエディタに入力して実行してください。 + + + +```cpp +#include +using namespace std; + +void greet(string person){ + cout << "Hi there " << person << "." << endl; +} + +int main() { + greet("moon"); + greet("red balloon"); + greet("comb"); + greet("brush"); + greet("bowl full of mush"); + return 0; +} +``` + + + +出力は馴染みの深いおとぎ話です。 + + + +``` +Hi there moon. +Hi there red balloon. +Hi there comb. +Hi there brush. +Hi there bowl full of mush. +``` + + + +この新しいコードでは、`main()` と同じように見えて異なる `greet(...)` という 2 つ目の関数に注目してください。同じようにコードブロックを保持する波括弧がありますが、戻り値の型が異なります。同様に丸括弧のペアもありますが、何かが中にあります。必要な return 宣言についてはどうでしょうか？関数が何も返さない場合には _void_ キーワードが戻り値の型の場所に置かれます。そういうわけで、`greet(...)` は _void_ の戻り値の型を持っていますので `return` を省略してもコンパイラは文句を言わないでしょう。丸括弧の中には `string person` というのがあります。これは引数で、関数が利用する入力値です。このケースでは、検索と置換に少し似ています。`main()` を見ると、私が `greet(...)` を 5 回呼び、それぞれ引用符の中の異なった文字列を、丸括弧の中に入れています。これらが _引数_ です。 + + + +余談として、いつそれらを _引数_ と呼んでいつ _パラメタ_ と呼ぶのかを専門的に区別するのを助けるために、このコード例をご覧ください： + + + +```cpp + +void myFunction(int parameter1, int parameter2){ + //todo: code +} + +int main(){ + int argument1 = 4; + int argument2 = 5; + myFunction(argument1,argument2); + return 0; +} + +``` + + + +前の例に戻ると、これらの 5 行のコードは全て **_関数呼び出し_** でした。それらは `greet(...)` を実行するように告げ、彼らが仕事を実行できるように文字列の引数を一つ渡しました。この一つの文字列の引数が `person` というパラメタを通じて `greet(...)` 内部のコードで利用可能となっています。事が起こっている順序を知るには、図 11 をご覧ください。 + + + +![Figure 11. Function Call Flow](images/function-call.png "Figure 11. Function Call Flow") + + + +図 11 のカラフルな線はコード上を実行に合わせて移動する想像上の再生ヘッドによって描かれる経路です。青い部分からスタートして main のエントリーポイントに入っていき、そして `greet(...)` に遭遇し、ここで _ジャンプ_ が発生します。線が緑になると、一時的に `main()` を抜けてしばらく `greet(...)` を辿っていきます。線が黄色になる頃には `greet(...)` の中に含まれるコードの実行は終わって 2 回目のジャンプ（return）が発生し、今度は先ほど保存された場所に戻って、次の宣言に続いていきます。この例で見ることができる明らかな利点は長い `cout` 宣言からシンプルな `greet(...)` の呼び出しに複雑さが削減されていることです。私たちが `greet(...)` を 5 回呼ばなければいけない場合、ルーチンを関数中に _カプセル化_ することは利便性の力を与えてくれます。あなたが挨拶を "Good night" から "Show's over " に変更するとしましょう。カット＆ペーストしたコード行の全てを更新するのではなく、たった一つの関数を変更することができてこれに関わるこの関数の利用がいっぺんに変更されるのです。さらに、コードは本当に複雑に成長します。それを小さなルーチンに分割し、それらのルーチンをカスタムの構成ブロックとして利用し、より大きなソフトウェアをどのように構築するかを考えることを助けるのです。関数を利用することで、システムの全てのディテールまで注意深く表現することから開放されます；それゆえ関数は _抽象化_ の一つの形態で、アートにおける抽象化に似ています。この種の抽象化は _複雑さのカプセル化_ と呼ばれますが、なぜならば大きく複雑なものを綺麗で小さなカプセルに入れてその大きく複雑な代物をより小さく、シンプルに見せるようなものだからです。これは - プログラミングだけでなく - 非常にパワフルなアイデアです。 + + +## 複雑さのカプセル化 + + +俳優のローレンス・フィッシュバーンが色付きの鼻眼鏡を着けて、とても複雑な説明の2つの選択肢をあなたに提示していると想像してください。一つには、ハッカーの英雄としての宿命を全うするためにあなたが悪しきマトリックスからの脱出を助けることを彼が望んでいるが、それは潜在的に苦痛以外の何者でもない運命と共に生きることを意味します。ともかくストーリーは続き、可愛い少女が現れます。一方では、彼はあなたが起きたこと全てを忘れてしまい、何も気づかずに不可解にも偽りの生活を送る小さなアパートにあなたを戻すことを望んでいます。この2つの選択肢は映画の _The Matrix_ で説明されていて、そうでなければ冗長になってしまうシナリオをシンプルにする手法として、主人公は選択を色付きの錠剤の形で提示されます。2つの込み入った選択肢は単純な比較にカプセル化されていて、それは映画の観客にとってずっと肚落ちしやすいものです。 + + +![Figure 12. Red Pill and Blue Pill from The Matrix](images/red-blue-pills.png "Figure 12. Red Pill and Blue Pill from The Matrix") + + +込み入った状況全体を繰り返すのでなく、ネオ（主人公）は単にどちらかの錠剤を飲めば良いのです。現実の薬においてさえも、複雑さをカプセルに閉じ込めるというアイデアはなお当てはまります。我々の殆どは最も効果的に医療行為を行うための専門知識を持っていないので、医者や薬学者がただ適切な薬草や化学物質の正しい配合を作ることを信じるのです。あなたが錠剤を飲み込む時、それは関数を呼ぶことに似ていて、なぜならばあなたは錠剤の奥深さを理解する必要がないという利点があるからです。あなたは単純にその錠剤が成果を出すことについて信頼します。同じことがプログラムコードにも言えます。殆どの場合、関数は他の誰かによって書かれていて、もしその人が良い開発者であるならば、あなたはそれらの関数の適切な呼び方を理解している限り、幸運にもその関数の内部的な動作からは開放されます。このように、あなたは _高レベル（higher-level）_ のプログラマで、つまりあなたが記述していない関数を単純に呼び出すことを意味します。openFrameworks でプロジェクトを作成する人は、openFrameworksの肩の上に乗っています。openFrameworksはOpenGL Utility Toolkitの肩に乗り、それはOpenGLそのものに立脚している、といった具合です。言い換えれば、openFrameworksのプロジェクトは _低レベル_ プログラミングとしての評判のあるC++の _高レベル_ アプリケーションなのです。図13に図示するように、私がインタラクティブな作品をC++で書いているというとしばしば問題が発生します。 + + +![図13. 巨人の肩に乗る](images/shoulders-of-giants.png "図13. 巨人の肩に乗る") + + +新規のメディアプロジェクトにC++を利用することは、他の選択肢（ほとんどスクリプト言語）に対して幾つかの利点があります。この議論は詳しい人々の中では非常に宗教的に（もとい：白熱したものに）なり得ます。あなたがC++を学ぼうとするとき、理由はたいていより速いランタイムの性能を求めるか、あなたのプロジェクトに組み込めるライブラリがより多いか、あなたのメンターがその言語に取り組んでいるからでしょう。oFのプロジェクトは高レベルと考えられますが、これは複雑なものの入ったより大きなカプセルを扱っているからであり、これは誇れるべきものです。 + + +## 変数（パート1） + + +> A “thing” is a “think”, a unit of thought +> 「物体」は「考え」、思考の単位である +> +> -- アラン・ワッツ + + +以下のプログラムをideoneに入力して実行してください。 + + +```cpp +#include +using namespace std; + +int main(){ + cout << "My friend is " << 42 << " years old." << endl; + cout << "The answer to the life the universe and everything is " << 42 << "." << endl; + cout << "That number plus 1 is " << (42+1) << "." << endl; + return 0; +} +``` + + +出力は以下のようになります。 + + +``` +My friend is 42 years old. +The answer to the life the universe and everything is 42. +That number plus 1 is 43. +``` + + +これまでのレッスンで、`<<` オペレータの間に入れたものは `cout` オブジェクトに整形されて入り、魔法のようにコンソールに出力されることを理解しました。最後の行で、括弧の中に簡単な計算（42+1）を入れ、それは43と評価されたことに注目してください。これは数学的な意味で _式（expression）_ と呼ばれます。これらの3行のコードは全て数字の42について何かを語っていますので、それらは全て _リテラル_ の整数を含んでいます。リテラルの値というのはプログラムに直接記述された内容です;コンパイルされると他の部分と値が固定されるため「ハード・ワイヤード」と呼ぶ人もいます。 + + +この数字を変更したいとすると、ワープロで知っていることは可能なので、42を新しい値に「検索と置換」します。3D空間に100,000のパーティクルがあったとしたらどうでしょう。いくつかは変化し続ける42であり、その他は変化してはいけない42だったら？プログラムを書いているとき、物事は重く複雑になり得ます。最もわかりやすい _変数_ の利用法は非常にパワフルな検索と置換のメカニズムですが、変数はそれ以上に有用です。さて、コードの最初に整数を宣言してリテラルの42の箇所で利用してみましょう。 + + +```cpp +#include +using namespace std; + +int main(){ + + int answer = 42; + + cout << "My friend is " << answer << " years old." << endl; + cout << "The answer to the life the universe and everything is " << answer << "." << endl; + cout << "That number plus 1 is " << (answer+1) << "." << endl; + return 0; +} +``` + + +今度は `answer` という変数を利用していて、私はこの1つの数値をコード中で変更すれば良いだけで、それは3つ全ての文章で42として現れます。これは検索と置換よりもずっとエレガントです。図18は変数の宣言と初期化を同じ行で行う構文の説明です。 + + +![図18. 変数の宣言と初期化](images/variable-declaration.png "図18. 変数の宣言と初期化") + + +変数の宣言と初期化を2行に分けることも可能です。それはこのようになります： + + +```cpp +int answer; +answer = 42; +``` + + +このケースでは、変数の宣言の後、そのanswerが予測できず不安定になる時間がありますが、これはCが（Javaと異なり）新規の変数の自動でゼロに設定されないためです - これはあなたがやる必要があります。そうしなければ、変数は予測できない値 - コンピュータのメモリのゴミ - になります。ですので、誤動作によるアートを作りたいのでない限り、変数は宣言に際してゼロであっても常に何らかの値で初期化するようにしてください + + +### 変数の名付け + + +「有効な名前の必要がある」と言っている矢印に注目してください。私たちは名前空間、関数、変数やプログラムに定義する要素（まだお伝えしていないクラス、構造体、列挙型やその他の物）に与える名前を考案します。コード中に新しい識別子を定義するルールは、ウェブサイトでありがちなパスワードの選択方法に似ていて厳格です。 + + +- 識別子は文字、数字、アンダースコアだけを含みます +- 数字からは始まれません。アンダースコアからの開始は可能です。 +- 言語のキーワード（例えば `void` という語）と同じにはできません。 + + +以下の識別子はOKです。 + + +``` +a +A +counter1 +_x_axis +perlin_noise_frequency +_ // a single underscore is fine +___ // several underscores are fine +``` + + +小文字のaは大文字のAと異なる識別子なことに注意してください。C++での識別子は大文字小文字を区別します。 +以下の識別子はNGです。 + + +```cpp +1infiniteloop // 数字からは開始できません +transient-mark-mode // ダッシュはアンダースコアにします +@jtnimoy // @マークは含められません +the locH of sprite 1 // スペースは入れられません +void // 予約語は使えません +int // 予約語は使えません +``` + + +変数に `void_int` と名付けるのは、ややこしいですが、アンダースコアで二つのキーワードを1つの識別子に連結しているにおで、コンパイラのエラーは起きないでしょう。まれに、`unqualified id` エラーに遭遇するかもしれません。これがC++の予約語のリストで、変数の命名時に避けるべきものです。C++には完全なプログラミング言語を提供するためにこれらが必要なのです。 + + +``` +alignas alignof and and_eq asm auto bitand bitor bool break case catch +char char16_t char32_t class compl const constexpr const_cast continue +decltype default delete do double dynamic_cast else enum explicit +export extern false final float for friend goto if inline int long +mutable namespace new noexcept not not_eq nullptr operator or or_eq +override private protected public register reinterpret_cast return +short signed sizeof static static_assert static_cast struct switch +template this thread_local throw true try typedef typeid typename +union unsigned using virtual void volatile wchar_t while xor xor_eq +``` + + +### 命名規則 + + +> 目的を同じくし、心を開くならば、習慣や言葉の違いはまったく問題にはならぬ +> +> **--アルバス・ダンブルドア + + +（変数を含む）識別子は異なるスタイルで書かれていて、構成要素の種類（変数、関数やクラス？）、データ型（整数や文字列？）、スコープ（グローバルかローカル？）、プライバシーのレベルなどの様々な属性を表します。あなたはその他が全て `lower_case_using_underscores_to_separate_the_words（単語の区切りにアンダースコアを利用した小文字）` であるのに、幾つかの識別子が大文字から始まって「キャメルケース」を利用していることに気づくでしょう。グローバルな定数は `ALL_CAPS_AND_UNDERSCORES（全て大文字とアンダースコア）` の名前で見つかります。もう一つは小文字の `letterThenCamelCaseFromThere（文字から始まってそれからキャメルケース）` です。ハイブリッドもあって、 `ClassName__functionName__variable_name` のようなものです。これらの異なるスタイルで違った識別子のカテゴリを示すことができます。 + + +より過剰には、プログラマが親しみを込めて _ハンガリアン表記_ と呼ばれるものを使うかもしれません。これは文字のバッジを識別子に付けて、それについての何かを表現しますが、これは、例えば `dwLightYears` や `szLastName` のように可読性を下げてもしまいます。命名規則は変更できないものではなく、コンパイラによって強制されているものでもありません。共同作業者は通常これらの繊細な命名規則について合意しお互いに混乱しないようにし、全員のパートが決定されたいかなる規則に対しても首尾一貫するように、規律を用いなければいけません。コードの命名規則の話題は、どの行に波括弧を置くか、インデントにタブを使うかのように、開発者間で滑稽に白熱する議論でもあります。プログラミングの多くの事と同様に、誰かが常にあなたは間違ったやり方をしていると言うでしょう。それは必ずしもあなたが間違っていることは意味しないのです。 + + +### 変数の変更 + + +変数は実行中に値が _変化_ するためにそう呼ばれます。これは大抵何か（たとえば水）を保管するために入れるバケツとして有用です。通常、最終的にはバケツに戻って水を幾らか利用するか、薬品を水に混ぜるか、バケツに水を足したりします。1つの変数は空のバケツのようなものでそこに何かを入れることができます。図19は _Minecraft_ というゲームのバケツです。 + +! +[図19. バケツ, Mojang AB 提供](images/minecraft-bucket.png "図19. バケツ, Mojang AB 提供") + + +コンピュータプログラムが小さな脳とした場合、変数は記憶の記憶の基本的な単位のようなものです。スケッチブックにノートをちょっと書き留めることは後から使うために値を変数に保存するようなものです。変数がその値を変化させる例を見てみましょう。 + + +```cpp +#include +using namespace std; + +int main(){ + int counter = 0; + cout << counter; + counter = 1; + cout << counter; + counter = 2; + cout << counter; + counter = 3; + cout << counter; + counter = 4; + cout << counter; + counter = 5; + cout << counter; + return 0; +} +``` + + +出力は `012345` となるはずです。イコールの使い方に注意してください。これは計算で慣れ親しんでいるものとは異なります。伝統的な文脈では、1つのイコールは両側の式は等価として評価されます。Cでは、それは実際には二重のイコール（==）であり、それについては後で述べます。単独のイコールは「右辺の式を評価して左辺の名前の変数に答を保存せよ」という意味です。もしこれまでプログラムをしたことがない場合には慣れるまでには少し時間が掛かるでしょう。もし私が（私の内なる子供は常にそうであるように）コーディング初心者であった場合、値を変数に保存する命令をコンピュータにするための他の文法についても恐らく楽しむことでしょう。Princeton sound lab による _Chuck_ という言語にある `3 => counter` というようなもの、あるいはもう少し視覚的に、図20に示すMinecraftの作業台の流用のようなものかもしれません。 + + +![図20. 変数割り当てのために改変したMinecraft作業台](images/minechuck.png "図20. 変数割り当てのために改変したMinecraft作業台") + + +変数名が右でなく左側にあることの有用性は実際にはとても明白で、式はとても長くなり得るからです！行を `varname =` で開始すると目で追いやすく、イコールの後に入力しようとしているものがどんな狂気の沙汰であっても、その前はシンボル2つ分の長さであることが保証されているからです。 + + +先ほどのコード例を詳しく見ると、数字を毎回1ずつ出力前に増やしていることが分かります。私は繰り返しリテラルな整数を変数に保存しました。プログラミング言語は基本的な算術を知っているので、以下のような変更をしてみましょう： + + +```cpp +#include +using namespace std; + +int main(){ + int counter = 0; + cout << counter; + counter = counter + 1; + cout << counter; + counter = counter + 1; + cout << counter; + counter = counter + 1; + cout << counter; + counter = counter + 1; + cout << counter; + counter = counter + 1; + cout << counter; + return 0; +} +``` + + +出力は依然として `012345` です。`counter = counter + 1` とすることで、`counter` を1ずつ増加させています。より厳密には、`counter` を右側の「加算」式で利用し、その結果を（直後に）`counter` に保存しています。これは `counter` を2つの別の時に述べているので少し奇妙に見えます。これは、マーティ・マクフライが過去と未来のバージョンの彼自身に遭遇するという、映画シリーズの _バック・トゥ・ザ・フューチャー_ を思い起こしますね。 + + +![図21. 未来のマーティが過去のマーティを利用する](images/futuremarty.png "図21. 未来のマーティが過去のマーティを利用する") + + + + +なんたることだ、めまいがする！しかしそれを何度か繰り返すと、見えるほどには複雑でないことが分かります。これは非常に _実践的な_ SFの利用であり、（あなたがカイル・マクドナルドかHaskellのプログラマでない限り）時空の構造に挑もうとしているわけではないでしょう。大事な事は、水を加えようとした時にすでにそのバケツには水が入っているであろうことと同様に、コンピュータのメモリの内容を変更するために、1命令前の `counter` を取得しているのです。`バケツ = バケツ + 水` を図22で示します。 + + + +![図22. バケツ = バケツ + 水](images/minecraft-inc.png "図22. バケツ = バケツ + 水") + + +1ずつ加算することは、または変数に何らかの値を足すことは実際あらゆるプログラミングで非常に日常茶飯事な事なので、そのための糖衣構文も存在します。_糖衣構文（シンタックスシュガー）_ とは簡単のためにプログラミング言語に追加された冗長な文法です。タイプ量を減らし、理解力や表現力を向上させ、そして（砂糖のように）プログラマを幸せにします。以下の宣言は全て `counter` に1を追加します。 + + +```cpp +counter = counter + 1; // 元の形式 +counter += 1; // 「自分に加算する」はタイプ量が少ないので便利です +counter++; // 「自分に1を足す」は1をタイプする必要がないので便利です。 +++counter; // 上と同様ですが、わずかに違います。 +``` + + +プログラムでテストしてみましょう。 + + +```cpp +#include +using namespace std; + +int main(){ + int counter = 0; + cout << counter; + counter++; + cout << counter; + counter++; + cout << counter; + counter++; + cout << counter; + counter++; + cout << counter; + counter++; + cout << counter; + return 0; +} +``` + + +やった、ずっとタイプ量が減りました。もっと完結にする方法はたくさんあります。これが1つの方法です。 + + +```cpp +#include +using namespace std; + +int main(){ + int counter = 0; + cout << counter++; + cout << counter++; + cout << counter++; + cout << counter++; + cout << counter++; + cout << counter++; + return 0; +} +``` + + +答えは依然 `012345` です。後置の加算演算子は式の中に存在したとしても変数を加算します。今度は前置のバージョンを試してみましょう。 + + +```cpp +#include +using namespace std; + +int main(){ + int counter = 0; + cout << ++counter; + cout << ++counter; + cout << ++counter; + cout << ++counter; + cout << ++counter; + cout << ++counter; + return 0; +} +``` + + +`123456` の答えが出ても、これは間違いではありません！前置の加算演算子は後置の姉妹とはまさにこの部分で異なるのです。0で初期化された `counter` に対して、`++counter` は1と評価し、`counter++` はまだ0と評価します（しかし加算されたバージョンの `counter` が後からの利用のために残ります）。以下の例の出力は `1112` です。 + + +```cpp +#include +using namespace std; + +int main(){ + int counter = 0; + cout << ++counter; // 1: 評価の前に加算される + cout << counter; // 1: 変化しません。 + cout << counter++; // 1: 評価の後に加算される + cout << counter; // 2: 変化した証拠です。 + return 0; +} +``` + + +算術的な完全性のために、負の _減算_ 演算子（counter--）も存在することに触れなければいけません。そして、恐らくここまでに推測しているように、`counter + 1` と言えるならば、Cコンパイラは `counter -3`（減算）、`counter * 2` （アスタリスクは乗算です）、`counter / 2` （除法）、丸括弧を利用した演算子の順番の強制は `(counter + 1) / 2` は `counter + 1 / 2` とは違う結果と評価されるようにその他の古典的な算術を認識します。 + + +変数についてはもう少し学ぶべき基礎がありますが、とりあえずは今まで学んだ事を使って、楽しんで実行してみましょう。さしあたりは、ここまでたどり着いたことにもう一度、あなた自身を褒めてあげてください！あなたは変数の何たるか、そしてそれに基本的な算術を行うやりかたを学びました。また、++演算子が変数名の前と後に置かれたときに何をするかを学びました。 + + +C++言語はC言語プラス1であることから名前が取られています。 + + +## 結論 + + +C++の紹介の最初の数ページを完了し、おめでとうございます。これらの基本的な概念をもってあなたは自分自身で十分遠くまで探検できるはずです、しかしofBookの残りのコード例を理解するための準備には十分でないことは認めます。紙幅の制限により、ここでみているものは十分な長さのC++言語への導入の「予告編」なのです。この章のそのバージョンはとても大きいので今ではそれ自身の書籍になっています - 完全版がWebで、将来的にはofBookの副読本として。非プログラマにC++言語を教えるためにはそれ自身で実際たくさんの科目が存在し、100ページ超の書籍に増大することは言うまでもなく、効果的に35ページに圧縮することはできません。真剣にopenFrameworksに取り組む場合、あなたが何を読んでいるのかを理解するためには、ofBookを読み進める前に立ち止まってこのチャプターの完全版を読むことを高く推奨します。資料は [こちら](https://github.com/openframeworks/ofBook/blob/master/chapters/cplusplus_basics/unabridged.md) + + +## 追伸 + + +章がここで終わることは、C++言語において何が重要で何が重要でないかを分けることを決して意図していません。単純に紙幅が尽きたのです。C++の導入の残りの部分の重要さの代わりに、そしてofZach氏の教育の経験に基づき、以下は完全版で見ることのできる詳細です： + + +- 変数はそれぞれ異なる期間存在します - 幾つかは長い時間、幾つかはプログラムのライフサイクルでの少しの間。_スコープ_ の科目はこのブックの完全版でカバーされており、_変数（パート2）_ というタイトルです。 + + +- 変数には _データ型_ があります。例えば、あるものは数値を保有し別のものは何らかのテキストを保有します。_基本的な型( +（Fundamental Types）_ にさらにあります。 + + +- Processingとは違い、変数は必ずしもゼロ値から始まりません。望みの値で初期化する必要があり、そうでなければその先に何が待っているか分かりません。この現象についての追加の議論は配列の導入部分にあります。 + + +> 未来を予測する最良の方法は、それを創り出すことだ。 +> +> **--エイブラハム・リンカーン** diff --git a/chapters/of_philosophy/chapter.ja.md b/chapters/of_philosophy/chapter.ja.md new file mode 100644 index 00000000..73bf62ea --- /dev/null +++ b/chapters/of_philosophy/chapter.ja.md @@ -0,0 +1,105 @@ + + +# 哲学 + +_by [Zach Lieberman](http://thesystemis.com)_ + + + +openFrameworks の航海は幾つかのゴールによって導かれています：それは協働的であること、有用かつシンプルであること、一貫性があり直感的であること、クロスプラットフォーム、パワフルさ、そして拡張可能であることです。加えて"人と一緒にやろう（do it with others / (DIWO)" の哲学により推進されています。 + + + +### 協働的であること + + + +openFrameworks の開発は協働的なもので、議論に頻繁に参加して、アドオンやプロジェクトでのコラボレーションを行うたくさんの人々の貢献の上に成り立っています。私たちは皆が openFrameworks を自らの物とし、エコシステムに貢献することを推奨します。 + + + +私たちは git という分散型バージョン管理システムを用いていて、これは人々がブランチを作り、実験し、提案が可能なことを意味します。[GitHub](https://github.com/openframeworks/openFrameworks "link to the GitHub repository of openFrameworks") のネットワーク図を見てみると、沢山の曲がりくねったブランチ、枝分かれしてまた合流するコードによるエイリアンのダイヤグラムのように見えます。コアのコードに対して作業する世界中にまたがる巨大なコミュニティが存在します：彼らはバグを修正し、プルリクエストを送り、見たいような形とするようなツールを具現化します。これは全世界的なプロジェクトであり、合衆国で目を覚ますとアジアやヨーロッパのプログラマからのプルリクエストやイシューの電子メールでいっぱいの INBOX を目にすることは日常茶飯事です。 + + + +### シンプルさ + + + +openFrameworks は有用性とシンプルさのバランスを目指しています。openFrameworks の最初期のバージョンはその中核部分を C++ と [OpenGL](https://en.wikipedia.org/wiki/OpenGL "wikipedia article on OpenGL")を教えるツールとして利用していましたが、時を経るにつれて中核部分がより先進的な機能を取り入れるようになり、サンプル（examples）が学習のための最適な方法となりました。引き換えに、物事をシンプルにして実験のための改変可能なスタートポイントとするべく、私たちは openFrameworks に同梱される沢山のサンプルを作成しました。 + + + +私たちは openFrameworks を可能な限り、特に他の言語や環境からきた人々にとってシンプルなものにしたいです。C++ は「大きな」言語であり、それは全く違うタイプの様々な C++ コードを書くことが出来るという意味です。書店に行けば何百もの C++ の書籍を目にするでしょう。私たちはあなた方が専門家になる必要なく、多くとも一冊か二冊の書籍が必要とし、コードのパターン、アプローチとスタイルはシンプルで直感的であるようなライブラリを作りたいです。私たちは [Processing](http://www.processing.org/ "processing language and IDE website") とある意味同質となること、つまり多くの機能が似通っていて一方のフレームワークから他方への移行が容易になることに特に関心を持っていました。 + + + +### 一貫性と直感的であること + + + +openFrameworks は一貫性があり直感的です：これは最小の驚きの原則によって運営されており、openFrameworks のあるパートで学んだことは別のパートでも適用可能です。初学者は openFrameworks をよくあるプログラミングのパターンについて学ぶことに使い、上級者は他の言語やツールキットでの経験を適用することができるでしょう。 + + + +学生ファーストであることがモットーです。openFrameworks を導く上で多く考えることは：私は 5 年か 10 年前だったらどんなツールを好んだか？コーディングのパターンはできる限りシンプルでタイピングしやすいものにしたい。これは動画のプレーヤにおいては "play" や "stop" といった自己言及的な関数名や直感的な変数名を持つことを意味します。直感的であることについては私たちは多くの議論を持っていますが、これはコードを出来るだけ素直な物にしたいという要求によっています。 + + + +### クロスプラットフォーム + + + +openFrameworks はクロスプラットフォームなツールキットです。openFrameworks は可能な限り多くの開発環境や OS をサポートします。openFrameworks をダウンロードをするには任意のプラットフォームや開発環境を選ぶことができ、学んだり遊んだりできるプロジェクトやサンプルを入手できます。移植が困難なコードは中核からは取り除かれ、代わりにアドオンの中に置かれます。 + + + +openFrameworks は多くのプラットフォーム：OS X、 Windows、 Linux、 Android、 組み込みの ARM Linux システム、Blackberry PlayBook のような実験的なプラットフォームの上でも動作します。openFrameworks の開発者は Android の場合には Java、iOS の場合には Objective-C といった他の言語と接続する上手な方法も考案しています。 + + + +クロスプラットフォームなライブラリの良い点は、あなたのアイデアをプラットフォームをまたいで移植することが容易なことです。ラップトップ上でスケッチし、即座に電話機上で実行できます。プラットフォームをまたいで動作させる何かを作成するような退屈な仕事の心配をせずにアイデアを最優先にできるのです。 + + + +### パワフルさ + + + +openFrameworks はパワフルです：[OpenCV](http://opencv.org/ "OpenCV, a library for (real-time) computer vision")のような高度なライブラリを利用したり、グラフィックカードのようなハードウエアを効果的に使ったり、カメラやその他のデバイスのような周辺機器を接続することができます。 + + + +私たちが C++ を選択したのは、それがかなり低レベルな言語でありながら高レベルなやり方でプログラムすることが可能だからです。C++ はより古い C 言語の拡張なので、とても低レベルでオールドスクールな C コードや、より高級な C++ コードを記述できます。openFrameworks で、私たちは両方のアプローチを使い、シンプル、明瞭でありながらパワフルなコードとの関わりを提示します。C++ を利用することはまた、C や C++ で書かれた沢山のライブラリと他の言語のラッパに依存することなく接続することを容易にしています。 + + + +openFramewoks は基本として OpenGL や [Cairo](http://cairographics.org/ "Cairo, a vector graphics library")、[FreeType](http://freetype.org/ "FreeType, a software library to render fonts")、[FreeImage](http://freeimage.sourceforge.net/ "FreeImage, a library to work with common computer graphic image formats")、OpenCV といったライブラリをラップしています。openFrameworks はユーザーコード（あなたが記述するコード）とこれらのライブラリの間の層として考えることができます。これらのライブラリには異なるスタイルやイディオムやアプローチがあります。そして私たちの仕事はそれらをラップして、一貫性があり直感的なものとすることです。 + + + +### 拡張可能性 + + + +openFrameworks は拡張可能です。もし openFrameworks に足りない物を見つけた場合、拡張するアドオンを作成することは容易です。openFrameworks の中核のアドオンは概して斬新な方法で問題を解決するというよりはライブラリをラップしています。openFrameworks はライブラリをラップしていますが、それらのライブラリはさらなるハックのために露出されたままです。 + + + +あなたが望むものを構築する際の openFrameworks の概念の一つは足場、もしくは足がかりとなる肩です。中核部分を軽量に保つことに資しているものの一つは、全てのものを可能な限り同梱しようとするのではなく、追加的なコード、ライブラリ、アプローチが必要に応じてユーザー間で共有されプロジェクトに編み込まれるように openFrameworks が「アドオン」のシステムを持っていることです。 + + + +openFrameworks のアドオンはコードのスニペットでも良いし、もっと複雑な OpenNI、Tesseract、Box2D のようなライブラリをラップしているかもしれません。アドオンの名前は通常 "ofx" という接頭辞から始まり、「中核」のコードと非中核のコードを容易に区別できます。加えて私たちは、例えば ofxOpenCv のように皆がおそらく利用したいが全てのプロジェクトで必須ではないようなアドオンを「コアアドオン」として同梱しています。 + + + +私たちは、アドオンを開発するコミュニテイを整え支援することを [http://ofxaddons.com](http://ofxaddons.com "ofxaddons, a collection of oF addons") というサイトを通じて行い、これは自動的に Github 上からタイトルに "ofx" という語彙を含むレポジトリを探すことでアドオンを収集しています。 + + + +### 他の人と一緒にやろう (Do it with others / DIWO) + + + +openFrameworks の背後にある強い哲学は「他の人と一緒にやろう (Do it with others / DIWO)」というものです。私たちは Instructables や Make といったチュートリアルサイトの興りによって盛んに宣伝され手がけられている「自分でやろう Do it yourself (DIY) カルチャーを愛しています。しかし私たちは「ソーシャルに作る」（他人と）というアイデアにも興奮します。私たちはワークショップ、デベロッパカンファレンス、ハッカソン/ラボ、knitting circle や個人的なミートアップ、メーリングリストやフォーラムでの投稿などのオンラインの形態を通じて DIWO を実践しています。私たちはギャングサインすら持っています。なぜなら一味となるときにはギャングサインを持つべきだからです。私たちが強調すべき最も大事な点は、あなたは独りではなく、学び、教え、ハックし、コードの創造的な側面を探索する人々の素晴らしいグループがいるということです。 From d18a7556fa74ff93036c1d20b3d677e397873808 Mon Sep 17 00:00:00 2001 From: Hiroyuki Kurosawa Date: Mon, 21 Jan 2019 00:41:21 +0900 Subject: [PATCH 2/8] =?UTF-8?q?=E6=97=A5=E6=9C=AC=E8=AA=9E=E3=81=AE?= =?UTF-8?q?=E8=AA=BF=E6=95=B4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- chapters/of_philosophy/chapter.ja.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/chapters/of_philosophy/chapter.ja.md b/chapters/of_philosophy/chapter.ja.md index 73bf62ea..a9582494 100644 --- a/chapters/of_philosophy/chapter.ja.md +++ b/chapters/of_philosophy/chapter.ja.md @@ -6,7 +6,7 @@ _by [Zach Lieberman](http://thesystemis.com)_ -openFrameworks の航海は幾つかのゴールによって導かれています：それは協働的であること、有用かつシンプルであること、一貫性があり直感的であること、クロスプラットフォーム、パワフルさ、そして拡張可能であることです。加えて"人と一緒にやろう（do it with others / (DIWO)" の哲学により推進されています。 +openFrameworks の航海は幾つかのゴールによってその指針が示されています：それは協働的であること、実用的かつシンプルであること、一貫性があり直感的であること、クロスプラットフォーム、パワフルさ、そして拡張可能であることです。加えて「人と一緒にやろう（do it with others / (DIWO)」の哲学により推進されています。 @@ -14,11 +14,11 @@ openFrameworks の航海は幾つかのゴールによって導かれていま -openFrameworks の開発は協働的なもので、議論に頻繁に参加して、アドオンやプロジェクトでのコラボレーションを行うたくさんの人々の貢献の上に成り立っています。私たちは皆が openFrameworks を自らの物とし、エコシステムに貢献することを推奨します。 +openFrameworks の開発は協働的なもので、議論に盛んに参加し、アドオンやプロジェクト上で協働する多くの人々の貢献の上に成り立っています。私たちは皆が openFrameworks を我が物とし、エコシステムに貢献することを推奨します。 -私たちは git という分散型バージョン管理システムを用いていて、これは人々がブランチを作り、実験し、提案が可能なことを意味します。[GitHub](https://github.com/openframeworks/openFrameworks "link to the GitHub repository of openFrameworks") のネットワーク図を見てみると、沢山の曲がりくねったブランチ、枝分かれしてまた合流するコードによるエイリアンのダイヤグラムのように見えます。コアのコードに対して作業する世界中にまたがる巨大なコミュニティが存在します：彼らはバグを修正し、プルリクエストを送り、見たいような形とするようなツールを具現化します。これは全世界的なプロジェクトであり、合衆国で目を覚ますとアジアやヨーロッパのプログラマからのプルリクエストやイシューの電子メールでいっぱいの INBOX を目にすることは日常茶飯事です。 +私たちは git という分散型バージョン管理システムを用いていて、これは人々がブランチを作り、実験し、提案が可能なことを意味します。[GitHub](https://github.com/openframeworks/openFrameworks "link to the GitHub repository of openFrameworks") のネットワーク図を見てみると、沢山の曲がりくねったブランチ、枝分かれしてまた合流するコードによるエイリアンのダイヤグラムのように見えます。コアのコードに対して作業する世界中にまたがる巨大なコミュニティが存在します：彼らはバグを修正し、プルリクエストを送り、見たいような形のツールを具現化します。これは全世界的なプロジェクトであり、合衆国で目を覚ますとアジアやヨーロッパのプログラマからのプルリクエストやイシューの電子メールでいっぱいの受信箱を目にすることは日常茶飯事です。 @@ -26,11 +26,11 @@ openFrameworks の開発は協働的なもので、議論に頻繁に参加し -openFrameworks は有用性とシンプルさのバランスを目指しています。openFrameworks の最初期のバージョンはその中核部分を C++ と [OpenGL](https://en.wikipedia.org/wiki/OpenGL "wikipedia article on OpenGL")を教えるツールとして利用していましたが、時を経るにつれて中核部分がより先進的な機能を取り入れるようになり、サンプル（examples）が学習のための最適な方法となりました。引き換えに、物事をシンプルにして実験のための改変可能なスタートポイントとするべく、私たちは openFrameworks に同梱される沢山のサンプルを作成しました。 +openFrameworks は有用性とシンプルさのバランスを目指しています。openFrameworks の最初期のバージョンは C++ と [OpenGL](https://en.wikipedia.org/wiki/OpenGL "wikipedia article on OpenGL")を教えるためのツールとしてその中核の部分を利用していましたが、時を経るにつれて中核部分がより先進的な機能を取り入れるようになり、サンプル（examples）が学習のための最適な方法となりました。引き換えに、物事をシンプルにし、それを実験のための改変可能なスタートポイントとするべく、私たちは openFrameworks に同梱される沢山のサンプルを作成しました。 -私たちは openFrameworks を可能な限り、特に他の言語や環境からきた人々にとってシンプルなものにしたいです。C++ は「大きな」言語であり、それは全く違うタイプの様々な C++ コードを書くことが出来るという意味です。書店に行けば何百もの C++ の書籍を目にするでしょう。私たちはあなた方が専門家になる必要なく、多くとも一冊か二冊の書籍が必要とし、コードのパターン、アプローチとスタイルはシンプルで直感的であるようなライブラリを作りたいです。私たちは [Processing](http://www.processing.org/ "processing language and IDE website") とある意味同質となること、つまり多くの機能が似通っていて一方のフレームワークから他方への移行が容易になることに特に関心を持っていました。 +私たちは openFrameworks を可能な限り、特に他の言語や環境から来た人々にとってシンプルなものにしたいです。C++ は「大きな」言語であり、それは全く違うタイプの様々な C++ コードを書くことが出来るという意味です。書店に行けば何百もの C++ の書籍を目にするでしょう。私たちはあなた方が専門家になる必要なく、多くとも一冊か二冊の書籍が必要とされ、コードのパターン、アプローチとスタイルはシンプルで直感的であるようなライブラリを作りたいです。私たちは [Processing](http://www.processing.org/ "processing language and IDE website") とある意味同質となること、つまり多くの機能が似通っていて一方のフレームワークから他方への移行が容易になることに特に関心を持っていました。 @@ -42,7 +42,7 @@ openFrameworks は一貫性があり直感的です：これは最小の驚き -学生ファーストであることがモットーです。openFrameworks を導く上で多く考えることは：私は 5 年か 10 年前だったらどんなツールを好んだか？コーディングのパターンはできる限りシンプルでタイピングしやすいものにしたい。これは動画のプレーヤにおいては "play" や "stop" といった自己言及的な関数名や直感的な変数名を持つことを意味します。直感的であることについては私たちは多くの議論を持っていますが、これはコードを出来るだけ素直な物にしたいという要求によっています。 +学生ファーストであることがモットーです。openFrameworks を導く上で多く考えることは：私は 5 年か 10 年前だったらどんなツールを好んだか？コーディングのパターンはできる限りシンプルでタイピングしやすいものにしたい。これは動画のプレーヤにおいては "play" や "stop" といった自己言及的な関数名や直感的な変数名を持つことを意味します。直感的であることについては私たちは数多く議論していますが、これはコードを出来るだけ素直な物にしたいという要求によっています。タイプすることによって学び、オートコンプリート機能は助けになる、等々。 @@ -50,7 +50,7 @@ openFrameworks は一貫性があり直感的です：これは最小の驚き -openFrameworks はクロスプラットフォームなツールキットです。openFrameworks は可能な限り多くの開発環境や OS をサポートします。openFrameworks をダウンロードをするには任意のプラットフォームや開発環境を選ぶことができ、学んだり遊んだりできるプロジェクトやサンプルを入手できます。移植が困難なコードは中核からは取り除かれ、代わりにアドオンの中に置かれます。 +openFrameworks はクロスプラットフォームなツールキットです。openFrameworks は可能な限り多くの開発環境や OS をサポートします。openFrameworks をダウンロードをするには任意のプラットフォームや開発環境を選ぶことができ、学んだり遊んだりできるプロジェクトやサンプルを入手できます。移植が困難なコードはコアの部分からは取り除かれ、代わりにアドオンの中に置かれます。 @@ -58,7 +58,7 @@ openFrameworks は多くのプラットフォーム：OS X、 Windows、 Linux -クロスプラットフォームなライブラリの良い点は、あなたのアイデアをプラットフォームをまたいで移植することが容易なことです。ラップトップ上でスケッチし、即座に電話機上で実行できます。プラットフォームをまたいで動作させる何かを作成するような退屈な仕事の心配をせずにアイデアを最優先にできるのです。 +クロスプラットフォームなライブラリの良い点は、あなたのアイデアをプラットフォームをまたいで移植することが容易なことです。ラップトップ上でスケッチし、即座に電話機上で実行できます。プラットフォームを超えて動作する何かを作成するような退屈な仕事の心配をせずにアイデアを最優先にできるのです。 @@ -70,7 +70,7 @@ openFrameworks はパワフルです：[OpenCV](http://opencv.org/ "OpenCV, a li -私たちが C++ を選択したのは、それがかなり低レベルな言語でありながら高レベルなやり方でプログラムすることが可能だからです。C++ はより古い C 言語の拡張なので、とても低レベルでオールドスクールな C コードや、より高級な C++ コードを記述できます。openFrameworks で、私たちは両方のアプローチを使い、シンプル、明瞭でありながらパワフルなコードとの関わりを提示します。C++ を利用することはまた、C や C++ で書かれた沢山のライブラリと他の言語のラッパに依存することなく接続することを容易にしています。 +私たちが C++ を選択したのは、それがかなり低レベルな言語でありながら高レベルなやり方でプログラムすることが可能だからです。C++ はより古い C 言語の拡張なので、とても低レベルでオールドスクールな C コードや、より高レベルな C++ コードを記述できます。openFrameworks で、私たちは両方のアプローチを使い、シンプル、明瞭でありながらパワフルなコードとの関わりを提示します。C++ を利用することはまた、他の言語のラッパに依存することなく C や C++ で書かれた沢山のライブラリと接続することを容易にしています。 @@ -82,7 +82,7 @@ openFramewoks は基本として OpenGL や [Cairo](http://cairographics.org/ "C -openFrameworks は拡張可能です。もし openFrameworks に足りない物を見つけた場合、拡張するアドオンを作成することは容易です。openFrameworks の中核のアドオンは概して斬新な方法で問題を解決するというよりはライブラリをラップしています。openFrameworks はライブラリをラップしていますが、それらのライブラリはさらなるハックのために露出されたままです。 +openFrameworks は拡張可能です。もし openFrameworks に足りない物を見つけた場合、拡張するアドオンを作成することは容易です。openFrameworks の中核のアドオンは斬新な方法で問題を解決するというよりは、概してライブラリをラップしています。openFrameworks はライブラリをラップしていますが、それらのライブラリはさらなるハックのために外部に露出されたままです。 @@ -90,7 +90,7 @@ openFrameworks は拡張可能です。もし openFrameworks に足りない物 -openFrameworks のアドオンはコードのスニペットでも良いし、もっと複雑な OpenNI、Tesseract、Box2D のようなライブラリをラップしているかもしれません。アドオンの名前は通常 "ofx" という接頭辞から始まり、「中核」のコードと非中核のコードを容易に区別できます。加えて私たちは、例えば ofxOpenCv のように皆がおそらく利用したいが全てのプロジェクトで必須ではないようなアドオンを「コアアドオン」として同梱しています。 +openFrameworks のアドオンはコードのスニペットでも良いし、またはもっと複雑な OpenNI、Tesseract、Box2D のようなライブラリをラップしているかもしれません。アドオンの名前は通常 "ofx" という接頭辞から始まり、「中核」のコードと非中核のコードを容易に区別できます。加えて私たちは、例えば ofxOpenCv のように、皆がおそらく利用したいが全てのプロジェクトでは必須でないようなアドオンを「コアアドオン」として同梱しています。 @@ -102,4 +102,4 @@ openFrameworks のアドオンはコードのスニペットでも良いし、 -openFrameworks の背後にある強い哲学は「他の人と一緒にやろう (Do it with others / DIWO)」というものです。私たちは Instructables や Make といったチュートリアルサイトの興りによって盛んに宣伝され手がけられている「自分でやろう Do it yourself (DIY) カルチャーを愛しています。しかし私たちは「ソーシャルに作る」（他人と）というアイデアにも興奮します。私たちはワークショップ、デベロッパカンファレンス、ハッカソン/ラボ、knitting circle や個人的なミートアップ、メーリングリストやフォーラムでの投稿などのオンラインの形態を通じて DIWO を実践しています。私たちはギャングサインすら持っています。なぜなら一味となるときにはギャングサインを持つべきだからです。私たちが強調すべき最も大事な点は、あなたは独りではなく、学び、教え、ハックし、コードの創造的な側面を探索する人々の素晴らしいグループがいるということです。 +openFrameworks の背後にある強い哲学は「皆と一緒にやろう (Do it with others / DIWO)」というものです。私たちは Instructables や Make といったチュートリアルサイトの興りによって盛んに宣伝され手がけられている「自分でやろう Do it yourself (DIY) カルチャーを愛しています。しかし私たちは「ソーシャルに作る」（皆と）というアイデアにも興奮します。私たちはワークショップ、デベロッパカンファレンス、ハッカソン/ラボ、手芸サークルや個人的なミートアップ、メーリングリストやフォーラムでの投稿などのオンラインの形態を通じて DIWO を実践しています。私たちはギャングサインすら持っています。なぜなら仲間となるときにはギャングサインを持つべきだからです。私たちが強調したい最も大事な点は、あなたは独りではなく、学び、教え、ハックし、コードの創造的な側面を追求する人々による素晴らしいグループがあるということです。 From c7ff3167f8bc02dfad1599ef3fe41cb3f67d4599 Mon Sep 17 00:00:00 2001 From: Hiroyuki Kurosawa Date: Mon, 21 Jan 2019 01:00:27 +0900 Subject: [PATCH 3/8] =?UTF-8?q?=E8=A1=A8=E7=8F=BE=E3=81=AE=E8=AA=BF?= =?UTF-8?q?=E6=95=B4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- chapters/cplusplus_basics/chapter.ja.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/chapters/cplusplus_basics/chapter.ja.md b/chapters/cplusplus_basics/chapter.ja.md index bb5097ed..b3ba727c 100644 --- a/chapters/cplusplus_basics/chapter.ja.md +++ b/chapters/cplusplus_basics/chapter.ja.md @@ -20,13 +20,13 @@ _by [Jetty Nimoy](http://jtn.im)_ ## Look Alive! --> -## 気をつけて！ +## ぐずぐるするな！ -このチャプターでは C++ 言語を用いて小さなコンピュータプログラムを書きます。事前の知識はとても少ないことを想定していますが、その他のトピックの大部分はこれの上に立脚しますので、このチャプターから得られるリテラシーはこの本の後続のチャプターの理解に直接的に影響します。さらに、ここでのレッスンは累積的なものなので、つまりトピックを飛ばせば迷子になってしまうでしょう。一つの概念で詰まってしまった場合、次のトピックに移動する前に理解できなかったパートを特に理解するための助けを得てください。このようにある意味厳格にレッスンを続けることで、openFrameworks だけでなくコンピュータ一般を最大限に活用できるようになるでしょう。 +このチャプターでは C++ 言語を用いて小さなコンピュータプログラムを書きます。事前の知識はとても少ないことを想定していますが、その他のトピックの大部分はこれの上に立脚しますので、このチャプターから得られるリテラシーはこの本の後続のチャプターの理解に直接的に影響します。さらに、ここでのレッスンは累積的なものなので、つまりトピックを飛ばせば迷子になってしまうでしょう。一つの概念で詰まってしまった場合、次のトピックに移動する前に理解できなかったパートをはっきりと理解するための助けを求めてください。このように、ある意味厳格にレッスンを続けることで、openFrameworks だけでなくコンピュータ一般を最大限に活用できるようになるでしょう。 -長いポニーテールに段のついた刈り上げと丸メガネを着けていて、リキテックス・ベーシックスのアクリル絵の具が飛び散り、浴び、こぼれ落ち、染みの無い衣服など着たことがなかった 90 年代の中盤の高校でのアートの AP 学生時代に私はドローイングやペインティングの多くを行いました。経済の授業に飽き飽きして TI-82 型グラフ計算機で遊んでいた時に、私は心の内に電気の灯るような物事を発見しました。生まれ育った家に転がっていた小さな計算機と違い、TI-82 には分厚い取扱説明書がありました。このマニュアルの中、三角法の関数やその他の無味乾燥な手の届かないサイエンスの章の間に、何か：図 1 に示すような、一回り小さな逆さまのピラミッドがその内側に無限にネストされているセクシーな白黒のピラミッド、が私の飢えた若き眼を奪いました。 +長いポニーテールに段のついた刈り上げと丸メガネを着けていて、リキテックス・ベーシックスのアクリル絵の具が飛び散り、浴び、こぼれ落ち、染みの無い衣服など着たことがなかった 90 年代の中盤の高校でのアートの AP 学生時代に私はドローイングやペインティングの多くを行いました。経済の授業に飽き飽きして TI-82 型グラフ計算機で遊んでいた時に、私は心の内に電気の灯るような物事を発見しました。生まれ育った家に転がっていた小さな計算機と違い、TI-82 には分厚い取扱説明書がありました。このマニュアルの中、三角法の関数やその他無味乾燥な手の届かない科学の章の間に、何か：図 1 に示すような、一回り小さな逆さまのピラミッドがその内側に無限にネストされているセクシーな白黒のピラミッドが、私の飢えた若き眼を奪いました。 -このフラクタル、有名な [Sierpinski triangle](https://www.wolframalpha.com/input/?i=sierpinski+triangle) には完全なシェルピンスプログラムを構成する 25 行あまりのコンピュータの命令が添えられていました。私は幾つかの数値演算も見ながらコードを仔細に調べました - 何も高度すぎることはなく、ほとんどのものは命令する言葉で、「これをせよ」や「もし何々ならば他のことをせよ」のようなものでした。私は書籍からグラフ計算機のコードに打ち込んでグラフ計算機でプログラムを実行することができました。最初はただの空白の液晶パネルです。徐々にいくつかのランダムなピクセルがあちこちで黒く切り替わりますが特に法則性は見出せません。さらに何秒かするとシーンが満たされ、すでにトライアングルの輪郭がかすかに見えてきます。十分な時間が経過すると、計算機はついに書籍のものとぴったり一致しました。私の気持ちははっきりとぶっ飛びました。はっきりとは意味がわかりませんでした。どのような自然の神秘がこんなにわずかな命令からこのような複雑な形態を生み出すのか？画面には 6,000 ピクセルがあり、わずか 25 行の命令がこの驚くべき生物のようなアートワークを生み出すに足るのだろうか？これは誰のアートワークなのか？私は新しい作品をそこから派生しうるのか？それまで私はごくわずかの仕事からこれほどの魔法のような褒美を得られたことはほとんどありませんでした。私は新たな礎を発見しました。私はそれが重要（だと私が決めたので）プログラムを理解する必要性を感じました。私はコードに戻って数値のいくつかを変更し、プログラムをもう一度実行しました。スクリーンは空白になり、異なった画像を描きました。今回だけは左に歪み、ビューポートからはみ出してしまいました。私は勇気を出して英語の命令の一つを変更し、そしてマシンはエラーを出し、実行に失敗しました。 +このフラクタル、有名な [Sierpinski triangle](https://www.wolframalpha.com/input/?i=sierpinski+triangle) には完全なシェルピンスプログラムを構成する 25 行あまりのコンピュータの命令が添えられていました。私は幾つかの数値演算も見ながらコードを仔細に調べました - 何も高度すぎることはなく、ほとんどのものは命令する言葉で、「これをせよ」や「もし何々ならば他のことをせよ」のようなものでした。私は書籍からグラフ計算機にコードを打ち込み、プログラムを実行することができました。最初はただの空白の液晶パネルです。徐々にいくつかのランダムなピクセルがあちこちで黒く切り替わりますが特に法則性は見出せません。さらに何秒かすると画面が満たされ、すでにトライアングルの輪郭がかすかに見えてきます。十分な時間が経過すると、計算機はついに書籍のものとぴったり一致しました。私の気持ちははっきりいってぶっ飛びました。明確には意味がわかりませんでした。どのような自然の神秘がこんなにわずかな命令からこのような複雑な形態を生み出すのか？画面には 6,000 ピクセルがあり、わずか 25 行の命令がこの驚くべき生物のようなアートワークを生み出すに足るのだろうか？これは誰のアートワークなのか？私は新しい作品をそこから派生しうるのか？それまで私はそれほどにごくわずかの仕事からこれほどの魔法のような報いを得られたことはほとんどありませんでした。私は新たな礎を発見しました。私はそれが重要（だと私が決めたので）プログラムを理解する必要性を感じました。私はコードに戻って数値のいくつかを変更し、プログラムをもう一度実行しました。スクリーンは空白になり、異なった画像を描きました。今回だけは左に歪み、ビューポートからはみ出してしまいました。私は勇気を出して英語の命令の一つを変更し、そしてマシンはエラーを出し、実行に失敗しました。 -図 2 に示しているサイクルは私が何十年も実行する楽しみを感じており今なお愛している無限に繰り返されるループです。プログラムを作成することが何を意味するのか、そしてソフトウェア芸術を創ることが何を意味するのかを追求する中で、どんな新しいサイクルも私を驚かせなかったことはありません。コンピュータ命令のリストが繰り返し進化していくプロセスは芸術的な報いであると同時にロジカルな挑戦でもあります。これらの挑戦は、特に他の皆との協働や支援を得られる時、または問題をより小さな課題に分割できるときにはほとんど解決できないということはありません。もし Processing や JavaScript、または HTML と CSS などの他の環境でコードを書いたことがあれば、この最初の大事なレッスンはわかりきったものかもしれません。 +図 2 に示しているサイクルは私が何十年も実行する楽しみを感じており今なお愛している、無限に繰り返されるループです。プログラムを作成することが何を意味するのか、そしてソフトウェア芸術を創ることが何を意味するのかを追求する中で、どんな新しいサイクルも私を驚かせなかったことはありません。コンピュータ命令のリストが繰り返し進化していくプロセスは芸術的な報いであると同時にロジカルな挑戦でもあります。これらの挑戦は、特に他の皆との協働や支援を得られる時、または問題をより小さな課題に分割できるときにはほとんど解決できないということはありません。もし Processing や JavaScript、または HTML と CSS などの他の環境でコードを書いたことがあれば、この最初の大事なレッスンは明白なものかもしれません。 -小さなプログラムを記述することにこれから慣れ親しんでいく皆さんにとって、コードを書くプロセスにある繰り返しの性質を理解することは大切です。図 3 の挿話はこのプロセスでは「ありません」。エディタにたった一度だけコードを記述し、コンパイルを叩いて完成品を期待できることはほとんどないでしょう。これは自然で、小さなプログラムから始め、多くの失敗（バグ）を持っていて、望む結果や挙動に向かってゆっくりと進化していくことが通常受け入れられています。事実、事前の推測は全くのプログラマのミスであることはよくあることです。プログラムが紙に書かれていた昔の時代でさえも、作者は執拗にコードを睨みつけて間違いを直す必要がありました：つまりこのプロセスは反復的なものなのです。C++ 言語を学ぶにあたって、私はあなたのマシンでコンパイルできる小さなコードサンプルを提示します。変則的なパートはこの本からエディタにコードをタイプすることですが、（あなたの指が滑らない限り）プログラムは魔法のように動作します。私はわざと問題解決の経験を除いていますが、C++ 言語そのものの問題によるものを分離するためです。続いて、トピック毎によくある「デバッグ」（エラーの修正）作業にとりかかります。 +小さなプログラムを記述することにこれから慣れ親しんでいく皆さんにとって、コードを書くプロセスにある繰り返しの性質を理解することは大切です。図 3 の挿話はこのプロセスでは「ありません」。エディタにたった一度だけコードを記述し、コンパイルを叩いて完成品を期待できることはほとんどないでしょう。小さなプログラムから始まり、多くの失敗（バグ）を持っていて、望む結果や挙動に向かってゆっくりと進化していくことは自然で、通常受け入れられています。事実、事前の推測は全くのプログラマの誤りであることはよくあることです。プログラムが紙に書かれていた昔の時代でさえも、作者は執拗にコードを睨みつけて間違いを直す必要がありました：つまりこのプロセスは反復的なものなのです。C++ 言語を学ぶにあたって、私はあなたのマシンでコンパイルできる小さなコード例を提示します。変則的な部分はこの本からエディタにコードをタイプすることですが、（あなたの指が滑らない限り）プログラムは魔法のように動作します。私はわざと問題解決の経験を除いていますが、C++ 言語そのものの問題によるものを分離するためです。後ほど、よくある「デバッグ」（エラーの修正）作業それ自体のトピックにも取り組みます。 -できる限り最も小さく、直接的な C++ プログラムから始め、その便利な環境をこのチャプターを通して C++ コードをテストするために利用しましょう。このために私たちは「コンパイラ」が必要ですが、これは何らかのコードを実行可能なアプリ、しばしば実行可能ファイルとも言われるものに翻訳します。C++ コンパイラの大部分は無料でダウンロード可能で、多くの場合がオープンソースです。私たちが生成するアプリは自動的に Apple の App Store、Google Play、Steam、Ubuntu Apps Directory や Pi Store のような場所には現れません。その代わり、それらは個人的でプライベートなプログラムであり、後から手動で共有することにあなたは責任を持っています。続くチャプターの "oF Setup and Project Structure" では、コンパイラはあなたのローカルコンピュータに存在し、オフラインで動作するでしょう。今は我慢して、Sphere Research Labs による便利なツールで 簡単な C++ を Web 上でコンパイルしましょう。ブラウザを開いて [ideone](http://ideone.com) (http://ideone.com) に行きましょう。 +できる限り最も小さく、直接的な C++ プログラムから始め、その便利な環境をこの章を通して C++ コードをテストするために利用しましょう。このために私たちは「コンパイラ」が必要ですが、これは何らかのコードを実行可能なアプリ、しばしば実行可能ファイルとも言われるものに翻訳します。C++ コンパイラの大部分は無料でダウンロード可能で、多くの場合がオープンソースです。私たちが生成するアプリは自動的に Apple の App Store、Google Play、Steam、Ubuntu Apps Directory や Pi Store のような場所には現れません。その代わり、それらは個人的でプライベートなプログラムファイルであり、後から手動で共有することにあなたは責任を持っています。続くチャプターの "oF Setup and Project Structure" では、コンパイラはあなたのローカルコンピュータに存在し、オフラインで動作するでしょう。今は我慢して、Sphere Research Labs による便利なツールで 簡単な C++ を Web 上でコンパイルしましょう。ブラウザを開いて [ideone](http://ideone.com) (http://ideone.com) に行きましょう。 -![Figure 4](images/where-is-says-java.png "Figure 4") +![図4](images/where-is-says-java.png "図4") -エディタのコードが変化し、図 6 のようになることに注目してください。 +エディタのコードが変化し、図6 のようになることに注目してください。 -![Figure 6](images/empty-template.png "Figure 6") +![図6](images/empty-template.png "図6") -これはただの空のコードの雛形で、何もせず、エラーも起きません。左手の溝の数字はコードの行数を示しています。"Run" というラベルのついた緑のボタンを押します。コメント欄にコードのコピーと "Success" が現れ、"stdin"（標準入力）とラベルのあるエリアは空っぽです。"stdout"（標準出力）も同様に空です。 +これはただの空のコードの雛形で、何もせず、エラーも起きません。左手の列にある数字はコードの行数を示しています。"Run" というラベルのついた緑のボタンを押します。コメント欄にコードのコピーと "Success" が現れ、"stdin"（標準入力）とラベルのあるエリアは空っぽです。"stdout"（標準出力）も同様に空です。 -Web 上の大部分のフォントは可変幅であり、つまり各文字は異なった横幅です；目には読み易いです。フォントには固定幅のものもあり、これは全ての文字（W と小文字の i でさえも）が同じ横幅です。これはタイプライターのように変わって奇妙に見えるかもしれませんが、重要な目的を担います。固定幅のフォントはテキストのブロックをゲーム版のようなもの、たとえばチェス盤や方眼紙のようなものにします。コンピュータプログラムのコードは通常固定幅の書式設定で表示されますが、これはそれがアスキーアートの様式だからです。インデント、ホワイトスペース文字、および繰り返しパターンは重要であり、保存して肉眼で比較することを容易にします。芸術家の Jeremy Rotsztain を除く私の知る全てのプログラマは彼らのコードに単一幅のフォントの何らかの様式を用いています。タイプフェイスの提案の例は Courier、Andale Mono、Monaco、Profont、Monofur、Proggy、Droid Sans Mono、Deja Vu Sans Mono、Consolas、そして Inconsolata などです。今後`このインラインスタイル` . . . +Web 上の大部分のフォントは可変幅であり、つまり各文字の横幅は異なっています；目には読み易いです。フォントには固定幅のものもあり、これは全ての文字（W と小文字の i でさえも）が同じ横幅です。これはタイプライターのように奇妙で風変わりに見えるかもしれませんが、重要な目的を担います。固定幅のフォントはテキストのブロックをゲーム版のようなもの、たとえばチェス盤や方眼紙のようなものにします。コンピュータプログラムのコードは通常固定幅の書式設定で表示されますが、これはそれがアスキーアートの様式だからです。インデント、ホワイトスペース文字、および繰り返しパターンは重要であり、保存して肉眼で比較することを容易にします。芸術家の Jeremy Rotsztain を除く私の知る全てのプログラマは彼らのコードに単一幅のフォントの何らかの様式を用いています。タイプフェイスの提案の例は Courier、Andale Mono、Monaco、Profont、Monofur、Proggy、Droid Sans Mono、Deja Vu Sans Mono、Consolas、そして Inconsolata などです。今後 `このインラインスタイル` . . . ```cpp -nそしてこのブロック中のスタイル . . . +そしてこのブロック中のスタイル . . . ``` -2 つのスラッシュから始まる行はコメントと呼ばれます。あなたが理解できる方法で注釈をつけるために、何で記述することができます。スラッシュを 2 つ前方に置くことで"コードのコメントアウト"をすると便利なことがあります、なぜならばこれで C++ のコードを削除せずに無効化することができるからです。C++ でのコメントは複数行に渡ったり、タグのように挿入されることもできます。コメントモードの開始と終了の構文は異なります。`/* と */`の間の全てがコメントになります： +2 つのスラッシュから始まる行はコメントと呼ばれます。あなたが理解できる方法で注釈をつけるために、何で記述することができます。スラッシュを 2 つ前方に置くことで「コードのコメントアウト」をすると便利なことがあります、なぜならばこれで C++ のコードを削除せずに無効化することができるからです。C++ でのコメントは複数行に渡ったり、タグのように挿入されることもできます。コメントモードの開始と終了の構文は異なります。`/* と */`の間の全てがコメントになります： -このコード行は暗黙の _標準出力_ (別名 _stdout_)として知られるテキスト空間に "Hello World" と言うように命令しています。プログラムを記述するときに、_stdout_ が存在することは期待しても安全です。このプログラムはそこにテキストを"プリント"するでしょう。別の時には、ただのトラブルシューティングに使われるコーディング環境のウインドウペインとなります。 +このコード行は暗黙の _標準出力_ (別名 _stdout_)として知られるテキスト空間に対して "Hello World" と言うように命令しています。プログラムを記述するときに、_stdout_ は存在すると思っていても安全です。このプログラムはそこにテキストを「プリント」するでしょう。別の時には、標準出力はただのトラブルシューティングに使われるコーディング環境のウインドウペインとなります。 -引用符の間にはほとんどどんなものでも入れることが可能です。引用されたフレーズは文章の _文字列(string)_ と呼ばれます。より厳密には、これは*C 文字列リテラル* です。ストリングについてはこの章の後ろでさらにカバーします。このコードで `cout <<` の塊のパートは「以降のものを標準出力に整形して出力せよ」という意味です。最後の `<< endl` のパートは「キャリッジリターン（行の終わり）文字を hello world メッセージの末尾に追加せよ」の意味です。最後に、このコード行の一番最後にセミコロン(;)があります。 +引用符の間にはほとんどどんなものでも入れることが可能です。引用されたフレーズは文章の _文字列(string)_ と呼ばれます。より厳密には、これは*C 文字列リテラル* です。ストリングについてはこの章の後ろでさらにカバーします。このコードで `cout <<` の塊の部分は「以降のものを標準出力に整形して出力せよ」という意味です。最後の `<< endl` のパートは「キャリッジリターン（行の終わり）文字を hello world メッセージの末尾に追加せよ」の意味です。最後に、このコード行の一番末尾にはセミコロン(;)があります。 -C++ では、セミコロンは文の終わりの終止符あるいはピリオドのようなものです。それぞれの宣言の最後にはセミコロンをタイプしなければならず、これは通常はコードの行の末尾にあります。もしセミコロンをタイプするのを忘れた場合、コンパイルは失敗します。セミコロンは 1 行に複数の宣言があることや、一つの宣言で複数の行を使うことを許容し、プログラマがホワイトスペースによって柔軟で表現豊かであると感じることができるために有用なものです。セミコロンを追加することで、コンパイラが混乱しないことを確実にします：あなたが手助けをして、どこで宣言が終了するかを示してあげるのです。始めて C や C++ を学ぶ際、セミコロンを忘れることはとてもよくあるミスたり得ますが、それでもこれはコードをコンパイルするために必要なものです。十二分に注意してコードの宣言はセミコロンで終了するようにしてください。 +C++ では、セミコロンは文の終わりの終止符あるいはピリオドのようなものです。それぞれの宣言の最後にはセミコロンをタイプしなければならず、これは通常はコードの行の末尾にあります。もしセミコロンをタイプするのを忘れた場合、コンパイルは失敗します。セミコロンは 1 行に複数の宣言があることや、一つの宣言で複数の行を使うことを許容し、ホワイトスペースによって柔軟で表現豊かであるとプログラマが感じることができるために便利なものです。セミコロンを追加することで、コンパイラが確実に混乱しないようにします：あなたが手助けをして、どこで宣言が終了するかを示してあげるのです。初めて C や C++ を学ぶ際、セミコロンを忘れることはとてもよくあるミスたり得ますが、それでもこれはコードをコンパイルするために必要なものです。十二分に注意してコードの宣言はセミコロンで終了するようにしてください。 -タイプすると、テキストが自動でマルチカラーに色付けされることに気づくかもしれません。この便利な機能は _シンタックスカラーリング_（またはシンタックスハイライト）と呼ばれ、コードを読んだり、変なシンタックスのトラブルシューティングや検索を支援する能力を潜在的に向上させます。ツールはそれぞれ独自のシンタックスカラーリングシステムを持っているので、もし色を変えたいと思った場合、色がドキュメントそのものに追加されるようなワープロと同じではないと考えてください。コードエディタは "TRON.TTF" フォントを光るアクアカラーを `endl` （これは行末を意味します）_だけ_ に割り当てることを許しません。代わりに、シンタックスの種類全部のために特別なスタイルを選び、それがそのタイプのコードである限りコードの全てのパーツがその方法でスタイル付けされて見ることができます。このケースでは、`cout` と `endl` の両方がキーワードと見なされるので、ツールはそれらを黒く色付けします。もしこれらが他の場所で別の色で現れた場合も、コードは以前と同じであることを信じてください。なぜなら異なるコードエディタは別のシンタックスカラーリングを提供しているからです。今はコード全体はこのように見えています： +タイプすると、テキストが自動で複数色に色付けされることに気づくかもしれません。この便利な機能は _シンタックスカラーリング_（またはシンタックスハイライト）と呼ばれ、コードを読んだり、変なシンタックスのトラブルシューティングや検索を支援する潜在的な能力を向上させます。ツールはそれぞれ独自のシンタックスカラーリングシステムを持っているので、もし色を変えたいと思った場合、色がドキュメントそのものに追加されるようなワープロと同じではないと考えてください。コードエディタは "TRON.TTF" フォントを光るアクアカラーを `endl` （これは行末を意味します）_だけ_ に割り当てることを許しません。代わりに、シンタックスの種類全部のために特別なスタイルを選び、それがその種類のコードである限りコードの全てのパーツがその方法でスタイル付けされて見ることができます。このケースでは、`cout` と `endl` の両方がキーワードと見なされるので、ツールはそれらを黒く色付けします。もしこれらが他の場所で別の色で現れた場合も、コードは以前と同じであることを信じてください。なぜなら異なるコードエディタは別のシンタックスカラーリングを提供しているからです。今はコード全体はこのように見えています： -今度は右下の角にある緑の _ideone it!_ ボタンを押下し、コードエディタの下半分、ちょうど緑のボタンの上の出力コンソールを見ましょう。 「コンパイル待ちです(Waiting for compilation）」「コンパイル（Compilation）」「実行中（Running）」というようなオレンジのステータスメッセージが表示されるでしょう。すぐ後に、プログラムはクラウド上で実行されて標準出力が Web ページに表示されます。図 8 にあるメッセージが出るでしょう。 +今度は右下の角にある緑の _ideone it!_ ボタンを押下し、コードエディタの下半分、ちょうど緑のボタンの上の出力コンソールを見ましょう。 「コンパイル待ちです（Waiting for compilation）」「コンパイル（Compilation）」「実行中（Running）」というようなオレンジのステータスメッセージが表示されるでしょう。すぐ後に、プログラムはクラウド上で実行され標準出力が Web ページに表示されます。図 8 にあるメッセージが出るでしょう。 -ここまでやりきりました。あなた自身を褒めてください。あなたはたった今最初の C++ コードを書きました；分析し、コンパイルし、実行し、出力をご覧ください。 +ここまでやりきりました。あなた自身を褒めてください。あなたはたった今最初の C++ コードを書きました；それを分析し、コンパイルし、実行し、出力を見ました。 -Java や CSS での _import_ と同様、`#include` はコンパイラに _iostream.h_ というファイルから他の有用なコードをファイルのその場所にカット＆ペーストするように告げるようなものなので、あなたの新しいコードはそのコードに依存することができます。このケースでは、iostream.h は `cout` と `endl` を私のコードの中で、それらの名前をタイプするだけで利用できるツールとして _提供_ します。C++ では、**.h** で終わるファイル名はヘッダファイルと呼ばれ、これはファイル名が **.cpp** で終わる C++ の実際の実装ファイルでインクルードするであろうコードを含んでいます。標準ヘッダが C++ には沢山組み込まれて様々な基本的なサービスを提供しています - 事実、ここで挙げるには多すぎます。もしそれで十分でなければ、プロジェクトに外部のライブラリを、そのヘッダをインクルードすることで追加することはよくあることです。あなたが記述する」k〜どの一部としてヘッダファイルを定義することもできますが、構文はやや異なります： +Java や CSS での _import_ と同様、`#include` はコンパイラに _iostream.h_ というファイルから他の有用なコードをファイルのその場所にカット＆ペーストするように告げるようなものなので、あなたの新しいコードはそのコードに依存することができます。このケースでは、iostream.h は `cout` と `endl` を私のコードの中で、それらの名前をタイプするだけで利用できるツールとして _提供_ します。C++ では、**.h** で終わるファイル名はヘッダファイルと呼ばれ、これはファイル名が **.cpp** で終わる C++ の実際の実装ファイルからインクルードするであろうコードを含んでいます。標準ヘッダが C++ には沢山組み込まれて、様々な基本的なサービスを提供しています - 事実、ここで挙げるには多すぎます。もしそれで十分でなければ、プロジェクトに外部のライブラリを、そのヘッダをインクルードすることで追加することはよくあることです。あなたが記述するコードの一部としてヘッダファイルを定義することもできますが、構文はやや異なります： -これが全体像ですが、概念は理解する価値があります。include 宣言は実際には C++ コードではありません（セミコロンがないことに注目してください）。これは完全に分離されたコンパイラのパスの一部分で _プリプロセッサ_ と呼ばれます。これは実際のプログラムの命令が処理される前に行われます。これらはコンパイル後に実行されるコンピュータへの命令に対して、コードのコンパイラに対する命令のようなものです。ポンド/ハッシュ記号をこれら _プリプロセッサ命令（preprocessor directives）_ の前に使うことで、人はファイル中で明確かつ十分な理由をもって、これらを見つけることができます。これらは異なる言語が、実際の C++ コードに混ざっているように見えるでしょう。C++ プリプロセッサ命令は多くはありません - それらはほとんどその他のコードを集めることに関連します。これらのいくつかを見るでしょう。 +これは全体像ですが、概念は理解する価値があります。include 宣言は実際には C++ コードではありません（セミコロンがないことに注目してください）。これは完全に分離されたコンパイラのパスの一部分で _プリプロセッサ_ と呼ばれます。これは実際のプログラムの命令が処理される前に行われます。これらはコンパイル後に実行されるコンピュータへの命令に対して、コードのコンパイラに対する命令のようなものです。ポンド/ハッシュ記号をこれら _プリプロセッサ命令（preprocessor directives）_ の前に使うことで、人はファイル中で明確かつ十分な理由をもって、これらを見つけることができます。これらは異なる言語が、実際の C++ コードに混ざっているように見えるでしょう。C++ プリプロセッサ命令は多くはありません - それらはほとんど他のコードを集めることに関連します。こんなものを見かけるでしょう。 コンパイラがエラーを発見し、プログラムは実行されません。代わりに、あなたがこれを修正するのを助ける為の試みとして、コンパイラはどこでわからなくなったかを示します。最初のパート、_prog.cpp_: はエラーのあるファイルを教えています。このケースでは、ideone.com がデフォルトのファイル名であなたのコードを保存しています。次に、`In function 'int main()'`: -　とありますが、エラーを含んでいる特定の部分を示していて、この例では、_main_ という関数の {中括弧} の中です。（関数と中括弧については後ほど触れます）次の行には、`prog.cpp:5:2:`とあります。5 はファイルの最初から何業あるか、そして 2 は行の始めから右方向に何文字あるかです。次に、`error: 'cout' was not declared in this scope` というものがあります。これは何がコード中でエラーと思われているかを記述しています。この例では、これはかなり正しいです。iostream.h が無くなっていて、それにより `cout` が我々に提供されておらず、したがって "Hello World" を送信しようとした時に、コンパイラが失敗しているわけです。続く 2 行には、疑わしい `cout` を含むコード行があり、そしてその下の行には小さな上向きのキャレットがあって、これはコード中の文字を指している矢印と推察できます。このケースではこの矢印は `cout` の `c` を指しています。システムはどのトークンが誤りか視覚的に示しているわけです。二つ目のエラーが表示されていて、今度はコンパイラは endl が無いと訴えています。もちろん、このエラーを修正するには `` をインクルードすることを私たちは知っていますので、これをやりましょう。1 行目のコメントを解除してコードを再実行してください。 +　とありますが、エラーを含んでいる具体的な場所を示していて、この例では、_main_ という関数の {中括弧} の中です。（関数と中括弧については後ほど触れます）次の行には、`prog.cpp:5:2:`とあります。5 はファイルの最初から何行あるか、そして 2 は行の始めから右方向に何文字あるかです。次に、`error: 'cout' was not declared in this scope` というものがあります。これは何がコード中でエラーと思われているかを記述しています。この例では、これはかなり正しいです。iostream.h が無くなっていて、それにより `cout` が我々に提供されておらず、したがって "Hello World" を送信しようとした時に、コンパイラが失敗しているわけです。続く 2 行には、疑わしい `cout` を含むコード行があり、そしてその下の行には小さな上向きのキャレットがあって、これはコード中の文字を指している矢印と推察できます。このケースではこの矢印は `cout` の `c` を指しています。システムはどのトークンが誤りか視覚的に示しているわけです。二つ目のエラーが表示されていて、今度はコンパイラは endl が無いと訴えています。もちろん、このエラーを修正するには `` をインクルードすることを私たちは知っていますので、これをやりましょう。1 行目のコメントを解除してコードを再実行してください。 -2 行目には以下があります： +2 行目に行くと、以下があります： -とある SNS に入会して、ユーザー名を選択するように言われたとしましょう。私の名前は Mx. Jetty Nimoy なので - ユーザー名は JNIMOY でしょうか。私はページを送信するとエラーが返され、私の父である Joseph Nimoy が以前に登録して彼がすでに JNIMOY を取得してしまっていたので、そのユーザー名はすでに取得されていて別のものを選択しなければならないと言われました。ですので私はミドルネームのイニシャルである T を用い、固有な JTNIMOY というユーザー名を作成します。私は _名前空間（namespace）の衝突_ を生み出し、解決しました。名前空間は固有な名前のグループで - 一つとして重複していません。同一の名前が存在することは、それらが別の 2 つの名前空間にある限りにおいて可能です。名前空間はプログラマが他人のシンボルを上書きしてしまったり、良い名前を占有するなどしてお互いに不愉快になることの無いように助けてくれます。名前空間はまた、探しているものを見つけることを助けるためのすっきりと整理された管理システムを提供しています。openFrameworks では、全て `of` から始まっています . . . `ofSetBackground` とか `ofGraphics` のような感じです。これは名前空間を分割する一つのテクニックで、なぜならば他人が作成した別の名前が `of` から始まることはあまりなさそうだからです。同じテクニックが OpenGL でも使われています。OpenGL API（Application Programming Interface）の全ての名前は `glBlendFunc` や `glPopMatrix` のように `gl` から始まっています。C++ ではしかしながら言語が名前空間の構文を提供しているため、名前に必ずしも厳密にお行儀の良い接頭辞を付ける必要はありません。2 行目では、`using namepace std;` がコンパイラにこの .cpp ファイルは全ての名前を `std` 名前空間の中で使おうとしていることを伝えています。ネタバレ注意！これらの 2 つの名前は `cout` であり `endl` です。実験として 2 行目をコメントアウトし、実行してください。コンパイラはどんなエラーを返すと思いますか？ +とある SNS に入会して、ユーザー名を選ぶように言われたとしましょう。私の名前は Mx. Jetty Nimoy なので - ユーザー名は JNIMOY でしょうか。私がページを送信するとエラーが返され、私の父である Joseph Nimoy が以前に登録し彼がすでに JNIMOY を取得してしまっていたので、そのユーザー名はすでに取得されていて別のものを選択しなければならないと言われました。ですので私はミドルネームのイニシャルである T を用い、固有な JTNIMOY というユーザー名を作成します。私は _名前空間（namespace）の衝突_ を生み出し、解決しました。名前空間は固有な名前のグループで - 一つとして重複していません。同一の名前が存在することは、それらが別の 2 つの名前空間にある限りにおいてあり得ます。名前空間はプログラマが他人のシンボルを上書きしてしまったり、良い名前を占有するなどしてお互いに不愉快になることの無いように助けてくれます。名前空間はまた、探しているものを見つけることを助けるためのすっきりと整理された管理システムを提供しています。openFrameworks では、全て `of` から始まっています . . . `ofSetBackground` とか `ofGraphics` のような感じです。これは名前空間を分割する一つのテクニックで、なぜならば他人が作成した別の名前が `of` から始まることはあまりなさそうだからです。同じテクニックが OpenGL でも使われています。OpenGL API（Application Programming Interface）の全ての名前は `glBlendFunc` や `glPopMatrix` のように `gl` から始まっています。C++ ではしかしながら言語が名前空間の構文を提供しているため、名前に必ずしも厳密にお行儀の良い接頭辞を付ける必要はありません。2 行目では、`using namepace std;` がコンパイラにこの .cpp ファイルは全ての名前を `std` 名前空間の中で使おうとしていることを伝えています。ネタバレ注意！これらの 2 つの名前は `cout` であり `endl` です。実験として 2 行目をコメントアウトし、実行してください。コンパイラはどんなエラーを返すと思いますか？ -コンパイラは「ねえ、`cout` を探したんだけどファイルでインクルードされている名前空間の一つから見つけたよ。これがそれさ。`std::cout`」といっていて、この例ではコンパイラは正解です。`cout` とタイプする際に _より明示的に_ することを求めていますので、それの名前空間である `std`（standard）を左側に示し、2 つのコロン（::）を続けます。これは私自身を `Nimoy::Jetty` と呼ぶようなものです。実験を続け、5 行目を編集して `cout` と `endl` に明示的な名前空間が付加されるようにしましょう。 +コンパイラは「ねえ、`cout` を探したんだけどファイルでインクルードされている名前空間の一つから見つけたよ。これがそれさ。`std::cout`」と言っていて、この例ではコンパイラは正解です。`cout` とタイプする際に _より明示的に_ することを求めていますので、それの名前空間である `std`（standard）を左側に示し、2 つのコロン（::）を続けます。これは私自身を `Nimoy::Jetty` と呼ぶようなものです。実験を続け、5 行目を編集して `cout` と `endl` に明示的な名前空間が付加されるようにしましょう。 -コードを実行すると、正常にコンパイルされて、"Hello World" とプリントすることに成功すると思います。`using namespace std;` と書いている行はコメントアウトされているのにです。歌の歌詞をランダムに生成するプログラムを書いていると想像してください。明らかに、`cout` をかなり使うと思います。全ての `cout` の前に `std::` とタイプすることはとても退屈ですし、プログラミング言語がこの機能を追加している理由の一つはタイプ量を減らすことです。ですので 2 行目の `using namespace std;` は必須では無いのですが、それが（他の `using namespace` 宣言と共に）存在することで、C++ コードを暗黙的なコンテキストによって読み書きしやすくできるのです。 +コードを実行すると、正常にコンパイルされて、"Hello World" と出力することに成功すると思います。`using namespace std;` と書いている行はコメントアウトされているのにです。歌の歌詞をランダムに生成するプログラムを書いていると想像してください。明らかに、`cout` をかなり使うと思います。全ての `cout` の前に `std::` とタイプすることはとても退屈ですし、プログラミング言語がこの機能を追加している理由の一つはタイプ量を減らすことです。ですので 2 行目の `using namespace std;` は必須では無いのですが、それが（他の `using namespace` 宣言と共に）存在することで、C++ コードを暗黙的なコンテキストによって読み書きしやすくできるのです。 -これが初めての開始と終了を持つコード片で、ですので他のコード片を "包んで" います。しかしより大事なことは、関数はその中に入っている宣言を _代表している_ ということです。この _関数（function）_ の終了は 7 行目の閉じかっこです。 +これが初めての開始と終了を持つコード片で、ですので他のコード片を「包んで」います。しかしより大事なことは、関数はその中に入っている宣言を _代表している_ ということです。この _関数（function）_ の終了は 7 行目の閉じかっこです。 -関数を定義する際、最初のトークンは宣言された戻り値の型です。関数は値を戻すことができますが、質問に対する答え、問題に対する解法、タスクの結果、または加工処理の生産物のようなものです。このケースでは、 _main_ は分数や少数の無い数字の全体を指す `int`、または _整数値_ の一つを返すと約束しています。次のトークンは関数の名前です。システムは "main" という語は全て小文字であることを期待しますが、後ほどあなた独自の関数を定義し、名前付けに取り組みましょう。次は始めおよび終わり丸括弧です。そうですね、これには何も中に無いので、そこに存在することが奇妙に見えるかもしれません。後でここになにが入るのかを見ていきましょう - しかし関数から括弧を省くことの無いようにしてください、なぜならばある意味でこれは人間に対してこれが関数であるという主要なヒントだからです。事実、今後私は関数を名前で読んでいきます。そして例えば関数が引数を必要としない場合には `main()` のようにそれに()を付加し、関数が一つかそれ以上の引数を要求する場合には `main(...)` のようにそれに(...)を付加します。 +関数を定義する際、最初のトークンは宣言された戻り値の型です。関数は値を戻すことができますが、質問に対する答え、問題に対する解法、タスクの結果、または加工処理における製品のようなものです。このケースでは、 _main_ は分数や少数の無い数字の全体を指す `int`、または _整数値_ の一つを返すと約束しています。次のトークンは関数の名前です。システムは "main" という語は全て小文字であることを期待しますが、後ほどあなた独自の関数を定義し、名前付けに取り組みましょう。次は始めおよび終わり丸括弧です。そうですね、これには何も中に無いので、そこに存在することが奇妙に見えるかもしれません。後でここになにが入るのかを見ていきましょう - しかし関数から括弧を省くことの無いようにしてください、なぜならばある意味でこれは人間に対してこれが関数であるという主要なヒントだからです。事実、今後私は関数を名前で読んでいきます。そして例えば関数が引数を必要としない場合には `main()` のようにそれに()を付加し、関数が一つかそれ以上の引数を要求する場合には `main(...)` のようにそれに(...)を付加します。 -続いて、始め波括弧があります。この始め波括弧はその前の終わり丸括弧と同じ行にあることもありますが、そうでない場合にはそれ自身の新規の行に書きます。これは個人的なプログラマ、プロジェクトやグループに依存しますが - どちらでも結構です。異なるインデントスタイルの完全なリファレンスについては Indent Style についての Wikipedia の記事(http://en.wikipedia.org/wiki/Indent_style)を参照してください。 +続いて、始め波括弧があります。この始め波括弧はその前の終わり丸括弧と同じ行にあることもありますが、そうでない場合にはそれ自身の新規の行に書きます。これは個人的なプログラマ、プロジェクトやグループに依存しますが - どちらでも結構です。異なるインデント（字下げ）スタイルの完全なリファレンスについては 字下げスタイルについての Wikipedia の記事(https://ja.wikipedia.org/wiki/%E5%AD%97%E4%B8%8B%E3%81%92%E3%82%B9%E3%82%BF%E3%82%A4%E3%83%AB)を参照してください。 -この始め波括弧と終わりの間に、私たちはコンピュータに何かをさせる具体的な命令となるコード宣言を書きます。この例では、一つの宣言だけがあり、それは必要とされている `return` です。もしこれを戻り値の型が `int` の関数において省略すると、コンパイラは整数を返すという約束をあなたが破ったとして文句を言うでしょう。このケースでは、オペレーティングシステムは 0 を「つつがなく実行された」と解釈します。面白半分、0 を 1 に変更してコードを実行し、何が起こるかご覧ください。 +この始め波括弧と終わりの間に、私たちはコンピュータに何かをさせる具体的な命令となるコード宣言を書きます。この例では、一つの宣言だけがあり、それは必要とされている `return` です。もしこれを戻り値の型が `int` の関数において省略すると、コンパイラは整数を返すという約束をあなたが破ったとして文句を言うでしょう。このケースでは、オペレーティングシステムは 0 を「問題なく実行された」と解釈します。面白半分、0 を 1 に変更してコードを実行し、何が起こるかご覧ください。 -この新しいコードでは、`main()` と同じように見えて異なる `greet(...)` という 2 つ目の関数に注目してください。同じようにコードブロックを保持する波括弧がありますが、戻り値の型が異なります。同様に丸括弧のペアもありますが、何かが中にあります。必要な return 宣言についてはどうでしょうか？関数が何も返さない場合には _void_ キーワードが戻り値の型の場所に置かれます。そういうわけで、`greet(...)` は _void_ の戻り値の型を持っていますので `return` を省略してもコンパイラは文句を言わないでしょう。丸括弧の中には `string person` というのがあります。これは引数で、関数が利用する入力値です。このケースでは、検索と置換に少し似ています。`main()` を見ると、私が `greet(...)` を 5 回呼び、それぞれ引用符の中の異なった文字列を、丸括弧の中に入れています。これらが _引数_ です。 +この新しいコードでは、`main()` と同じような見た目ながら異なる `greet(...)` という 2 つ目の関数に注目してください。同じようにコードブロックを保持する波括弧がありますが、戻り値の型が異なります。同様に丸括弧のペアもありますが、何かが中にあります。必要な return 宣言についてはどうでしょうか？関数が何も返さない場合には _void_ キーワードが戻り値の型の位置に置かれます。そういうわけで、`greet(...)` は _void_ の戻り値の型を持っていますので `return` を省略してもコンパイラは文句を言わないでしょう。丸括弧の中には `string person` というのがあります。これは引数で、関数が利用する入力値です。このケースでは、検索と置換に少し似ています。`main()` を見ると、私が `greet(...)` を 5 回呼び、それぞれ引用符の中の異なった文字列を、丸括弧の中に入れています。これらが _引数_ です。 -前の例に戻ると、これらの 5 行のコードは全て **_関数呼び出し_** でした。それらは `greet(...)` を実行するように告げ、彼らが仕事を実行できるように文字列の引数を一つ渡しました。この一つの文字列の引数が `person` というパラメタを通じて `greet(...)` 内部のコードで利用可能となっています。事が起こっている順序を知るには、図 11 をご覧ください。 +前の例に戻ると、これらの 5 行のコードは全て **_関数呼び出し_** でした。それらは `greet(...)` を実行するように告げ、それが仕事を実行できるように文字列の引数を一つ渡しました。この一つの文字列の引数が `person` というパラメタを通じて `greet(...)` 内部のコードで利用可能となっています。事が起こっている順序を知るには、図 11 をご覧ください。 -![Figure 11. Function Call Flow](images/function-call.png "Figure 11. Function Call Flow") +![図11. 関数呼び出しフロー](images/function-call.png "図11. 関数呼び出しフロー") -図 11 のカラフルな線はコード上を実行に合わせて移動する想像上の再生ヘッドによって描かれる経路です。青い部分からスタートして main のエントリーポイントに入っていき、そして `greet(...)` に遭遇し、ここで _ジャンプ_ が発生します。線が緑になると、一時的に `main()` を抜けてしばらく `greet(...)` を辿っていきます。線が黄色になる頃には `greet(...)` の中に含まれるコードの実行は終わって 2 回目のジャンプ（return）が発生し、今度は先ほど保存された場所に戻って、次の宣言に続いていきます。この例で見ることができる明らかな利点は長い `cout` 宣言からシンプルな `greet(...)` の呼び出しに複雑さが削減されていることです。私たちが `greet(...)` を 5 回呼ばなければいけない場合、ルーチンを関数中に _カプセル化_ することは利便性の力を与えてくれます。あなたが挨拶を "Good night" から "Show's over " に変更するとしましょう。カット＆ペーストしたコード行の全てを更新するのではなく、たった一つの関数を変更することができてこれに関わるこの関数の利用がいっぺんに変更されるのです。さらに、コードは本当に複雑に成長します。それを小さなルーチンに分割し、それらのルーチンをカスタムの構成ブロックとして利用し、より大きなソフトウェアをどのように構築するかを考えることを助けるのです。関数を利用することで、システムの全てのディテールまで注意深く表現することから開放されます；それゆえ関数は _抽象化_ の一つの形態で、アートにおける抽象化に似ています。この種の抽象化は _複雑さのカプセル化_ と呼ばれますが、なぜならば大きく複雑なものを綺麗で小さなカプセルに入れてその大きく複雑な代物をより小さく、シンプルに見せるようなものだからです。これは - プログラミングだけでなく - 非常にパワフルなアイデアです。 +図 11 のカラフルな線はコード上を実行に合わせて移動する想像上の再生ヘッドによって描かれる経路です。青い部分からスタートして main のエントリーポイントに入っていき、そして `greet(...)` に遭遇し、ここで _ジャンプ_ が発生します。線が緑になると、一時的に `main()` を抜けてしばらく `greet(...)` を辿っていきます。線が黄色になる頃には `greet(...)` の中に含まれるコードの実行は終わって 2 回目のジャンプ（return）が発生し、今度は先ほど保存された場所に戻って、次の宣言に続いていきます。この例で見ることができる明らかな利点は、長い `cout` 宣言からシンプルな `greet(...)` の呼び出しに複雑さが削減されていることです。私たちが `greet(...)` を 5 回呼ばなければいけない場合、ルーチンを関数中に _カプセル化_ することは利便性のパワーを与えてくれます。あなたが挨拶を "Good night" から "Show's over " に変更するとしましょう。カット＆ペーストしたコード行の全てを更新するのではなくたった一つの関数の変更で済み、この関数の利用によるこれに関する挙動がいっぺんに変更されるのです。さらに、コードは本当に複雑に成長します。それを小さなルーチンに分割し、それらのルーチンをカスタムの構成ブロックとして利用し、より大きなソフトウェアをどのように構築するかを考えることを助けるのです。関数を利用することで、システムの全てのディテールまで注意深く表現することから開放されます；それゆえ関数は _抽象化_ の一つの形態で、アートにおける抽象化に似ています。この種の抽象化は _複雑さのカプセル化_ と呼ばれますが、なぜならば大きく複雑なものを綺麗で小さなカプセルに入れ、その大きく複雑な代物をより小さくシンプルに見せるようなものだからです。これは - プログラミングだけでなく - 非常にパワフルなアイデアです。 -俳優のローレンス・フィッシュバーンが色付きの鼻眼鏡を着けて、とても複雑な説明の2つの選択肢をあなたに提示していると想像してください。一つには、ハッカーの英雄としての宿命を全うするためにあなたが悪しきマトリックスからの脱出を助けることを彼が望んでいるが、それは潜在的に苦痛以外の何者でもない運命と共に生きることを意味します。ともかくストーリーは続き、可愛い少女が現れます。一方では、彼はあなたが起きたこと全てを忘れてしまい、何も気づかずに不可解にも偽りの生活を送る小さなアパートにあなたを戻すことを望んでいます。この2つの選択肢は映画の _The Matrix_ で説明されていて、そうでなければ冗長になってしまうシナリオをシンプルにする手法として、主人公は選択を色付きの錠剤の形で提示されます。2つの込み入った選択肢は単純な比較にカプセル化されていて、それは映画の観客にとってずっと肚落ちしやすいものです。 +俳優のローレンス・フィッシュバーンが色付きの鼻眼鏡を着けて、とても複雑な説明の2つの選択肢をあなたに提示していると想像してください。一つには、ハッカーの英雄としての宿命を全うするためにあなたが悪しきマトリックスからの脱出を助けることを彼が望んでいるが、それは潜在的に苦痛以外の何者でもない運命と共に生きることを意味します。ともかくストーリーは続き、可愛い少女が現れます。一方では、彼はあなたが起きたこと全てを忘れてしまい、何も気づかずに不可解にも偽りの生活を送る小さなアパートにあなたを戻すことを望んでいます。この2つの選択肢は映画の _マトリックス_ で説明されていて、そうでなければ冗長になってしまうシナリオをシンプルにする手法として、主人公は選択を色付きの錠剤の形で提示されます。2つの込み入った選択肢は単純な比較にカプセル化されていて、それは映画の観客にとってずっと肚落ちしやすいものです。 -![Figure 12. Red Pill and Blue Pill from The Matrix](images/red-blue-pills.png "Figure 12. Red Pill and Blue Pill from The Matrix") +![図12. マトリックスの赤い錠剤と青い錠剤](images/red-blue-pills.png "図12. マトリックスの赤い錠剤と青い錠剤") -込み入った状況全体を繰り返すのでなく、ネオ（主人公）は単にどちらかの錠剤を飲めば良いのです。現実の薬においてさえも、複雑さをカプセルに閉じ込めるというアイデアはなお当てはまります。我々の殆どは最も効果的に医療行為を行うための専門知識を持っていないので、医者や薬学者がただ適切な薬草や化学物質の正しい配合を作ることを信じるのです。あなたが錠剤を飲み込む時、それは関数を呼ぶことに似ていて、なぜならばあなたは錠剤の奥深さを理解する必要がないという利点があるからです。あなたは単純にその錠剤が成果を出すことについて信頼します。同じことがプログラムコードにも言えます。殆どの場合、関数は他の誰かによって書かれていて、もしその人が良い開発者であるならば、あなたはそれらの関数の適切な呼び方を理解している限り、幸運にもその関数の内部的な動作からは開放されます。このように、あなたは _高レベル（higher-level）_ のプログラマで、つまりあなたが記述していない関数を単純に呼び出すことを意味します。openFrameworks でプロジェクトを作成する人は、openFrameworksの肩の上に乗っています。openFrameworksはOpenGL Utility Toolkitの肩に乗り、それはOpenGLそのものに立脚している、といった具合です。言い換えれば、openFrameworksのプロジェクトは _低レベル_ プログラミングとしての評判のあるC++の _高レベル_ アプリケーションなのです。図13に図示するように、私がインタラクティブな作品をC++で書いているというとしばしば問題が発生します。 +込み入った状況全体を繰り返すのでなく、ネオ（主人公）は単にどちらかの錠剤を飲めば良いのです。現実の薬においてさえも、複雑さをカプセルに閉じ込めるというアイデアはなお当てはまります。我々の殆どは最も効果的に医療行為を行うための専門知識を持っていないので、医者や薬学者がただ適切な薬草や化学物質の正しい配合を作ることを信じるのです。あなたが錠剤を飲み込む時、それは関数を呼ぶことに似ていて、なぜならばあなたは錠剤の奥深さを理解する必要がないという利点があるからです。あなたは単純にその錠剤が成果を出すことを信じます。同じことがプログラムコードにも言えます。殆どの場合、関数は他の誰かによって書かれていて、もしその人が良い開発者であるならば、あなたはそれらの関数の適切な呼び方を理解している限り、幸運にもその関数の内部的な動作からは開放されます。このように、あなたは _高レベル（higher-level）_ のプログラマで、つまりあなたが記述していない関数を単純に呼び出すことを意味します。openFrameworks でプロジェクトを作成する人は、openFrameworks の肩の上に乗っています。openFrameworks は OpenGL Utility Toolkit の肩に乗り、それは OpenGL そのものに立脚している、といった具合です。言い換えれば、openFrameworks のプロジェクトは _低レベル_ プログラミングとしての評判のある C++ の _高レベル_ アプリケーションなのです。図13に図示するように、私がインタラクティブな作品を C++ で書いているというとしばしば問題が発生します。 -新規のメディアプロジェクトにC++を利用することは、他の選択肢（ほとんどスクリプト言語）に対して幾つかの利点があります。この議論は詳しい人々の中では非常に宗教的に（もとい：白熱したものに）なり得ます。あなたがC++を学ぼうとするとき、理由はたいていより速いランタイムの性能を求めるか、あなたのプロジェクトに組み込めるライブラリがより多いか、あなたのメンターがその言語に取り組んでいるからでしょう。oFのプロジェクトは高レベルと考えられますが、これは複雑なものの入ったより大きなカプセルを扱っているからであり、これは誇れるべきものです。 +新規のメディアプロジェクトに C++ を利用することは、他の選択肢（ほとんどスクリプト言語）に対して幾つかの利点があります。この議論は詳しい人々の中では非常に宗教的に（意：白熱したものに）なり得ます。あなたが C++ を学ぼうとするとき、理由はたいていより速いランタイムの性能を求めるか、あなたのプロジェクトに組み込めるライブラリがより多いか、あなたのメンターがその言語に取り組んでいるからでしょう。oF のプロジェクトは高レベルと考えられますが、これは複雑なものが入ったより大きなカプセルを扱っているからであり、これは誇れるべきものです。 -> A “thing” is a “think”, a unit of thought > 「物体」は「考え」、思考の単位である > > -- アラン・ワッツ @@ -801,7 +800,7 @@ There are a few advantages to using C++ over the other options (mostly scripting -以下のプログラムをideoneに入力して実行してください。 +以下のプログラムを ideone に入力して実行してください。 -これまでのレッスンで、`<<` オペレータの間に入れたものは `cout` オブジェクトに整形されて入り、魔法のようにコンソールに出力されることを理解しました。最後の行で、括弧の中に簡単な計算（42+1）を入れ、それは43と評価されたことに注目してください。これは数学的な意味で _式（expression）_ と呼ばれます。これらの3行のコードは全て数字の42について何かを語っていますので、それらは全て _リテラル_ の整数を含んでいます。リテラルの値というのはプログラムに直接記述された内容です;コンパイルされると他の部分と値が固定されるため「ハード・ワイヤード」と呼ぶ人もいます。 +これまでのレッスンで、`<<` オペレータの間に入れたものは `cout` オブジェクトに整形されて入り、魔法のようにコンソールに出力されることを理解しました。最後の行で、括弧の中に簡単な計算（42+1）を入れ、それは 43 と評価されたことに注目してください。これは数学的な意味で _式（expression）_ と呼ばれます。これらの 3 行のコードは全て数字の42について何かを語っていますので、それらは全て _リテラル_ の整数を含んでいます。リテラルの値というのはプログラムに直接記述された内容です；コンパイルされると他の部分と値が固定されるため「ハード・ワイヤード」と呼ぶ人もいます。 -この数字を変更したいとすると、ワープロで知っていることは可能なので、42を新しい値に「検索と置換」します。3D空間に100,000のパーティクルがあったとしたらどうでしょう。いくつかは変化し続ける42であり、その他は変化してはいけない42だったら？プログラムを書いているとき、物事は重く複雑になり得ます。最もわかりやすい _変数_ の利用法は非常にパワフルな検索と置換のメカニズムですが、変数はそれ以上に有用です。さて、コードの最初に整数を宣言してリテラルの42の箇所で利用してみましょう。 +この数字を変更したいとすると、ワープロで知っていることは可能なので、42 を新しい値に「検索と置換」します。3D 空間に 100,000 のパーティクルがあったとしたらどうでしょう。いくつかは変化し続ける 42 であり、その他は変化してはいけない 42 だったら？プログラムを書いているとき、物事は重く複雑になり得ます。最もわかりやすい _変数_ の利用法は非常にパワフルな検索と置換のメカニズムですが、変数はそれ以上に有用です。さて、コードの最初に整数を宣言してリテラルの 42 の箇所で利用してみましょう。 -今度は `answer` という変数を利用していて、私はこの1つの数値をコード中で変更すれば良いだけで、それは3つ全ての文章で42として現れます。これは検索と置換よりもずっとエレガントです。図18は変数の宣言と初期化を同じ行で行う構文の説明です。 +今度は `answer` という変数を利用していて、私はこの 1 つの数値をコード中で変更すれば良いだけで、それは 3 つ全ての文章で 42 として現れます。これは検索と置換よりもずっとエレガントです。図 18 は変数の宣言と初期化を同じ行で行う構文の説明です。 -変数の宣言と初期化を2行に分けることも可能です。それはこのようになります： +変数の宣言と初期化を 2 行に分けることも可能です。それはこのようになります： -このケースでは、変数の宣言の後、そのanswerが予測できず不安定になる時間がありますが、これはCが（Javaと異なり）新規の変数の自動でゼロに設定されないためです - これはあなたがやる必要があります。そうしなければ、変数は予測できない値 - コンピュータのメモリのゴミ - になります。ですので、誤動作によるアートを作りたいのでない限り、変数は宣言に際してゼロであっても常に何らかの値で初期化するようにしてください +このケースでは、変数の宣言の後、その answer が予測できず不安定になる時間がありますが、これは C が（Java と異なり）新規の変数の自動でゼロに設定されないためです - これはあなたがやる必要があります。そうしなければ、変数は予測できない値 - コンピュータのメモリのゴミ - になります。ですので、誤動作によるアートを作りたいのでない限り、変数は宣言に際して常に何らかの値で、ゼロであっても初期化するようにしてください。 -以下の識別子はOKです。 +以下の識別子は OK です。 -小文字のaは大文字のAと異なる識別子なことに注意してください。C++での識別子は大文字小文字を区別します。 -以下の識別子はNGです。 +小文字の a は大文字の A とは異なる識別子なことに注意してください。C++ での識別子は大文字小文字を区別します。 +以下の識別子は NG です。 -変数に `void_int` と名付けるのは、ややこしいですが、アンダースコアで二つのキーワードを1つの識別子に連結しているにおで、コンパイラのエラーは起きないでしょう。まれに、`unqualified id` エラーに遭遇するかもしれません。これがC++の予約語のリストで、変数の命名時に避けるべきものです。C++には完全なプログラミング言語を提供するためにこれらが必要なのです。 +変数に `void_int` と名付けるのは、ややこしいですが、アンダースコアで二つのキーワードを1つの識別子に連結しているので、コンパイラのエラーは起きないでしょう。まれに、`unqualified id` エラーに遭遇するかもしれません。これがC++の予約語のリストで、変数の命名時に避けるべきものです。完全なプログラミング言語を提供するために C++ にはこれらが必要なのです。 -（変数を含む）識別子は異なるスタイルで書かれていて、構成要素の種類（変数、関数やクラス？）、データ型（整数や文字列？）、スコープ（グローバルかローカル？）、プライバシーのレベルなどの様々な属性を表します。あなたはその他が全て `lower_case_using_underscores_to_separate_the_words（単語の区切りにアンダースコアを利用した小文字）` であるのに、幾つかの識別子が大文字から始まって「キャメルケース」を利用していることに気づくでしょう。グローバルな定数は `ALL_CAPS_AND_UNDERSCORES（全て大文字とアンダースコア）` の名前で見つかります。もう一つは小文字の `letterThenCamelCaseFromThere（文字から始まってそれからキャメルケース）` です。ハイブリッドもあって、 `ClassName__functionName__variable_name` のようなものです。これらの異なるスタイルで違った識別子のカテゴリを示すことができます。 +（変数を含む）識別子は異なるスタイルで書かれていて、構成要素の種類（変数、関数またはクラス？）、データ型（整数か文字列か？）、スコープ（グローバルかローカルか？）、プライバシーのレベルなどの様々な属性を表します。あなたはその他が全て `lower_case_using_underscores_to_separate_the_words（単語の区切りにアンダースコアを利用した小文字）` であるのに、幾つかの識別子が大文字から始まって「キャメルケース」を利用していることに気づくでしょう。グローバルな定数は `ALL_CAPS_AND_UNDERSCORES（全て大文字とアンダースコア）` の名前で見つかります。もう一つは小文字の `letterThenCamelCaseFromThere（文字から始まってそれからキャメルケース）` です。ハイブリッドもあって、 `ClassName__functionName__variable_name` のようなものです。これらの異なるスタイルで違った識別子のカテゴリを示すことができます。 -より過剰には、プログラマが親しみを込めて _ハンガリアン表記_ と呼ばれるものを使うかもしれません。これは文字のバッジを識別子に付けて、それについての何かを表現しますが、これは、例えば `dwLightYears` や `szLastName` のように可読性を下げてもしまいます。命名規則は変更できないものではなく、コンパイラによって強制されているものでもありません。共同作業者は通常これらの繊細な命名規則について合意しお互いに混乱しないようにし、全員のパートが決定されたいかなる規則に対しても首尾一貫するように、規律を用いなければいけません。コードの命名規則の話題は、どの行に波括弧を置くか、インデントにタブを使うかのように、開発者間で滑稽に白熱する議論でもあります。プログラミングの多くの事と同様に、誰かが常にあなたは間違ったやり方をしていると言うでしょう。それは必ずしもあなたが間違っていることは意味しないのです。 +より過剰には、プログラマが親しみを込めて _ハンガリアン表記_ と呼ばれるものを使うかもしれません。これは文字のバッジを識別子に付けて、それについての何かを表現しますが、これは、例えば `dwLightYears` や `szLastName` のように可読性を下げてもしまいます。命名規則は変更できないものではなく、コンパイラによって強制されているものでもありません。共同作業者は通常これらの繊細な命名規則について合意してお互いに混乱しないようにし、全員のパートが決定されたいかなる規則に対しても首尾一貫するように、規律を用いなければいけません。コードの命名規則の話題は、どの行に波括弧を置くか、インデントにタブを使うかのように、開発者間で滑稽に白熱する議論でもあります。プログラミングの多くの事と同様に、誰かが常にあなたは間違ったやり方をしていると言うでしょう。それは必ずしもあなたが間違っていることは意味しないのです。 -変数は実行中に値が _変化_ するためにそう呼ばれます。これは大抵何か（たとえば水）を保管するために入れるバケツとして有用です。通常、最終的にはバケツに戻って水を幾らか利用するか、薬品を水に混ぜるか、バケツに水を足したりします。1つの変数は空のバケツのようなものでそこに何かを入れることができます。図19は _Minecraft_ というゲームのバケツです。 +変数は実行中に値が _変化_ するためにそう呼ばれます。これは大抵何か（たとえば水）を保管するために入れるバケツとして有用です。通常、最終的にはバケツに戻って水を幾らか利用するか、薬品を水に混ぜるか、バケツに水を足したりします。1つの変数は空のバケツのようなものでそこに何かを入れることができます。図19は _マインクラフト_ というゲームのバケツです。 -出力は `012345` となるはずです。イコールの使い方に注意してください。これは計算で慣れ親しんでいるものとは異なります。伝統的な文脈では、1つのイコールは両側の式は等価として評価されます。Cでは、それは実際には二重のイコール（==）であり、それについては後で述べます。単独のイコールは「右辺の式を評価して左辺の名前の変数に答を保存せよ」という意味です。もしこれまでプログラムをしたことがない場合には慣れるまでには少し時間が掛かるでしょう。もし私が（私の内なる子供は常にそうであるように）コーディング初心者であった場合、値を変数に保存する命令をコンピュータにするための他の文法についても恐らく楽しむことでしょう。Princeton sound lab による _Chuck_ という言語にある `3 => counter` というようなもの、あるいはもう少し視覚的に、図20に示すMinecraftの作業台の流用のようなものかもしれません。 +出力は `012345` となるはずです。イコールの使い方に注意してください。これは計算で慣れ親しんでいるものとは異なります。伝統的な文脈では、1つのイコールは両側の式は等価として評価されます。C では、それは実際には二重のイコール（==）であり、それについては後で述べます。単独のイコールは「右辺の式を評価して左辺の名前の変数に答を保存せよ」という意味です。もしこれまでプログラムをしたことがない場合には慣れるまでには少し時間が掛かるでしょう。もし私が（私の内なる子供は常にそうであるように）コーディング初心者であった場合、値を変数に保存する命令をコンピュータにするための他の文法についても恐らく楽しむことでしょう。Princeton sound lab による _Chuck_ という言語にある `3 => counter` というようなもの、あるいはもう少し視覚的に、図 20 に示すマインクラフトの作業台の流用のようなものかもしれません。 -![図20. 変数割り当てのために改変したMinecraft作業台](images/minechuck.png "図20. 変数割り当てのために改変したMinecraft作業台") +![図20. 変数割り当てのために改変したマインクラフトの作業台](images/minechuck.png "図20. 変数割り当てのために改変したマインクラフトの作業台") -先ほどのコード例を詳しく見ると、数字を毎回1ずつ出力前に増やしていることが分かります。私は繰り返しリテラルな整数を変数に保存しました。プログラミング言語は基本的な算術を知っているので、以下のような変更をしてみましょう： +先ほどのコード例を詳しく見ると、数字を毎回 1 ずつ出力前に増やしていることが分かります。私は繰り返しリテラルな整数を変数に保存しました。プログラミング言語は基本的な算術を知っているので、以下のような変更をしてみましょう： -なんたることだ、めまいがする！しかしそれを何度か繰り返すと、見えるほどには複雑でないことが分かります。これは非常に _実践的な_ SFの利用であり、（あなたがカイル・マクドナルドかHaskellのプログラマでない限り）時空の構造に挑もうとしているわけではないでしょう。大事な事は、水を加えようとした時にすでにそのバケツには水が入っているであろうことと同様に、コンピュータのメモリの内容を変更するために、1命令前の `counter` を取得しているのです。`バケツ = バケツ + 水` を図22で示します。 +なんたることだ、めまいがする！しかしそれを何度か繰り返すと、見えるほどには複雑でないことが分かります。これは非常に _実践的な_ SFの利用であり、（あなたがカイル・マクドナルドか Haskell のプログラマでない限り）時空の構造に挑もうとしているわけではないでしょう。大事な事は、水を加えようとした時にすでにそのバケツには水が入っているであろうことと同じように、コンピュータのメモリの内容を変更するためには、1 命令前の `counter` があるということです。`バケツ = バケツ + 水` を図22で示します。 -1ずつ加算することは、または変数に何らかの値を足すことは実際あらゆるプログラミングで非常に日常茶飯事な事なので、そのための糖衣構文も存在します。_糖衣構文（シンタックスシュガー）_ とは簡単のためにプログラミング言語に追加された冗長な文法です。タイプ量を減らし、理解力や表現力を向上させ、そして（砂糖のように）プログラマを幸せにします。以下の宣言は全て `counter` に1を追加します。 +1 ずつ加算することは、または変数に何らかの値を足すことは実際あらゆるプログラミングで非常に日常茶飯事な事なので、そのための糖衣構文も存在します。_糖衣構文（シンタックスシュガー）_ とは簡単のためにプログラミング言語に追加された冗長な文法です。タイプ量を減らし、理解力や表現力を向上させ、そして（砂糖のように）プログラマを幸せにします。以下の宣言は全て `counter` に 1 を追加します。 -やった、ずっとタイプ量が減りました。もっと完結にする方法はたくさんあります。これが1つの方法です。 +やった、ずっとタイプ量が減りました。もっと完結にする方法はたくさんあります。これが 1 つの方法です。 -`123456` の答えが出ても、これは間違いではありません！前置の加算演算子は後置の姉妹とはまさにこの部分で異なるのです。0で初期化された `counter` に対して、`++counter` は1と評価し、`counter++` はまだ0と評価します（しかし加算されたバージョンの `counter` が後からの利用のために残ります）。以下の例の出力は `1112` です。 +`123456` の答えが出ても、これは間違いではありません！前置の加算演算子と姉妹の後置とはまさにこの部分で異なるのです。0 で初期化された `counter` に対して、`++counter` は 1 と評価し、`counter++` はまだ0と評価します（しかし加算されたバージョンの `counter` が後からの利用のために繰り越されます）。以下の例の出力は `1112` です。 -算術的な完全性のために、負の _減算_ 演算子（counter--）も存在することに触れなければいけません。そして、恐らくここまでに推測しているように、`counter + 1` と言えるならば、Cコンパイラは `counter -3`（減算）、`counter * 2` （アスタリスクは乗算です）、`counter / 2` （除法）、丸括弧を利用した演算子の順番の強制は `(counter + 1) / 2` は `counter + 1 / 2` とは違う結果と評価されるようにその他の古典的な算術を認識します。 +算術的な完全性のために、負の _減算_ 演算子（counter--）も存在することに触れなければいけません。そして、恐らくここまででの想像通り、`counter + 1` と言えるならば、Cコンパイラはその他の `counter - 3`（減算）、`counter * 2` （アスタリスクは乗算です）、`counter / 2` （除法）、丸括弧を利用した演算子の順番の強制は `(counter + 1) / 2` は `counter + 1 / 2` とは違う結果と評価されるといった古典的な算術を認識します。 -変数についてはもう少し学ぶべき基礎がありますが、とりあえずは今まで学んだ事を使って、楽しんで実行してみましょう。さしあたりは、ここまでたどり着いたことにもう一度、あなた自身を褒めてあげてください！あなたは変数の何たるか、そしてそれに基本的な算術を行うやりかたを学びました。また、++演算子が変数名の前と後に置かれたときに何をするかを学びました。 +変数についてはもう少し学ぶべき基礎がありますが、とりあえずは今まで学んだ事を使って、楽しんで実行してみましょう。さしあたりは、ここまでたどり着いたことにもう一度、あなた自身を褒めてあげてください！あなたは変数の何たるか、そしてそれに基本的な算術を行うやりかたを学びました。また、++ 演算子が変数名の前と後に置かれたときに何をするかを学びました。 -C++言語はC言語プラス1であることから名前が取られています。 +C++ 言語は C 言語プラス 1 であることから名前が取られています。 -C++の紹介の最初の数ページを完了し、おめでとうございます。これらの基本的な概念をもってあなたは自分自身で十分遠くまで探検できるはずです、しかしofBookの残りのコード例を理解するための準備には十分でないことは認めます。紙幅の制限により、ここでみているものは十分な長さのC++言語への導入の「予告編」なのです。この章のそのバージョンはとても大きいので今ではそれ自身の書籍になっています - 完全版がWebで、将来的にはofBookの副読本として。非プログラマにC++言語を教えるためにはそれ自身で実際たくさんの科目が存在し、100ページ超の書籍に増大することは言うまでもなく、効果的に35ページに圧縮することはできません。真剣にopenFrameworksに取り組む場合、あなたが何を読んでいるのかを理解するためには、ofBookを読み進める前に立ち止まってこのチャプターの完全版を読むことを高く推奨します。資料は [こちら](https://github.com/openframeworks/ofBook/blob/master/chapters/cplusplus_basics/unabridged.md) +C++の紹介の最初の数ページを完了しました、おめでとうございます。これらの基本的な概念をもってあなたは自分自身で十分遠くまで探検できるはずです、しかし ofBook の残りのコード例を理解するための準備には十分でないことは認めます。紙幅の制限により、ここでみているものは十分な長さの C++ 言語への導入の「予告編」なのです。この章のそのバージョンはとても大きいので今ではそれ自身の書籍になっています - 完全版が Web で、将来的には ofBook の副読本として。非プログラマに C++ 言語を教えるためにはそれ自身で実際たくさんの科目が存在し、100 ページ超の書籍に増大することは言うまでもなく、効果的に 35 ページに圧縮することはできません。真剣に openFrameworks に取り組む場合、あなたが何を読んでいるのかを理解するためには、ofBook を読み進める前に立ち止まってこのチャプターの完全版を読むことを高く推奨します。資料は [こちら](https://github.com/openframeworks/ofBook/blob/master/chapters/cplusplus_basics/unabridged.md) -章がここで終わることは、C++言語において何が重要で何が重要でないかを分けることを決して意図していません。単純に紙幅が尽きたのです。C++の導入の残りの部分の重要さの代わりに、そしてofZach氏の教育の経験に基づき、以下は完全版で見ることのできる詳細です： +章がここで終わることは、C++ 言語において何が重要で何が重要でないかを分けることを決して意図していません。単純に紙幅が尽きたのです。C++ のこの導入の残りの部分の重要さの代わり、そして ofZach 氏の教育の経験に基づき、以下は完全版で見ることのできる詳細です： -- 変数はそれぞれ異なる期間存在します - 幾つかは長い時間、幾つかはプログラムのライフサイクルでの少しの間。_スコープ_ の科目はこのブックの完全版でカバーされており、_変数（パート2）_ というタイトルです。 +- 変数はそれぞれ異なる期間存在します - 幾つかは長い時間、幾つかはプログラムのライフサイクルでほんの少しの間。_スコープ_ の科目はこのブックの完全版でカバーされており、_変数（パート2）_ というタイトルです。 -- 変数には _データ型_ があります。例えば、あるものは数値を保有し別のものは何らかのテキストを保有します。_基本的な型( -（Fundamental Types）_ にさらにあります。 +- 変数には _データ型_ があります。例えば、あるものは数値を保有し、別のものは何らかのテキストを保有します。_基本的な型（Fundamental Types）_ に詳しくあります。 -![Figure 1: TI-82 rendering of the Sierpinski triangle, Courtesy of Texas Instruments](images/sierpinski-fractal-ti82.png "Figure 1: TI-82 rendering of the Sierpinski triangle, Courtesy of Texas Instruments") +![図1: TI-82によるシェルピンスキーの三角形、テキサス・インスツルメンツ提供](images/sierpinski-fractal-ti82.png "図1: TI-82によるシェルピンスキーの三角形、テキサス・インスツルメンツ提供") -このフラクタル、有名な [Sierpinski triangle](https://www.wolframalpha.com/input/?i=sierpinski+triangle) には完全なシェルピンスプログラムを構成する 25 行あまりのコンピュータの命令が添えられていました。私は幾つかの数値演算も見ながらコードを仔細に調べました - 何も高度すぎることはなく、ほとんどのものは命令する言葉で、「これをせよ」や「もし何々ならば他のことをせよ」のようなものでした。私は書籍からグラフ計算機にコードを打ち込み、プログラムを実行することができました。最初はただの空白の液晶パネルです。徐々にいくつかのランダムなピクセルがあちこちで黒く切り替わりますが特に法則性は見出せません。さらに何秒かすると画面が満たされ、すでにトライアングルの輪郭がかすかに見えてきます。十分な時間が経過すると、計算機はついに書籍のものとぴったり一致しました。私の気持ちははっきりいってぶっ飛びました。明確には意味がわかりませんでした。どのような自然の神秘がこんなにわずかな命令からこのような複雑な形態を生み出すのか？画面には 6,000 ピクセルがあり、わずか 25 行の命令がこの驚くべき生物のようなアートワークを生み出すに足るのだろうか？これは誰のアートワークなのか？私は新しい作品をそこから派生しうるのか？それまで私はそれほどにごくわずかの仕事からこれほどの魔法のような報いを得られたことはほとんどありませんでした。私は新たな礎を発見しました。私はそれが重要（だと私が決めたので）プログラムを理解する必要性を感じました。私はコードに戻って数値のいくつかを変更し、プログラムをもう一度実行しました。スクリーンは空白になり、異なった画像を描きました。今回だけは左に歪み、ビューポートからはみ出してしまいました。私は勇気を出して英語の命令の一つを変更し、そしてマシンはエラーを出し、実行に失敗しました。 +このフラクタル、有名な [シェルピンスキーの三角形](https://www.wolframalpha.com/input/?i=sierpinski+triangle) には完全なシェルピンスプログラムを構成する 25 行あまりのコンピュータの命令が添えられていました。私は幾つかの数値演算も見ながらコードを仔細に調べました - 何も高度すぎることはなく、ほとんどのものは命令する言葉で、「これをせよ」や「もし何々ならば他のことをせよ」のようなものでした。私は書籍からグラフ計算機にコードを打ち込み、プログラムを実行することができました。最初はただの空白の液晶パネルです。徐々にいくつかのランダムなピクセルがあちこちで黒く切り替わりますが特に法則性は見出せません。さらに何秒かすると画面が満たされ、すでにトライアングルの輪郭がかすかに見えてきます。十分な時間が経過すると、計算機はついに書籍のものとぴったり一致しました。私の気持ちははっきりいってぶっ飛びました。明確には意味がわかりませんでした。どのような自然の神秘がこんなにわずかな命令からこのような複雑な形態を生み出すのか？画面には 6,000 ピクセルがあり、わずか 25 行の命令がこの驚くべき生物のようなアートワークを生み出すに足るのだろうか？これは誰のアートワークなのか？私は新しい作品をそこから派生しうるのか？それまで私はそれほどにごくわずかの仕事からこれほどの魔法のような報いを得られたことはほとんどありませんでした。私は新たな礎を発見しました。私はそれが重要（だと私が決めたので）プログラムを理解する必要性を感じました。私はコードに戻って数値のいくつかを変更し、プログラムをもう一度実行しました。スクリーンは空白になり、異なった画像を描きました。今回だけは左に歪み、ビューポートからはみ出してしまいました。私は勇気を出して英語の命令の一つを変更し、そしてマシンはエラーを出し、実行に失敗しました。 -![Figure 2: The human loop of a programmer.](images/programmer-cycle.png "Figure 2: The human loop of a programmer.") +![図2: プログラマーの人間らしい繰り返し](images/programmer-cycle.png "図2: プログラマーの人間らしい繰り返し") -![Figure 3: Don't get the wrong idea.](images/profit-not.png "Figure 3: Don't get the wrong idea.") +![図3: 誤った考えをしないように。](images/profit-not.png "図3: 誤った考えをしないように。") + # 哲学 _by [Zach Lieberman](http://thesystemis.com)_ - + openFrameworks の航海は幾つかのゴールによってその指針が示されています：それは協働的であること、実用的かつシンプルであること、一貫性があり直感的であること、クロスプラットフォーム、パワフルさ、そして拡張可能であることです。加えて「人と一緒にやろう（do it with others / (DIWO)」の哲学により推進されています。 - + ### 協働的であること - + openFrameworks の開発は協働的なもので、議論に盛んに参加し、アドオンやプロジェクト上で協働する多くの人々の貢献の上に成り立っています。私たちは皆が openFrameworks を我が物とし、エコシステムに貢献することを推奨します。 - + 私たちは git という分散型バージョン管理システムを用いていて、これは人々がブランチを作り、実験し、提案が可能なことを意味します。[GitHub](https://github.com/openframeworks/openFrameworks "link to the GitHub repository of openFrameworks") のネットワーク図を見てみると、沢山の曲がりくねったブランチ、枝分かれしてまた合流するコードによるエイリアンのダイヤグラムのように見えます。コアのコードに対して作業する世界中にまたがる巨大なコミュニティが存在します：彼らはバグを修正し、プルリクエストを送り、見たいような形のツールを具現化します。これは全世界的なプロジェクトであり、合衆国で目を覚ますとアジアやヨーロッパのプログラマからのプルリクエストやイシューの電子メールでいっぱいの受信箱を目にすることは日常茶飯事です。 - + ### シンプルさ - + openFrameworks は有用性とシンプルさのバランスを目指しています。openFrameworks の最初期のバージョンは C++ と [OpenGL](https://en.wikipedia.org/wiki/OpenGL "wikipedia article on OpenGL")を教えるためのツールとしてその中核の部分を利用していましたが、時を経るにつれて中核部分がより先進的な機能を取り入れるようになり、サンプル（examples）が学習のための最適な方法となりました。引き換えに、物事をシンプルにし、それを実験のための改変可能なスタートポイントとするべく、私たちは openFrameworks に同梱される沢山のサンプルを作成しました。 - + 私たちは openFrameworks を可能な限り、特に他の言語や環境から来た人々にとってシンプルなものにしたいです。C++ は「大きな」言語であり、それは全く違うタイプの様々な C++ コードを書くことが出来るという意味です。書店に行けば何百もの C++ の書籍を目にするでしょう。私たちはあなた方が専門家になる必要なく、多くとも一冊か二冊の書籍が必要とされ、コードのパターン、アプローチとスタイルはシンプルで直感的であるようなライブラリを作りたいです。私たちは [Processing](http://www.processing.org/ "processing language and IDE website") とある意味同質となること、つまり多くの機能が似通っていて一方のフレームワークから他方への移行が容易になることに特に関心を持っていました。 - + ### 一貫性と直感的であること - + openFrameworks は一貫性があり直感的です：これは最小の驚きの原則によって運営されており、openFrameworks のあるパートで学んだことは別のパートでも適用可能です。初学者は openFrameworks をよくあるプログラミングのパターンについて学ぶことに使い、上級者は他の言語やツールキットでの経験を適用することができるでしょう。 - + 学生ファーストであることがモットーです。openFrameworks を導く上で多く考えることは：私は 5 年か 10 年前だったらどんなツールを好んだか？コーディングのパターンはできる限りシンプルでタイピングしやすいものにしたい。これは動画のプレーヤにおいては "play" や "stop" といった自己言及的な関数名や直感的な変数名を持つことを意味します。直感的であることについては私たちは数多く議論していますが、これはコードを出来るだけ素直な物にしたいという要求によっています。タイプすることによって学び、オートコンプリート機能は助けになる、等々。 - + ### クロスプラットフォーム - + openFrameworks はクロスプラットフォームなツールキットです。openFrameworks は可能な限り多くの開発環境や OS をサポートします。openFrameworks をダウンロードをするには任意のプラットフォームや開発環境を選ぶことができ、学んだり遊んだりできるプロジェクトやサンプルを入手できます。移植が困難なコードはコアの部分からは取り除かれ、代わりにアドオンの中に置かれます。 - + openFrameworks は多くのプラットフォーム：OS X、 Windows、 Linux、 Android、 組み込みの ARM Linux システム、Blackberry PlayBook のような実験的なプラットフォームの上でも動作します。openFrameworks の開発者は Android の場合には Java、iOS の場合には Objective-C といった他の言語と接続する上手な方法も考案しています。 - + クロスプラットフォームなライブラリの良い点は、あなたのアイデアをプラットフォームをまたいで移植することが容易なことです。ラップトップ上でスケッチし、即座に電話機上で実行できます。プラットフォームを超えて動作する何かを作成するような退屈な仕事の心配をせずにアイデアを最優先にできるのです。 - + ### パワフルさ - + openFrameworks はパワフルです：[OpenCV](http://opencv.org/ "OpenCV, a library for (real-time) computer vision")のような高度なライブラリを利用したり、グラフィックカードのようなハードウエアを効果的に使ったり、カメラやその他のデバイスのような周辺機器を接続することができます。 - + 私たちが C++ を選択したのは、それがかなり低レベルな言語でありながら高レベルなやり方でプログラムすることが可能だからです。C++ はより古い C 言語の拡張なので、とても低レベルでオールドスクールな C コードや、より高レベルな C++ コードを記述できます。openFrameworks で、私たちは両方のアプローチを使い、シンプル、明瞭でありながらパワフルなコードとの関わりを提示します。C++ を利用することはまた、他の言語のラッパに依存することなく C や C++ で書かれた沢山のライブラリと接続することを容易にしています。 - + openFramewoks は基本として OpenGL や [Cairo](http://cairographics.org/ "Cairo, a vector graphics library")、[FreeType](http://freetype.org/ "FreeType, a software library to render fonts")、[FreeImage](http://freeimage.sourceforge.net/ "FreeImage, a library to work with common computer graphic image formats")、OpenCV といったライブラリをラップしています。openFrameworks はユーザーコード（あなたが記述するコード）とこれらのライブラリの間の層として考えることができます。これらのライブラリには異なるスタイルやイディオムやアプローチがあります。そして私たちの仕事はそれらをラップして、一貫性があり直感的なものとすることです。 @@ -80,26 +117,38 @@ openFramewoks は基本として OpenGL や [Cairo](http://cairographics.org/ "C ### 拡張可能性 - + openFrameworks は拡張可能です。もし openFrameworks に足りない物を見つけた場合、拡張するアドオンを作成することは容易です。openFrameworks の中核のアドオンは斬新な方法で問題を解決するというよりは、概してライブラリをラップしています。openFrameworks はライブラリをラップしていますが、それらのライブラリはさらなるハックのために外部に露出されたままです。 - + あなたが望むものを構築する際の openFrameworks の概念の一つは足場、もしくは足がかりとなる肩です。中核部分を軽量に保つことに資しているものの一つは、全てのものを可能な限り同梱しようとするのではなく、追加的なコード、ライブラリ、アプローチが必要に応じてユーザー間で共有されプロジェクトに編み込まれるように openFrameworks が「アドオン」のシステムを持っていることです。 - + openFrameworks のアドオンはコードのスニペットでも良いし、またはもっと複雑な OpenNI、Tesseract、Box2D のようなライブラリをラップしているかもしれません。アドオンの名前は通常 "ofx" という接頭辞から始まり、「中核」のコードと非中核のコードを容易に区別できます。加えて私たちは、例えば ofxOpenCv のように、皆がおそらく利用したいが全てのプロジェクトでは必須でないようなアドオンを「コアアドオン」として同梱しています。 - + 私たちは、アドオンを開発するコミュニテイを整え支援することを [http://ofxaddons.com](http://ofxaddons.com "ofxaddons, a collection of oF addons") というサイトを通じて行い、これは自動的に Github 上からタイトルに "ofx" という語彙を含むレポジトリを探すことでアドオンを収集しています。 - + -### 他の人と一緒にやろう (Do it with others / DIWO) +### 皆でやろう (Do it with others / DIWO) - + -openFrameworks の背後にある強い哲学は「皆と一緒にやろう (Do it with others / DIWO)」というものです。私たちは Instructables や Make といったチュートリアルサイトの興りによって盛んに宣伝され手がけられている「自分でやろう Do it yourself (DIY) カルチャーを愛しています。しかし私たちは「ソーシャルに作る」（皆と）というアイデアにも興奮します。私たちはワークショップ、デベロッパカンファレンス、ハッカソン/ラボ、手芸サークルや個人的なミートアップ、メーリングリストやフォーラムでの投稿などのオンラインの形態を通じて DIWO を実践しています。私たちはギャングサインすら持っています。なぜなら仲間となるときにはギャングサインを持つべきだからです。私たちが強調したい最も大事な点は、あなたは独りではなく、学び、教え、ハックし、コードの創造的な側面を追求する人々による素晴らしいグループがあるということです。 +openFrameworks の背後にある強い哲学は「皆でやろう (Do it with others / DIWO)」というものです。私たちは Instructables や Make といったチュートリアルサイトの興りによって盛んに宣伝され手がけられている「自分でやろう Do it yourself (DIY) カルチャーを愛しています。しかし私たちは「ソーシャルに作る」（皆と）というアイデアにも興奮します。私たちはワークショップ、デベロッパカンファレンス、ハッカソン/ラボ、手芸サークルや個人的なミートアップ、メーリングリストやフォーラムでの投稿などのオンラインの形態を通じて DIWO を実践しています。私たちはギャングサインすら持っています。なぜなら仲間となるときにはギャングサインを持つべきだからです。私たちが強調したい最も大事な点は、あなたは独りではなく、学び、教え、ハックし、コードの創造的な側面を追求する人々による素晴らしいグループがあるということです。 From 8607ce013740b948f6ce4f2b33e7ec53d381e4f5 Mon Sep 17 00:00:00 2001 From: Hiroyuki Kurosawa Date: Thu, 29 Aug 2019 02:14:51 +0900 Subject: [PATCH 7/8] =?UTF-8?q?=E8=A8=B3=E6=96=87=E3=81=AE=E8=A6=8B?= =?UTF-8?q?=E7=9B=B4=E3=81=97?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- chapters/of_philosophy/chapter.ja.md | 34 ++++++++++++++-------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/chapters/of_philosophy/chapter.ja.md b/chapters/of_philosophy/chapter.ja.md index f7228ce6..712d6187 100644 --- a/chapters/of_philosophy/chapter.ja.md +++ b/chapters/of_philosophy/chapter.ja.md @@ -10,7 +10,7 @@ _by [Zach Lieberman](http://thesystemis.com)_ The endeavour of openFrameworks is guided by a number of goals: it should be collaborative, usable and simple, consistent and intuitive, cross-platform, powerful, and extensible. It is also driven by a "do it with others" (DIWO) philosophy. --> -openFrameworks の航海は幾つかのゴールによってその指針が示されています：それは協働的であること、実用的かつシンプルであること、一貫性があり直感的であること、クロスプラットフォーム、パワフルさ、そして拡張可能であることです。加えて「人と一緒にやろう（do it with others / (DIWO)」の哲学により推進されています。 +openFrameworks は幾つかのゴールに向かった取り組みを行なっています。それは協働的であること、実用的かつシンプルであること、一貫性があり直感的であること、クロスプラットフォームであること、パワフルさ、そして拡張可能であることです。加えて、「皆でやろう（do it with others / (DIWO)」の哲学によって推進されています。 -openFrameworks の開発は協働的なもので、議論に盛んに参加し、アドオンやプロジェクト上で協働する多くの人々の貢献の上に成り立っています。私たちは皆が openFrameworks を我が物とし、エコシステムに貢献することを推奨します。 +openFrameworks の開発は協働的なもので、議論に盛んに参加し、アドオンやプロジェクト上で協働する多くの人々の貢献の上に成り立っています。私たちは皆が openFrameworks を我が物とし、このエコシステムに貢献することを推奨しています。 -私たちは git という分散型バージョン管理システムを用いていて、これは人々がブランチを作り、実験し、提案が可能なことを意味します。[GitHub](https://github.com/openframeworks/openFrameworks "link to the GitHub repository of openFrameworks") のネットワーク図を見てみると、沢山の曲がりくねったブランチ、枝分かれしてまた合流するコードによるエイリアンのダイヤグラムのように見えます。コアのコードに対して作業する世界中にまたがる巨大なコミュニティが存在します：彼らはバグを修正し、プルリクエストを送り、見たいような形のツールを具現化します。これは全世界的なプロジェクトであり、合衆国で目を覚ますとアジアやヨーロッパのプログラマからのプルリクエストやイシューの電子メールでいっぱいの受信箱を目にすることは日常茶飯事です。 +私たちは git という分散型バージョン管理システムを用いています。これは人々がブランチを作り、実験し、提案が可能なことを意味します。[GitHub](https://github.com/openframeworks/openFrameworks "link to the GitHub repository of openFrameworks") のネットワーク図を見てみると、沢山の曲がりくねったブランチ、枝分かれしてまた合流するコードによるエイリアンのダイヤグラムのように見えます。コアのコードに対して作業する、世界中に広がる巨大なコミュニティが存在します。彼らはバグを修正し、プルリクエストを送り、必要な形のツールを具現化します。これは全世界的なプロジェクトであり、合衆国で目を覚ました時に、アジアやヨーロッパのプログラマからのプルリクエストやイシューで一杯の電子メールの受信箱を目にすることは日常茶飯事です。 @@ -39,13 +39,13 @@ We use git, a distributed versioning system, which means that people can branch, openFrameworks tries to balance usability and simplicity. The earliest versions of openFrameworks used the core as a tool for teaching C++ and [OpenGL](https://en.wikipedia.org/wiki/OpenGL "wikipedia article on OpenGL"), but over time the examples have become the best way to learn while the core takes advantage of more advanced features. In exchange, we've created many more examples that come with openFrameworks, with the goal of trying to make simple, hackable starting points for experimentation. --> -openFrameworks は有用性とシンプルさのバランスを目指しています。openFrameworks の最初期のバージョンは C++ と [OpenGL](https://en.wikipedia.org/wiki/OpenGL "wikipedia article on OpenGL")を教えるためのツールとしてその中核の部分を利用していましたが、時を経るにつれて中核部分がより先進的な機能を取り入れるようになり、サンプル（examples）が学習のための最適な方法となりました。引き換えに、物事をシンプルにし、それを実験のための改変可能なスタートポイントとするべく、私たちは openFrameworks に同梱される沢山のサンプルを作成しました。 +openFrameworks は有用性とシンプルさのバランスを取ることを目指しています。openFrameworks の最初期のバージョンは C++ と [OpenGL](https://en.wikipedia.org/wiki/OpenGL "wikipedia article on OpenGL")を教えるためのツールとしてその中核の部分を利用していましたが、時を経るにつれて中核部分はより先進的な機能を取り入れるようになり、サンプル（examples）が学習のための最適な方法となりました。代わりに openFrameworks に同梱される沢山のサンプルを作成して、実験のために改変していけるシンプルなスタート地点としました。 -私たちは openFrameworks を可能な限り、特に他の言語や環境から来た人々にとってシンプルなものにしたいです。C++ は「大きな」言語であり、それは全く違うタイプの様々な C++ コードを書くことが出来るという意味です。書店に行けば何百もの C++ の書籍を目にするでしょう。私たちはあなた方が専門家になる必要なく、多くとも一冊か二冊の書籍が必要とされ、コードのパターン、アプローチとスタイルはシンプルで直感的であるようなライブラリを作りたいです。私たちは [Processing](http://www.processing.org/ "processing language and IDE website") とある意味同質となること、つまり多くの機能が似通っていて一方のフレームワークから他方への移行が容易になることに特に関心を持っていました。 +可能な限り、私たちは openFrameworks を特に他の言語や環境から来た人々にとってシンプルなものにしたいです。C++ は「大きな」言語で、それはつまり全く違うタイプの様々な C++ コードを書くことが出来るという意味です。書店に行けば何百もの C++ の書籍を目にするでしょう。私たちはあなた方が専門家になる必要なく、多くとも一冊か二冊があれば事足りて、コードのパターン、アプローチやスタイルはシンプルかつ直感的であるようなライブラリを作りたいのです。私たちは [Processing](http://www.processing.org/ "processing language and IDE website") とある意味で同質となること、つまり多くの機能が似通っていて一方のフレームワークから他方への移行が容易になることに特に関心を持っていました。 -openFrameworks は一貫性があり直感的です：これは最小の驚きの原則によって運営されており、openFrameworks のあるパートで学んだことは別のパートでも適用可能です。初学者は openFrameworks をよくあるプログラミングのパターンについて学ぶことに使い、上級者は他の言語やツールキットでの経験を適用することができるでしょう。 +openFrameworks は一貫性があり直感的です。これは最小の驚きの原則によって運営されており、openFrameworks のあるパートで学んだことは別のパートでも適用可能です。初学者は openFrameworks をよくあるプログラミングのパターンについて学ぶことに使い、上級者は他の言語やツールキットでの経験を適用することができるでしょう。 -学生ファーストであることがモットーです。openFrameworks を導く上で多く考えることは：私は 5 年か 10 年前だったらどんなツールを好んだか？コーディングのパターンはできる限りシンプルでタイピングしやすいものにしたい。これは動画のプレーヤにおいては "play" や "stop" といった自己言及的な関数名や直感的な変数名を持つことを意味します。直感的であることについては私たちは数多く議論していますが、これはコードを出来るだけ素直な物にしたいという要求によっています。タイプすることによって学び、オートコンプリート機能は助けになる、等々。 +学生ファーストであることがモットーです。openFrameworks を導く上で多く考えることは、私が 5 年あるいは 10 年前だったらどんなツールを好んだろうか？コーディングのパターンはできる限りシンプルでタイピングしやすいものにしたいです。これは動画のプレーヤにおいては "play" や "stop" といった自己言及的な関数名や直感的な変数名を持つことを意味します。直感的であることについては私たちは数多くの議論をしていますが、これはコードを出来るだけ素直な物にしたいという要求によるものです。タイプすることによって学んだり、オートコンプリート機能は使えるべきである、などです。 -### クロスプラットフォーム +### クロスプラットフォームであること -openFrameworks はクロスプラットフォームなツールキットです。openFrameworks は可能な限り多くの開発環境や OS をサポートします。openFrameworks をダウンロードをするには任意のプラットフォームや開発環境を選ぶことができ、学んだり遊んだりできるプロジェクトやサンプルを入手できます。移植が困難なコードはコアの部分からは取り除かれ、代わりにアドオンの中に置かれます。 +openFrameworks はクロスプラットフォームなツールキットです。openFrameworks は可能な限り多くの開発環境や OS をサポートします。openFrameworks をダウンロードをする際には任意のプラットフォームや開発環境を選ぶことができ、学んだりそれで遊んだりできるプロジェクトやサンプルを入手できます。移植が困難なコードはコアの部分からは取り除かれ、代わりにアドオンの中に置かれます。 -クロスプラットフォームなライブラリの良い点は、あなたのアイデアをプラットフォームをまたいで移植することが容易なことです。ラップトップ上でスケッチし、即座に電話機上で実行できます。プラットフォームを超えて動作する何かを作成するような退屈な仕事の心配をせずにアイデアを最優先にできるのです。 +クロスプラットフォームなライブラリの良い点は、あなたのアイデアをプラットフォームをまたいで移植することが簡単なことです。ラップトップ上でスケッチし、即座に電話機上で実行できます。プラットフォームをまたいで動作させるための退屈な仕事の心配をせず、アイデアを最優先にできるのです。 -openFrameworks はパワフルです：[OpenCV](http://opencv.org/ "OpenCV, a library for (real-time) computer vision")のような高度なライブラリを利用したり、グラフィックカードのようなハードウエアを効果的に使ったり、カメラやその他のデバイスのような周辺機器を接続することができます。 +openFrameworks はパワフルです。[OpenCV](http://opencv.org/ "OpenCV, a library for (real-time) computer vision")のような高度なライブラリを利用したり、グラフィックカードのようなハードウエアを効果的に使ったり、カメラやその他のデバイスといった周辺機器を接続することができます。 -私たちが C++ を選択したのは、それがかなり低レベルな言語でありながら高レベルなやり方でプログラムすることが可能だからです。C++ はより古い C 言語の拡張なので、とても低レベルでオールドスクールな C コードや、より高レベルな C++ コードを記述できます。openFrameworks で、私たちは両方のアプローチを使い、シンプル、明瞭でありながらパワフルなコードとの関わりを提示します。C++ を利用することはまた、他の言語のラッパに依存することなく C や C++ で書かれた沢山のライブラリと接続することを容易にしています。 +私たちが C++ を選択したのは、それがかなり低レベルな言語でありながら高レベルなやり方でプログラムすることが可能だからです。C++ はより古い C 言語の拡張なので、とても低レベルでオールドスクールな C コードや、より高レベルな C++ コードを記述できます。openFrameworks では私たちは両方のアプローチを使い、シンプル、明瞭でありながらパワフルなコードとの関わりを提示します。C++ を利用することはまた、他の言語のラッパに依存することなく C や C++ で書かれた沢山のライブラリと接続することを容易にしています。 -openFramewoks は基本として OpenGL や [Cairo](http://cairographics.org/ "Cairo, a vector graphics library")、[FreeType](http://freetype.org/ "FreeType, a software library to render fonts")、[FreeImage](http://freeimage.sourceforge.net/ "FreeImage, a library to work with common computer graphic image formats")、OpenCV といったライブラリをラップしています。openFrameworks はユーザーコード（あなたが記述するコード）とこれらのライブラリの間の層として考えることができます。これらのライブラリには異なるスタイルやイディオムやアプローチがあります。そして私たちの仕事はそれらをラップして、一貫性があり直感的なものとすることです。 +openFramewoks は基本として OpenGL や [Cairo](http://cairographics.org/ "Cairo, a vector graphics library")、[FreeType](http://freetype.org/ "FreeType, a software library to render fonts")、[FreeImage](http://freeimage.sourceforge.net/ "FreeImage, a library to work with common computer graphic image formats")、OpenCV といったライブラリをラップしています。openFrameworks はユーザーコード（あなたが記述するコード）とこれらのライブラリの間にある層として考えることができます。これらのライブラリには異なるスタイルやイディオムやアプローチがあります。そして私たちの仕事はそれらをラップして、一貫性があり直感的なものとすることです。 @@ -121,13 +121,13 @@ openFramewoks は基本として OpenGL や [Cairo](http://cairographics.org/ "C openFrameworks is extensible. When you find something missing from openFrameworks it's easy to create addons that extend it. The core addons for openFrameworks generally wrap libraries rather than solving problems in novel ways. When openFrameworks wraps libraries, the libraries are left exposed for further hacking. --> -openFrameworks は拡張可能です。もし openFrameworks に足りない物を見つけた場合、拡張するアドオンを作成することは容易です。openFrameworks の中核のアドオンは斬新な方法で問題を解決するというよりは、概してライブラリをラップしています。openFrameworks はライブラリをラップしていますが、それらのライブラリはさらなるハックのために外部に露出されたままです。 +openFrameworks は拡張可能です。もし openFrameworks に足りない物を見つけた場合、簡単に拡張するアドオンを作成できます。openFrameworks の中核のアドオンは斬新な方法で問題を解決するというよりは、概してライブラリをラップしています。openFrameworks はライブラリをラップしていますが、それらのライブラリはさらなるハックのために外部に露出されたままです。 -あなたが望むものを構築する際の openFrameworks の概念の一つは足場、もしくは足がかりとなる肩です。中核部分を軽量に保つことに資しているものの一つは、全てのものを可能な限り同梱しようとするのではなく、追加的なコード、ライブラリ、アプローチが必要に応じてユーザー間で共有されプロジェクトに編み込まれるように openFrameworks が「アドオン」のシステムを持っていることです。 +あなたが望むものを構築する際の openFrameworks の概念の一つは足場、もしくは足がかりとなる肩です。中核部分を軽量に保つことができるよう、 openFrameworks では全てのものをできるだけ同梱しようとする代わりに「アドオン」のシステムを持っていて、追加のコード、ライブラリ、アプローチがユーザー間で共有され、必要に応じてプロジェクトに組み込むことができるのです。 -私たちは、アドオンを開発するコミュニテイを整え支援することを [http://ofxaddons.com](http://ofxaddons.com "ofxaddons, a collection of oF addons") というサイトを通じて行い、これは自動的に Github 上からタイトルに "ofx" という語彙を含むレポジトリを探すことでアドオンを収集しています。 +私たちは、[http://ofxaddons.com](http://ofxaddons.com "ofxaddons, a collection of oF addons") というサイトを通じてアドオンを開発するコミュニテイを整え支援しています。これは Github 上からタイトルに "ofx" という語彙を含むレポジトリを探すことで自動的にアドオンを収集しています。 -openFrameworks の背後にある強い哲学は「皆でやろう (Do it with others / DIWO)」というものです。私たちは Instructables や Make といったチュートリアルサイトの興りによって盛んに宣伝され手がけられている「自分でやろう Do it yourself (DIY) カルチャーを愛しています。しかし私たちは「ソーシャルに作る」（皆と）というアイデアにも興奮します。私たちはワークショップ、デベロッパカンファレンス、ハッカソン/ラボ、手芸サークルや個人的なミートアップ、メーリングリストやフォーラムでの投稿などのオンラインの形態を通じて DIWO を実践しています。私たちはギャングサインすら持っています。なぜなら仲間となるときにはギャングサインを持つべきだからです。私たちが強調したい最も大事な点は、あなたは独りではなく、学び、教え、ハックし、コードの創造的な側面を追求する人々による素晴らしいグループがあるということです。 +openFrameworks の背後にある強い哲学は「皆でやろう (Do it with others / DIWO)」というものです。私たちは Instructables や Make といったチュートリアルサイトの興りによって盛んに宣伝され手がけられている「自分でやろう Do it yourself (DIY) カルチャーを愛しています。しかし私たちは「ソーシャルに作る」（皆で）というアイデアにも興奮します。私たちはワークショップ、デベロッパカンファレンス、ハッカソン/ラボ、手芸サークルや個人的なミートアップ、メーリングリストやフォーラムでの投稿などのオンラインの形態を通じて DIWO を実践しています。私たちはギャングサインすら持っています。なぜなら仲間となるときにはギャングサインを持つべきだからです。私たちが強調したい最も大事な点は、あなたは独りではなく、学び、教え、ハックし、コードの創造的な側面を探求する人々による素晴らしいグループがあるということです。 From 006b3f5a989de59456fc3cf37c43a3ebf6a40705 Mon Sep 17 00:00:00 2001 From: Hiroyuki Kurosawa Date: Sun, 7 Aug 2022 08:48:25 +0900 Subject: [PATCH 8/8] Update chapter.ja.md changed translation according to review https://github.com/openframeworks/ofBook/pull/301#issuecomment-536855383 --- chapters/of_philosophy/chapter.ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/of_philosophy/chapter.ja.md b/chapters/of_philosophy/chapter.ja.md index 712d6187..c0f8c987 100644 --- a/chapters/of_philosophy/chapter.ja.md +++ b/chapters/of_philosophy/chapter.ja.md @@ -28,7 +28,7 @@ openFrameworks の開発は協働的なもので、議論に盛んに参加し We use git, a distributed versioning system, which means that people can branch, experiment, and make suggestions. If you look at the network diagram on [GitHub](https://github.com/openframeworks/openFrameworks "link to the GitHub repository of openFrameworks"), it looks like some alien diagram, full of weaving branches, code pulling apart and coming together. There's a huge community all over the world working on the core code: fixing bugs, submitting pull requests, and shaping the tool the way they want to see it. It's a world wide project and it's common to wake up in the USA to an inbox full of pull requests and issues emails from coders in Asia and Europe. Over 70 people have contributed to the openFrameworks core directly, and hundreds of people have forked the code or contributed in other ways. --> -私たちは git という分散型バージョン管理システムを用いています。これは人々がブランチを作り、実験し、提案が可能なことを意味します。[GitHub](https://github.com/openframeworks/openFrameworks "link to the GitHub repository of openFrameworks") のネットワーク図を見てみると、沢山の曲がりくねったブランチ、枝分かれしてまた合流するコードによるエイリアンのダイヤグラムのように見えます。コアのコードに対して作業する、世界中に広がる巨大なコミュニティが存在します。彼らはバグを修正し、プルリクエストを送り、必要な形のツールを具現化します。これは全世界的なプロジェクトであり、合衆国で目を覚ました時に、アジアやヨーロッパのプログラマからのプルリクエストやイシューで一杯の電子メールの受信箱を目にすることは日常茶飯事です。 +私たちは git という分散型バージョン管理システムを用いています。これは人々がブランチを作り、実験し、提案が可能なことを意味します。[GitHub](https://github.com/openframeworks/openFrameworks "link to the GitHub repository of openFrameworks") のネットワーク図を見てみると、沢山の曲がりくねったブランチ、枝分かれしてまた合流するコードによるエイリアンのダイヤグラムのように見えます。コアのコードに対して作業する、世界中に広がる巨大なコミュニティが存在します。彼らはバグを修正し、プルリクエストを送り、必要な形のツールを具現化します。これは世界的なプロジェクトであり、アメリカ合衆国住まいのプログラマーが目を覚ましたときに、昨晩中にアジアやヨーロッパから来た様々のプルリクエストやイシューを目にすることは日常茶飯事です。