データ型 - The Rust Programming Language 日本語版
では、どの整数型を使うべきかはどう把握すればいいのでしょうか？もし確信が持てないのならば、 Rustの基準型は一般的にいい選択肢になります。整数型の基準はi32型です: 64ビットシステム上でも、 この型が普通最速になります。isizeとusizeを使う主な状況は、何らかのコレクションにアクセスすることです。 浮動小数点型 Rustにはさらに、浮動小数点数に対しても、2種類の基本型があり、浮動小数点数とは数値に小数点がついたもののことです。 Rustの浮動小数点型は、f32とf64で、それぞれ32ビットと64ビットサイズです。基準型はf64です。 なぜなら、現代のCPUでは、f32とほぼ同スピードにもかかわらず、より精度が高くなるからです。 実際に動作している浮動小数点数の例をご覧ください: ファイル名: src/main.rs fn main() { let x = 2.0; // f6
変数と可変性 - The Rust Programming Language 日本語版
変数と可変性 第2章で触れた通り、変数は標準で不変になります。これは、 Rustが提供する安全性や簡便な並行性の利点を享受する形でコードを書くための選択の1つです。 ところが、まだ変数を可変にするという選択肢も残されています。 どのように、そしてなぜRustは不変性を推奨するのか、さらには、なぜそれとは違う道を選びたくなることがあるのか見ていきましょう。 変数が不変であると、値が一旦名前に束縛されたら、その値を変えることができません。 これを具体的に説明するために、projectsディレクトリにcargo new --bin variablesコマンドを使って、 variablesという名前のプロジェクトを生成しましょう。 それから、新規作成したvariablesディレクトリで、src/main.rsファイルを開き、 その中身を以下のコードに置き換えましょう。このコードはまだコンパイルでき
Hello, Cargo! - The Rust Programming Language 日本語版
Hello, Cargo! CargoはRustのビルドシステム兼パッケージマネージャです。 ほとんどのRustaceanはこのツールを使ってRustプロジェクトを管理しています。 なぜなら、Cargoは多くの仕事、たとえばコードのビルド、コードが依存するライブラリのダウンロード、それらのライブラリのビルドなどを扱ってくれるからです。 （コードが必要とするライブラリのことを依存（dependencies）と呼びます） いままでに書いたようなごく単純なRustプログラムには依存がありません。 そのため「Hello, world!」プロジェクトをCargoでビルドしても、Cargoの中のコードをビルドする部分しか使わないでしょう。 より複雑なRustプログラムを書くようになると依存を追加することになりますが、Cargoを使ってプロジェクトを開始したなら、依存の追加もずっと簡単になります。 Ru
Hello, World! - The Rust Programming Language 日本語版
Hello, World! Rustをインストールしたので、最初のRustプログラムを書きましょう。新しい言語を学ぶ際に、 Hello, world!というテキストを画面に出力する小さなプログラムを書くことは伝統的なことなので、 ここでも同じようにしましょう！ 注釈: この本は、コマンドラインに基礎的な馴染みがあることを前提にしています。Rustは、編集やツール、 どこにコードがあるかについて特定の要求をしないので、コマンドラインではなくIDEを使用することを好むのなら、 どうぞご自由にお気に入りのIDEを使用してください。今では、多くのIDEがなんらかの形でRustをサポートしています; 詳しくは、IDEのドキュメンテーションをご覧ください。最近、Rustチームは優れたIDEサポートを有効にすることに注力し、 その前線で急激に成果があがっています！ プロジェクトのディレクトリを作成する
オブジェクト指向デザインパターンを実装する - The Rust Programming Language 日本語版
オブジェクト指向デザインパターンを実装する ステートパターンは、オブジェクト指向デザインパターンの1つです。このパターンの肝は、 値が一連のステートオブジェクトで表されるなんらかの内部状態を持ち、 その内部の状態に基づいて値の振る舞いが変化するというものです。ステートオブジェクトは、 機能を共有します: Rustでは、もちろん、オブジェクトと継承ではなく、構造体とトレイトを使用します。 各ステートオブジェクトは、自身の振る舞いと別の状態に変化すべき時を司ることに責任を持ちます。 ステートオブジェクトを保持する値は、状態ごとの異なる振る舞いや、いつ状態が移行するかについては何も知りません。 ステートパターンを使用することは、プログラムの業務要件が変わる時、状態を保持する値のコードや、 値を使用するコードを変更する必要はないことを意味します。ステートオブジェクトの1つのコードを更新して、 規則
トレイトオブジェクトで異なる型の値を許容する - The Rust Programming Language 日本語版
トレイトオブジェクトで異なる型の値を許容する 第8章で、ベクタの1つの制限は、たった1つの型の要素を保持することしかできないことだと述べました。 リスト8-10で整数、浮動小数点数、テキストを保持する列挙子のあるSpreadsheetCell enumを定義して、 これを回避しました。つまり、各セルに異なる型のデータを格納しつつ、1行のセルを表すベクタを保持するということです。 コンパイル時にわかるある固定されたセットの型にしか取り替え可能な要素がならない場合には、 完璧な解決策です。 ところが、時として、ライブラリの使用者が特定の場面で合法になる型のセットを拡張できるようにしたくなることがあります。 これをどう実現する可能性があるか示すために、各アイテムにdrawメソッドを呼び出してスクリーンに描画するという、 GUIツールで一般的なテクニックをしてあるリストの要素を走査する例のGUIツ
オブジェクト指向言語の特徴 - The Rust Programming Language 日本語版
オブジェクト指向言語の特徴 言語がオブジェクト指向と考えられるのになければならない機能について、プログラミングコミュニティ内での総意はありません。 RustはOOPを含めた多くのプログラミングパラダイムに影響を受けています; 例えば、 第13章で関数型プログラミングに由来する機能を探究しました。議論はあるかもしれませんが、 OOP言語は特定の一般的な特徴を共有しています。具体的には、オブジェクトやカプセル化、 継承などです。それらの個々の特徴が意味するものとRustがサポートしているかを見ましょう。 オブジェクトは、データと振る舞いを含む エーリヒ・ガンマ(Enoch Gamma)、リチャード・ヘルム(Richard Helm)、ラルフ・ジョンソン(Ralph Johnson)、 ジョン・ブリシディース(John Vlissides)(アディソン・ワズリー・プロ)により、 1994年に書か
はじめに
Rust 裏本 高度で危険な Rust Programming のための闇の技法 NOTE: この文書はドラフトです。重大な間違いを含んでいるかもしれません。 私に与えられたのは、望んだようなプログラムではなく、身を震わせるような暗黒と言い表せないような孤独であった。そして私はついに、誰ひとり口にしようともしなかった恐ろしい真実、ささやくことすらできない神秘中の神秘を目にしたのだ。石のように硬く、耳障りな音をたてるこの言語は、ロンドンが古きロンドンではなく、パリが古きパリではないように、Rust の御代をとこしえにするものではなく、実はきわめて危険で、不完全に防腐処理された、だらしなく寝そべった死体だったのだ。そこにはコンパイル時に生まれた奇妙な生き物たちが所在なさげに蔓延っていた。 （訳注: H.P. ラヴクラフトの小説「あの男」のパロディのようです。） この本は、危険な Rust プロ
SyncとSendトレイトで拡張可能な並行性 - The Rust Programming Language 日本語版
SyncとSendトレイトで拡張可能な並行性 面白いことに、Rust言語には、寡少な並行性機能があります。この章でここまでに語った並行性機能のほとんどは、 標準ライブラリの一部であり、言語ではありません。並行性を扱う選択肢は、言語や標準ライブラリに制限されません; 独自の並行性機能を書いたり、他人が書いたものを利用したりできるのです。 ですが、2つの並行性概念が言語に埋め込まれています: std::markerトレイトのSyncとSendです。 Sendでスレッド間の所有権の転送を許可する Sendマーカートレイトは、Sendを実装した型の所有権をスレッド間で転送できることを示唆します。 Rustのほとんどの型はSendですが、Rc<T>を含めて一部例外があります: この型は、Rc<T>の値をクローンし、 クローンしたものの所有権を別のスレッドに転送しようとしたら、両方のスレッドが同時に参
状態共有並行性 - The Rust Programming Language 日本語版
状態共有並行性 メッセージ受け渡しは、並行性を扱う素晴らしい方法ですが、唯一の方法ではありません。 Go言語ドキュメンテーションのスローガンのこの部分を再び考えてください: 「メモリを共有することでやり取りする。」 メモリを共有することでやり取りするとはどんな感じなのでしょうか？さらに、 なぜメッセージ受け渡しに熱狂的な人は、それを使わず、代わりに全く反対のことをするのでしょうか？ ある意味では、どんなプログラミング言語のチャンネルも単独の所有権に類似しています。 一旦チャンネルに値を転送したら、その値は最早使用することがないからです。 メモリ共有並行性は、複数の所有権に似ています: 複数のスレッドが同時に同じメモリ位置にアクセスできるのです。 第15章でスマートポインタが複数の所有権を可能にするのを目の当たりにしたように、 異なる所有者を管理する必要があるので、複数の所有権は複雑度を増さ
メッセージ受け渡しを使ってスレッド間でデータを転送する - The Rust Programming Language 日本語版
メッセージ受け渡しを使ってスレッド間でデータを転送する 人気度を増してきている安全な並行性を保証する一つのアプローチがメッセージ受け渡しで、 スレッドやアクターがデータを含むメッセージを相互に送り合うことでやり取りします。 こちらが、Go言語のドキュメンテーションのスローガンにある考えです: 「メモリを共有することでやり取りするな; 代わりにやり取りすることでメモリを共有しろ」 メッセージ送信並行性を達成するためにRustに存在する一つの主な道具は、チャンネルで、 Rustの標準ライブラリが実装を提供しているプログラミング概念です。プログラミングのチャンネルは、 水の流れのように考えることができます。小川とか川ですね。アヒルのおもちゃやボートみたいなものを流れに置いたら、 水路の終端まで下流に流れていきます。 プログラミングにおけるチャンネルは、2分割できます: 転送機と受信機です。転送機
スレッドを使用してコードを同時に走らせる - The Rust Programming Language 日本語版
スレッドを使用してコードを同時に走らせる 多くの現代のOSでは、実行中のプログラムのコードはプロセスで走り、OSは同時に複数のプロセスを管理します。 自分のプログラム内で、独立した部分を同時に実行できます。これらの独立した部分を走らせる機能をスレッドと呼びます。 プログラム内の計算を複数のスレッドに分けると、パフォーマンスが改善します。プログラムが同時に複数の作業をするからですが、 複雑度も増します。スレッドは同時に走らせることができるので、異なるスレッドのコードが走る順番に関して、 本来的に保証はありません。これは例えば以下のような問題を招きます: スレッドがデータやリソースに矛盾した順番でアクセスする競合状態 2つのスレッドがお互いにもう一方が持っているリソースを使用し終わるのを待ち、両者が継続するのを防ぐデッドロック 特定の状況でのみ起き、確実な再現や修正が困難なバグ Rustは、ス
恐れるな！並行性 - The Rust Programming Language 日本語版
恐れるな！並行性 並行性を安全かつ効率的に扱うことは、Rustの別の主な目標です。並行プログラミングは、プログラムの異なる部分が独立して実行することであり、 並列プログラミングはプログラムの異なる部分が同時に実行することですが、多くのコンピュータが複数のプロセッサの利点を生かすようになるにつれ、 重要度を増しています。歴史的に、これらの文脈で行うプログラミングは困難で、エラーが起きやすいものでした: Rustはこれを変えると願っています。 当初、Rustチームは、メモリ安全性を保証することと、並行性問題を回避することは、 異なる方法で解決すべき別々の課題だと考えていました。時間とともに、チームは、所有権と型システムは、 メモリ安全性と並行性問題を管理する役に立つ一連の強力な道具であることを発見しました。 所有権と型チェックを活用することで、多くの並行性エラーは、実行時エラーではなくコンパイ
循環参照は、メモリをリークすることもある - The Rust Programming Language 日本語版
循環参照は、メモリをリークすることもある Rustのメモリ安全保証により誤って絶対に片付けられることのないメモリ(メモリリークとして知られています)を生成してしまいにくくなりますが、 不可能にはなりません。コンパイル時にデータ競合を防ぐのと同じようにメモリリークを完全に回避することは、 Rustの保証の一つではなく、メモリリークはRustにおいてはメモリ安全であることを意味します。 Rustでは、Rc<T>とRefCell<T>を使用してメモリリークを許可するとわかります: 要素がお互いに循環して参照する参照を生成することも可能ということです。循環の各要素の参照カウントが絶対に0にならないので、 これはメモリリークを起こし、値は絶対にドロップされません。 循環参照させる リスト15-25のList enumの定義とtailメソッドから始めて、どう循環参照が起こる可能性があるのかとその回避策
RefCell<T>と内部可変性パターン - The Rust Programming Language 日本語版
RefCell<T>と内部可変性パターン 内部可変性は、そのデータへの不変参照がある時でさえもデータを可変化できるRustでのデザインパターンです: 普通、この行動は借用規則により許可されません。データを可変化するために、このパターンは、データ構造内でunsafeコードを使用して、 可変性と借用を支配するRustの通常の規則を捻じ曲げています。まだ、unsafeコードについては講義していません; 第19章で行います。たとえ、コンパイラが保証できなくても、借用規則に実行時に従うことが保証できる時、 内部可変性パターンを使用した型を使用できます。関係するunsafeコードはそうしたら、安全なAPIにラップされ、 外側の型は、それでも不変です。 内部可変性パターンに従うRefCell<T>型を眺めてこの概念を探究しましょう。 RefCell<T>で実行時に借用規則を強制する Rc<T>と異なり、
Rc<T>は、参照カウント方式のスマートポインタ - The Rust Programming Language 日本語版
Rc<T>は、参照カウント方式のスマートポインタ 大多数の場合、所有権は明らかです: 一体どの変数が与えられた値を所有しているかわかるのです。 ところが、単独の値が複数の所有者を持つ可能性のある場合もあります。例えば、グラフデータ構造では、 複数の辺が同じノードを指す可能性があり、概念的にそのノードはそれを指す全ての辺に所有されるわけです。 指す辺がなくならない限り、ノードは片付けられるべきではありません。 複数の所有権を可能にするため、RustにはRc<T>という型があり、これは、reference counting(参照カウント)の省略形です。 Rc<T>型は、値がまだ使用中かどうか決定する値への参照の数を追跡します。値への参照が0なら、どの参照も無効にすることなく、 値は片付けられます。 Rc<T>を家族部屋のテレビと想像してください。1人がテレビを見に部屋に入ったら、テレビをつけま
Dropトレイトで片付け時にコードを走らせる - The Rust Programming Language 日本語版
Dropトレイトで片付け時にコードを走らせる スマートポインタパターンにとって重要な2番目のトレイトは、Dropであり、 これのおかげで値がスコープを抜けそうになった時に起こることをカスタマイズできます。 どんな型に対してもDropトレイトの実装を提供することができ、指定したコードは、 ファイルやネットワーク接続などのリソースを解放するのに活用できます。 Dropをスマートポインタの文脈で導入しています。Dropトレイトの機能は、ほぼ常にスマートポインタを実装する時に使われるからです。 例えば、Box<T>はDropをカスタマイズしてボックスが指しているヒープの領域を解放しています。 ある言語では、プログラマがスマートポインタのインスタンスを使い終わる度にメモリやリソースを解放するコードを呼ばなければなりません。 忘れてしまったら、システムは詰め込みすぎになりクラッシュする可能性があります
Derefトレイトでスマートポインタを普通の参照のように扱う - The Rust Programming Language 日本語版
Derefトレイトでスマートポインタを普通の参照のように扱う Derefトレイトを実装することで、参照外し演算子の*（掛け算やグロブ演算子とは違います）の振る舞いをカスタマイズできます。 Derefを実装してスマートポインタを普通の参照みたいに扱えるようにすれば、 参照に対して処理を行うコードを書いて、そのコードをスマートポインタに対しても使うことができるのです。 まずは、参照外し演算子が普通の参照に対して動作するところを見ましょう。それから、Box<T>のように振る舞う独自の型を定義してみましょう。 参照とは異なり、新しく定義した型には参照外し演算子を使えません。その理由を確認します。 Derefトレイトを実装すればスマートポインタは参照と同じように機能するので、そのやり方を調べましょう。 そして、Rustには参照外し型強制という機能があり、その機能のおかげで参照やスマートポインタをうま
ヒープのデータを指すBox<T>を使用する - The Rust Programming Language 日本語版
ヒープのデータを指すBox<T>を使用する 最も素直なスマートポインタはボックスであり、その型はBox<T>と記述されます。 ボックスにより、スタックではなくヒープにデータを格納することができます。スタックに残るのは、 ヒープデータへのポインタです。スタックとヒープの違いを再確認するには、第4章を参照されたし。 ボックスは、データをスタックの代わりにヒープに格納する以外は、パフォーマンスのオーバーヘッドはありません。 しかし、特別な能力がたくさんあるわけでもありません。以下のような場面で最もよく使われるでしょう。 コンパイル時にはサイズを知ることができない型があり、正確なサイズを要求する文脈でその型の値を使用する時 多くのデータがあり、その所有権を移したいが、その際にデータがコピーされないようにしたい時 値を所有する必要があり、特定の型であることではなく、特定のトレイトを実装する型であるこ
スマートポインタ - The Rust Programming Language 日本語版
スマートポインタ ポインタは、メモリのアドレスを含む変数の一般的な概念です。このアドレスは、何らかの他のデータを参照、または「指します」。 Rustにおいて最もありふれた種類のポインタは参照です。参照については第4章で習いましたね。参照は&記号で示唆され、指している値を借用します。データを参照すること以外に特別な能力は何もありません。 また、オーバーヘッドもなく、ポインタの中では最も頻繁に使われます。 一方、スマートポインタは、ポインタのように振る舞うだけでなく、追加のメタデータと能力があるデータ構造です。 スマートポインタという概念は、Rustに特有のものではありません。スマートポインタは、C++に端を発し、 他の言語にも存在しています。Rustでは、標準ライブラリに定義された色々なスマートポインタが、 参照以上の機能を提供します。この章で探究する一つの例が、参照カウント方式のスマートポ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
