hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
機種依存文字 使用するフォントに依存する場合
使用するフォントの相違によって、テキストデータ中の特定の文字が意図しない字形として表示されたり、全く表示・印刷できなくなる場合もある。
標準規格の私用領域（いわゆる外字の領域）を用いて特定の処理系やアプリケーションのための文字や字形を表現したため、異なるシステムでは異なる文字として表示される。たとえば、マイクロソフトの韓国語版WindowsではUHCからUnicodeへのマッピングに際して古ハングルなどの字形を私用領域に割り当てていたが、私用領域を別の用途に使っているシステムでは正しく表示できない。
文字コード規格の改訂によって、例示字形があらためられたもの。たとえば、JIS X 0208の第2次規格（1983年）では複数の異体字関係にある文字同士のコードポイントが入れ替えられた。またJIS X 0213の第2次規格（2004年）では一部の文字の例示字形が印刷標準字体にあらためられた。いずれも、テキストデータとフォントの双方で前提とする規格を一致させなければ意図した表示にならない。
機種依存文字 使用するソフトウェアに依存する場合
使用するソフトウェアによって、同じフォントを使用しても特定の文字が意図しない字形として表示される場合がある。主に文字合成を必要とするものに見られ、例えばアイヌ語を表すカタカナの1つ「ㇷ゚」（小書きのプ）などの一部の小書き文字や、鼻濁音の「か゚」（「か」に半濁点）などが挙げられる。
例外処理
例外処理（れいがいしょり、英語: exception handling）とは、IT業界で用いられる専門用語で、ある抽象レベルにおけるシステムの設計で想定されておらず、ユーザー操作によって解決できない問題に対処するための処理である。例外処理の結果として問題が解決されないとシステム障害になる。システム停止やデータ破損の原因になり、ユーザーに損害を与える可能性があるため、システム開発で例外処理は重要視されている。
システムの設計で想定されておらず、継続不能や継続すると問題になる様な状態としては、次のようなものが挙げられる。
注意点として、あらゆる例外が抽象レベルに依存せずすべて異常系であるとは限らない。例えばページフォルトはカーネル内部のメモリなど例外が許されない環境下ではエラーとなるが、仮想記憶を採用したOSにおけるユーザプロセスのメモリは常時物理的に存在するとは限らないためページフォルトを正常系として処理する必要がある。また、例外処理中にさらなる例外が発生した場合は、通常なら正常系となる事象が異常系に変わる場合がある。詳しくは#例外のネストを参照されたい。
例外処理 例外処理の動作と重要性
例外処理の動作としては、システムを構成するプログラムの各呼び出し階層で、呼び出し先が想定していない入力値を受け取って問題が起きた場合に、問題に合わせた例外を発生させて呼び出し元に処理を返す。呼び出し元に例外を返す事によって、呼び出し元で問題解決が行われることに期待するが、どの呼び出し階層の例外処理でも問題解決できない場合は、システムの内部状態に矛盾が残り、システム障害となる。例外発生の後、システムが動作していても、例外への対処結果が設計から逸脱している場合、システムの内部状態に矛盾を来しており、ストレージやデータベースやネットワークに無意味なデータを出力する可能性が生じ、データ破損のみならず、連携する他システムにも矛盾が伝播して広範なシステム障害に繋がる可能性がある。従って、例外処理はシステム障害を未然に防ぐ意味で非常に重要である。
例外処理 例外とエラーの違い
例外(exception)はシステム担当者が問題解決を行う必要がある。例外の問題解決手段には例外を無視することも含まれるが、明確な根拠をもって無視する必要がある（設計の一環として一部の例外を無視しても問題ないと判断する，連携する他システムのメンテナンス中で例外発生が不可避な場合はメンテナンス完了を待つ）。例外に対して、ユーザーが解決すべき問題はエラー(error)と呼ぶ（但し、業務システム開発ではエラーを業務エラー、例外をシステムエラーと表現する場合もあり、技術者間での厳密な統一見解は存在しない）。何らかのシステム開発を行う会社では、例外への対処が不適切であるとユーザーに損害を与えるため、システム障害を発生させるような例外発生は製品の瑕疵として扱う必要がある。
例外処理 例外安全性
あるコード内を実行中の失敗が、メモリリーク、格納データの不整合、不正な出力などの有害な効果を生じないとき、そのコード片は例外安全であると言う。例外安全なコードは例外が発生したとしてもそのコードが備える不変条件を満たさなければならない。例外安全性にはいくつかのレベルがある:
例外処理 言語サポート
幾つかのプログラミング言語では組み込みの例外処理機能を用意している。例えばAda、C++、Java、Scala、C#、JavaScript、OCamlがそうである。これらの言語では専用の言語機能によってプログラマが例外処理を記述する手間を軽減している。
例外が発生したことを見落として正常時の動作を継続してしまうと、より深刻・致命的な異常を招くおそれがある。それを避けるには例外が発生したことのチェックを綿密に行い、例外が検出された場合には適切な事後処理を行う他ない。しかし、大規模なプログラムではこのようなチェックは膨大なものとなり、本来目的としている正常時の処理よりも多くの記述を必要とする場合すらある。
そこで、これらの言語では例外の発生チェックをほぼ自動化している。例外が発生すると現在の処理を中断する。発生した例外の事後処理を担当できるハンドラを探して次々にコールスタック（関数呼び出し）を遡り、適切なハンドラを見つけるとそれに事後処理を任せる。これにより、遡る途中にあったこの例外を処理する能力を持たない処理は自動的に中断されることになる。
Schemeでは言語レベルでの例外処理を持たないが、これは継続が存在するため例外をライブラリレベルで実現できるからである（標準仕様であるSRFI-34で定義されている）。
例外処理 言語サポート
tryブロック中で呼び出した関数Function0()が(1)のthrowを実行すると、Function1()のcatch文へと制御が移る。C++では後発の言語とは異なり、std::exceptionあるいはその派生型以外の型の値でもthrowで投げることができ、(3)(4)(5)の様に型に対応したcatch文で捕捉することができる。なお、(1)では例示のため複数のthrowを書いているが、実際には1個目のthrowを実行した時点でcatch文に移動する。
例外構文には例外が存在しないことを明示するnoexceptが標準化されている。
例外処理 言語サポート
C++の特徴的な構文として、(6)の省略子を用いたcatchが存在する。あらゆる例外を捕捉可能であり、他のcatchが取りこぼした例外でも捕まえる必要がある場合に用いる。値を指定しないthrowを捕まえられるのも省略子を用いたcatchだけである。また、Microsoft Visual C++といった一部の処理系では、コンパイラオプションの指定によりC++例外だけでなくOSが投げた構造化例外も省略子を用いたcatchで捕捉できる。catch文の中では(7)のように引数の無いthrowを用いた場合、例外の再送を意味する。省略子を用いたcatchの場合は例外情報を判断できないため必須であるが、省略子を使わないcatchでも派生型の例外を基底型で受け取ってしまった場合のスライシングを防ぐために必要となる。
tryブロックは(8)のように関数全体に適用することもできる。これをfunction-try-blockと言う。catch文では局所変数を参照できず引数だけしか参照できないが、コンストラクタの初期化リストで発生した例外やデストラクタから投げられた例外はこの書き方でしか捕捉することができない。
例外処理構文を最初に実装したのはAdaであるが、C++の例外処理構文はJavaやJavaScript、C#など多くの後発言語の規範となった。
例外処理 言語サポート
C++の例外指定 (Exception Specification、例外仕様とも) は、関数から伝達される例外の種類を明示する言語機能である。例えば void f() throw(int) はint型のエラーをthrowしうることを明示している。例外指定はコンパイラによる静的例外検査を想定して用意された機能だが各コンパイラには実装されず、C++11で非推奨になり、C++17をもって廃止された。
例外処理 言語サポート
Javaでは例外はクラスとして実装する。例外を「投げる(throw)」メソッドはthrows Exceptionのように指定する。Javaプラットフォーム上でJava言語を使用し、発生する例外がjava.lang.Exceptionを継承しているが、しかしjava.lang.RuntimeExcptionを継承していない場合、try/catch文で例外処理を明示的に記述するか、メソッドにthrowsを追加する必要がある。ただし、Javaプラットフォーム上で動く言語でも、GroovyやScalaなど、Java言語以外の多くは、RuntimeException以外の例外に対して必ずしも明示的に記述しなくても良くなっている。初期のJava（JDK1.0）では、I/O処理など他の手段では例外の発生を回避することができない種類の例外に対してはRuntimeExceptionを継承させないという設計思想になっていた。
言語機能としては例外処理構文が存在しないが別途例外処理を備える言語も存在する。Smalltalkは言語機能として制御構文が殆どない。このため例外処理構文もブロックを組み合わせたメッセージ式として記述するようになっている。言語機能ではないため極めて柔軟性がありブロックの戻り値を変更したり例外が発生した式の途中から復帰したりなど様々な制御が可能になっている。
例外処理の過程では処理の流れが通常の制御とは大きく変化することとなるが、これを（エラー処理以外の目的で、正常系において）積極的に利用することは、アンチパターンとされることもある。
一方、RubyやPythonでは、イテレータが終端に達するという、無限ループでなければ必ず発生する事象により例外が起きることもあるほか、Rubyでは例外処理と関係なく大域脱出を行う制御構造も用意されている。
Smalltalkでも例外はエラー処理以外の通知として使われる。Smalltalkの例外 (Exception) はエラー (Error) と通知 (Notification) からなり、EOFの通知やスレッド間の割り込み終了通知等に使われている。またSmalltalkは値を検索した結果値が見つからなかった場合の戻り値としてnil (null) を返さない傾向があり、値が見つからなければ例外を投げる。ただし単純な例外処理というパターンがあり、値が見つからない場合でも例外構文を使わず安全に回復する手段を用意している。
通知例外にはエラー例外と異なる特徴的な点がある。通知を投げた場合は、エラーと異なり捕捉しなければ処理を中止せずそのまま続行となる。
例外処理 戻り値と例外
例外処理（例外オブジェクト）をサポートしないCなどの言語では、従来から関数（サブルーチン）の戻り値によってその関数（処理）の成否を判定する方法がとられてきた。慣例的に、関数の戻り値を32ビット整数値などで宣言して、関数が成功した場合は0を返し、失敗した場合はエラーコードとして何らかの負数を返すことが多い。さらに簡略化して、成否の結果を真偽値1/0で返すだけにすることもある。戻り値がポインタ型である場合は、成功した場合に有効なポインタすなわち非NULLを返し、失敗した場合に無効なポインタすなわちNULLを返すのが通例である。標準ライブラリや各種APIでは、詳細を伝えるエラーコードを別途errnoのようなグローバル変数に格納することもある。各エラーコードによって失敗の原因を定義しておき、呼び出し側で原因を判定する。
このような戻り値による処理の成否判定には下記のような問題点がある。
3. に関連する問題として、戻り値が正常系の結果取得に使えないため引数を処理結果の取得用に使い関数インターフェイスおよび呼び出し側のコードが複雑化するという問題がある。
例外処理 戻り値と例外
4.の問題では関数の呼び出し結果をいったんローカル変数に格納することなく次の関数引数にそのまま式として渡すようなこともできなくなる。例えば下記のC言語の例では、atof()関数の戻り値が正常系と異常系とで区別がつかない仕様のため、対象フォーマット外の不正な入力があっても検知できず処理を継続してしまう。例外を使わずにこの問題に対処するには、正常系と異常系とを区別できるようにするために、関数の実装およびインターフェイスが複雑化することを許容しなければならない。
一方、文字列から数値への変換に失敗した場合に例外を投げるライブラリを持つ言語では、メインロジックに関係のないコードを挿入することなく、正常系と異常系とを簡潔かつ明確に区別できる。下記はC#による例である。
例外処理 戻り値と例外
別の例として、たとえば主記憶領域の容量やファイル容量を取得する関数を設計する際、結果を符号なし整数型 (非負数) の戻り値で返すように決めた場合、戻り値でエラー判定用の値を返すことができない。この場合、errnoのようなグローバル変数もしくは別途用意した関数引数経由でエラーコードを返して、呼び出し側で判定する必要がある。たとえばWindows APIのGetFileSize()関数は戻り値でファイルサイズを返すが、混合した設計となっており、エラーが発生した場合は-1を返す。しかし戻り値の型はDWORDつまり符号なし32ビット整数型であるため、実際には0xFFFFFFFFが返却される。これは本来正常値としてありうる値であり、異常系との区別が付かないため、エラーによる結果だったかどうかを判定するにはGetLastError()関数の呼び出しが別途必要になっている。なおGetFileSizeEx()関数は成否を戻り値で、正常系出力を引数で返す設計となっており、GetFileSize()関数の代替として推奨されている。また、C言語において身近な例としてはmallocおよびcalloc、realloc関数があげられる。これらは確保を要求する容量として0を指定したときC言語の規格としてNULLを返して良いと定義されている。このためこれらの関数の戻り値では記憶空間の容量不足か引数に0を指定したか判断できず切り分けのためにerrnoを調べるか引数を調べる必要がある。C++において同等のnew演算子ではこの点を容量不足のときだけ例外を投げることによって改善している。
言語レベルでの例外処理はこれらの欠点を解消し、例外を確実に、かつ統一的に処理する目的で導入されたものと言える。
例外処理 回復処理
処理中に使用可能な記憶領域が枯渇した場合の回復は比較的単純である。
記憶領域が原因として上記が考えられるがGUIプログラムのイベント処理であれば3以外の状況から回復できる。1,2どちらも現在実行中の処理を中断して処理に使った記憶領域を解放すればプロセスを継続できる可能性がある。特に2の状況であればシステムの記憶領域使用状況が回復を待って再度同じ処理を実行することができる。
CUIの場合でかつ複数のファイルを処理しているような場合1の状況から回復することができる。枯渇が発生した大容量ファイルの処理は無理でもその後の小容量ファイルは処理できる可能性がある。
次にSmalltalkによる回復処理の例を示す:
例外処理 例外のネスト
ある例外を処理中に、元のものとは別の例外が発生する場合がある。これを例外のネスト（入れ子）と呼ぶ。例外のネストの処理は例外処理の設計や実装を複雑にするため、どの範囲までネストを許すかやどのような処理に対しては例外を許さないかがしばしば問題となる。
言語仕様として実装されている例外にあっては、ネストのレベルは一般には制限されていない。この場合、同じ例外が繰り返し発生することにより無限ループに陥る恐れがある。そのような状況への対策は設計者や実装者の責任となる。
例外処理 例外のネスト
別の抽象レベルとして、OSやCPUの例外は処理や例外に備えた準備が複雑化することを防ぐため、ネストレベルに制限をかける場合が多い。典型的な例がページフォルトで、ユーザプロセスでのページフォルトは許すが、それを処理するカーネルに対してはページフォルトを許さないことにより例外処理を簡単化している。また、CPUでは例外が発生しハンドラを実行しようとした際、スタックオーバーフローに起因するページフォルトなど更なる例外が発生することがある。これはダブルフォルト（英語: Double fault）と呼ばれ、専用のハンドラやスタックなど一般的な例外よりもさらに複雑な設定や処理を要する。ダブルフォルトを処理しようとしてさらに例外が発生してしまうとトリプルフォルト（英語: Triple fault）となり、現実的な処理が困難となるためリセット処理を行う実装が多い。
荻野久作
荻野 久作（おぎの きゅうさく、1882年〈明治15年〉3月25日 - 1975年〈昭和50年〉1月1日）は産婦人科医、医学博士である。女性の月経周期と妊娠との関連性を研究した先駆的業績で知られる。
荻野久作 生涯
愛知県八名郡下川村（のち豊橋市下条（げじょう）東町）出身。父の姓は中村だが、1901年（明治34年）に西尾藩士で漢学者の荻野忍の養子となり、荻野姓となる。
旧制愛知県第四中学校（現・愛知県立時習館高等学校）、日本中学、一高などを経て1909年（明治42年）に東京帝国大学医科大学を卒業。しばらく同大病院で勤務した後、1912年（明治45年/大正元年）に新潟市の竹山病院産婦人科部長に就任するとともに新潟大学で研究を続ける。以後生涯のほとんどを新潟にて送り、1951年（昭和26年）に新潟市名誉市民の称号を受ける。
荻野久作 生涯
不妊や多産に苦しむ新潟の女性を目にし、当時解明されていなかった排卵時期の研究を行う。3年の歳月をかけ1924年（大正13年）、論文「排卵ノ時期、黄体ト子宮粘膜ノ周期的変化トノ関係、子宮粘膜ノ周期的変化ノ周期及ビ受胎胎日二就テ」を完成させ、「日本婦人科学会雑誌」19巻6号に発表した。この論文は翌年に懸賞当選論文として採用されたが、反対意見も多かった。そこで1929年（昭和4年）6月、ドイツに渡った。日本で論文を発表した6年後の1930年（昭和5年）2月22日に現地の学会誌（ドイツの『婦人科中央雑誌』（1930年（昭和5年）第22巻2号））に『排卵と受胎日』というタイトルで発表された。その後、日本婦人科学会雑誌第19巻6号に掲載された。なお学位は1923年（大正12年）東京帝国大学より「人類黄体の研究」より得ている。
ところが、オーストリア人のヘルマン・クナウス（Hermann Knaus）が久作の手法の目的を逆転させて避妊法として使うことを提唱する。これは当時から避妊法としては他の手段と比べて非常に不確実な手法であることが分かっていたので、久作は反対意見を表明する。しかし不本意にもこの避妊法は後にオギノ式と呼ばれるようになる。もっと確実な避妊法があるにもかかわらず自身の学説を安易な避妊法として使い、結果として望まない妊娠をして人工妊娠中絶により失われる命のあることに久作は憤りを感じていた。そして、むしろ不妊治療に役立てて欲しいと主張した。この2人はノーベル賞候補に挙がっていたというオーストリアのグラーツ大学Tscherne教授の証言がある。1970年（昭和45年）のクナウス教授の葬式の直後、「KnausとOginoはノーベル賞候補に上がって（原文ママ）いたのに、（Knaus教授が）死んでしまったのでその可能性がなくなった」と嘆いていた。
1975年（昭和50年）新潟市の自宅にて死去。最晩年まで医師として現役を貫いた。
新潟市の自宅跡には賞賛を讃えて「オギノ公園」が設置。
さらに、新潟市の自宅跡地前の通りは、「オギノ通り」と名づけられている。
アウトバーン
アウトバーン（ドイツ語: Autobahn）は、ドイツ・オーストリア・スイスの自動車高速道路。
本項では、特に記述のない限り、主にドイツのアウトバーンについて記述する。速度無制限道路として有名であるが、無制限区域は全区域ではなく、制限のある区域も存在する（後述）。
「アウトバーン」を逐語訳すると「自動車の走る道」である。「アウト」は（英語の「オート」に相当する）自動車を意味し、「バーン」は人や馬も歩くような道ではない「専用路」といったニュアンスを持つ。
ドイツの道路交通法 (StVO) では、日本の高速自動車国道に相当し、日本の自動車専用道路に相当するのは、クラフトファールシュトラーセ(Kraftfahrstraße) である。通称としてシュネルシュトラーセ(Schnellstraße) とも呼ばれ、こちらは「高速」の語感に近い。法定最高速度はなく、推奨速度は130 km/hが表示されているが、混雑区間や合流分岐付近あるいは急坂区間には制限速度が設定され、概ね100 km/hから130 km/hである。路線番号は東西方向が偶数、南北方向が奇数に割り振られている。ドイツの法定最高速度ルールはいたって簡単で、アウトバーン以外では街の始まりを示す標識から終わりを示す標識の間の市街地は50 km/h、住宅街・学校近辺には30 km/h規制標識も点在し、それ以外は100 km/hである。
アウトバーン
総延長は、およそ13,000 km、連邦道路（Bundesstraße）はおよそ40,000 km。両者を合わせて連邦遠距離道路（Bundesfernstraße）と呼ぶ。
スイス、フランス、オーストリア、オランダ、チェコ、スロバキア、デンマーク、ポーランドなど隣り合う各国の高速道路と密接に接続されている。オーストリア、スイス、チェコ、スロバキアではヴィネット（ビネット、ビニエット）と呼ばれる通行料金の支払いを示したステッカーシールをフロントガラスに貼る。ヴィネットは国境のサービスエリアや当該国のガソリンスタンドで購入できる。ヴィネットを貼っていない場合は通行料金と罰金を警察に徴収される。フランスの高速道路・オートルートやイタリアの高速道路・アウトストラーダは有料となっている区間が多く、国境を越えると本線上に料金所が現れる。オランダ、ベルギー、ルクセンブルクの高速道路は無料であるため、国境を示すEUの標識があるのみである。デンマークの高速道路は無料だが海底トンネルは有料である。
アウトバーン 歴史
アウトバーンのような自動車専用道路の構想はドイツ帝国時代やヴァイマル共和政時代にも行われていた。1913年から1921年にはベルリン郊外にアヴス (Automobil-Verkehrs- und Übungsstraße) と呼ばれる専用道路が作成され、1928年から1932年には、ハフラバ（ドイツ語: HaFraBa）（ハンザ同盟都市＝フランクフルト＝バーゼル間自動車高速道路建設協会）によってケルン＝ボン間の道路が完成した。「アウトバーン」の名称は1929年にこの団体が作成したものである。しかしアヴスは9 km、ケルン＝ボン間は35 kmにすぎなかった。これは当時の自動車の普及度がかんばしくなかったこと、当時の政治家が鉄道網や既存の道路網拡張で十分であると考えていたことが原因であった。
アウトバーン着工や病院建設などの公共事業は経済政策の一環であった。1929年に起こった世界恐慌の影響を受け、ドイツの深刻な不況で少なくとも600万人が失業に苦しむ中、1932年から1933年での選挙キャンペーンで、ナチ党のアドルフ・ヒトラーは国民に職とパンを与えることを約束した。ヒトラーの目的は
アウトバーン 歴史
であり、その経済政策の責任者はドイツ帝国銀行総裁のヒャルマル・シャハトであった。失業救済法の実施に伴って国家労働奉仕団（Reichsarbeitsdienst, RAD) を設立し、1935年以降は18から25歳までの全てのドイツ男子に対し、軍事訓練や労働研修、植林、畑仕事など、6か月間の各種労働奉仕活動を義務付けた。1936年にはヘルマン・ゲーリングが総裁となり、4年計画を打ち出した。
アウトバーン 歴史
1933年、首相となったヒトラーは、「休日には低所得者層が自動車に乗ってピクニックに出られる」暮らしが必要であると唱え、2月11日に国際自動車オートバイショー (Internationale Automobil- und Motorradausstellung) の会場でモータリゼーションと自動車道路網の構築を約束した。この後にハフラバの会長ヴィリー・ホーフが「ヨーロッパ横断道路計画」を、ザーガー・ヴェルナー社のフリッツ・トートが「ミュンヘン＝キーム湖間」の道路計画を提出した。ホーフの計画はヴァイマル時代にすでに提出されていたが、4月6日にホーフと会談したヒトラーはその計画をドイツ全体を覆う高速道路計画とするべきとし、計画の練り直しを命じた。5月1日に行われた「国民労働記念日」の式典で、ヒトラーは全長7,000 kmにおよぶ「帝国アウトバーン」(Reichsautobahnen) の計画を発表し、6月27日には「帝国アウトバーン会社の設立に関する法律」(Gesetz über die Errichtung eines Unternehmens „Reichsautobahnen“) が発布された。6月30日にはドイツ国有鉄道の子会社として帝国アウトバーン会社 (de:Reichsautobahn) が設立され、トートが「ドイツ道路総監」(Generalinspektor für das deutsche Straßenwesen) に就任した。トートは一介の技術者であったが、ヒトラーに提出した設計図が気に入られ、この後も要職につくことになる。9月23日にはヒトラー臨席の鍬入れ式が行われ、アウトバーン建設が始まった。11月30日には道路総監が総統直属の最高官庁であると定められた。
アウトバーン 歴史
この工事の特徴として、あえて機械化比率を抑制し人力施工部分を多くすることで、雇用を創出して失業対策効果を狙った点が挙げられる。現場では使用を避けられない場合に限って重機の使用が許されたが、そのような場合も、まずは建設総監であるトートの承認を得なければならなかった。この人力施行方針の結果、現場では極めて過酷な肉体労働環境が生じることとなった。負傷や病気による労働者の欠勤が発生し、労働者の間で不満が高まった。現場によっては労働者たちがストライキを起こす事態に発展した。
1936年から1937年にかけてのドイツ経済の着実な改善に伴い、過酷なアウトバーン建設よりも良い労働条件と高い賃金を提供する他の産業部門へ、多くの労働者が流出した。この状況を打開するため、総監トートは捕虜や民間人囚人を、建設事業の労働者として大量に投入することを要求した。帝国労働省（Reichsarbeitsministerium）と外務省（Auswärtiges Amt）はこれを承認し、直ちに許可した。建設に参加した労働者は1933年末には1,000人以下であったが、1937年には10万1,000人、1938年には12万人に達した。この他に、アウトバーンと連結する国道と地方道改良のために、直接間接に10万人が雇用された。
アウトバーン 歴史
第二次世界大戦の開戦までに3,860 kmが完成していたが、量産直前まで至っていた「国民車」フォルクスワーゲンの構想は開戦によって頓挫してしまい、一般国民の私有するフォルクスワーゲンが走ることは一度もなかった。1943年8月には自転車の乗り入れが許可された。大戦中は連合軍の空襲を避けるためにトンネルや近くの森の中に航空機を隠し、滑走路代わりとして利用した。連合国による激しい爆撃によって多くの部分が破壊されたが、戦後西ドイツ地域の区間は早急に修復が行われた。
1950年代に西ドイツ政府は構築プログラムを再開し、新区間の建設および既存区間の改良に多額の投資を行って、隣接各国とも連携した高速道路ネットワーク構築を推進した。
一方で、東ドイツおよびポーランド区間は各政府の経済的な問題で修復が進まなかった。1980年代には西ドイツ国内ですべての世帯から10 km以内のアクセスを提供する計画が進められていたが、ドイツ再統一後には予算を東側にシフトし建設が行われた。
アウトバーン 制限速度
速度無制限区間といわれる区間と速度制限区間がある。速度無制限区間といっても、乗用車においてはトレーラーやキャンピングトレーラーなどを牽引している車両には制限速度が設定されており、その制限速度以上で走ることができない。大型トラックは80 km/h、バスは条件にもよるが多くの場合100 km/hが制限速度になっている。日本と同様に速度違反自動取締装置（カメラ）が設置されているところもある。速度無制限区間における推奨巡航速度は130 km/hとされている。
近年は速度制限区間が多くなっており、連邦道路研究所の2017年の報告書によると、2015年のアウトバーン路線の70.4%は推奨速度のみが存在し、6.2%は天候や交通状況による一時的な速度制限が行われており、23.4%は恒久的な速度制限があると報告されている。ブランデンブルク州の2006年の測定では、アウトバーンの6車線区間の自由流時の平均速度は142 km/hであった。速度無制限区間であっても、路面の荒れが激しいことや交通量の増大に伴い混雑が激しいこと、すぐに速度制限区間に到達してしまうことなどから、近年の幹線道路においては、交通量の少ない地方の路線を除いて、300 km/hを超えるような超高速走行は難しくなっている。2008年にはブレーメン市が120 km/hの制限速度を導入。市内全域で制限を行う自治体は初めてであった。
アウトバーン 料金
無料を前提として設計されており、料金徴収所を設置することが困難なため、有料化は見送られ、自動車燃料や自動車保有への税金で建設と維持が行われていた。しかし、東西冷戦の終結やEUによるヨーロッパ経済の統合により、ヨーロッパの中間に位置する東西交通の要として重要な存在であり、各国からの交通量の増加に加え、周辺の環境対策や道路の整備維持など莫大な費用がかさんでおり、これらをドイツにおける税収で賄うことは適当でないとして、外国からの利用が多い大型トラックを対象に、有料化が図られている。その他の車種については賛否両論があり、当面は無料が継続されると思われる。
こうして、1995年1月より、12トン以上の大型トラックについて有料となった。当初は利用券（ヴィネット）方式であったが、2005年1月から距離課金方式に変更された。本線上にETC受信装置を設置し、80 km/hで走行しているトラックの車上装置と赤外線で通信を行い、GPSによって通った路線料金を計算して納めるシステムである。本線受信装置からホストコンピュータへはドイツテレコムの携帯電話通信網が使われる。ゲートを高速で通過するため当初は誤作動が多く、システムを請け負ったシーメンス社は違約金をドイツ政府に支払った。
アウトバーン 料金
国外業者のトラックに対しては車上装置設置の義務がないため、車上装置を持たない国外業者は、通るルートの通行券をサービスエリアに備えられたチケットマシンで購入するシステムになっている。
2014年7月7日に外国人ドライバーより料金を徴収する方針が示され、2016年にも始まる予定であった。欧州委員会より外国人差別の疑いがあるとして有料化方針に対する批判を受けたこともあり、2015年に有料化導入はいったん延期された。
アウトバーン 設備・設計
高速走行に適したように設計されており、勾配は原則的に4 %以内に抑えられている。また、建設時に航空機の発着を想定したため、舗装の厚みが平均75 cmとアメリカの高速道路に比べて約2倍と厚くなっている（高速道路に掛ける予算もアメリカの約2倍）。
サービスエリアやパーキングエリアなどの施設が整備されており、レストラン・スナック・売店・トイレ・簡易宿泊施設・ガソリンスタンド・駐車場が合体したラストホーフと、給油だけのタンクシュテレ、トイレが設置された駐車場（PとWCの表示）、トイレなしの駐車場のみの施設（Pだけの表示）などと機能別に分かれている。
アウトバーン その他
戦前から戦後にかけての日本における弾丸道路計画は、アウトバーンに刺激されたものであるといわれる。
アウトバーン アウトバーンをテーマにした作品
『アウトバーンコップ』 (Alarm für Cobra 11 - Die Autobahnpolizei) 
1996年3月から、RTLテレビが放映しているドイツのテレビドラマ。その名の通り、アウトバーンを舞台に、ドイツ警察高速警察隊の活躍を描く。爆破・銃撃戦・カーチェイスと、多重事故など派手なアクションシーンが展開される。このドラマの撮影のために、一部の路線で通行止めが行われたりする。
日本でも、日活がビデオ・DVD化。他のシリーズも他社からビデオ、DVDが発売されている。
2008年4月4日から、プライムウェーブが『アラーム・フォー・コブラ11』というタイトルでDVDリリースしている。
キク目
キク目（キクもく、学名: Asterales）は、双子葉植物の目の一つ。11科に約1,700属27,000種が属する。属種のほとんどは、ヒマワリやデイジーなどが属するキク科で占められている。被子植物の中で進化の進んだグループであり、大きな目となっている。
キク目 過去の分類体系
クロンキスト体系ではキク科のみを含む単型目である。
エングラーと共同研究者らはキク科をキキョウ科に近縁と考えて、キキョウ目に所属させた。そのため、新エングラー体系ではキク目の名前は使われていない。キク科をキキョウ科の間に系統関係を認めている点では、APGと同じである。
ポインタ (プログラミング)
ポインタあるいはポインター(pointer)は、
コンピュータで処理するデータやプログラムの場所を記憶して指示するレジスタや変数の分類や呼称

。
ポインタ (プログラミング) 概要
コンピュータは処理対象のデータと処理内容であるプログラムとを、一定の規則で記憶装置に並べて処理を行う。
記憶装置の特定の場所を指示するため、(現在のコンピュータの多くは)連続した整数のアドレス(Address)、番地を1バイト単位で割当てている。またプロセッサの内部にもレジスタと呼ばれる記憶場所を、数個から数10個程度配置している。レジスタや記憶装置の中身は全て有限桁ビット列のデジタル数値であるが、特にアドレス指定のための数値を記憶するレジスタや、記憶装置での特定アドレス(高水準言語での特定変数)を、ポインタと呼んで区別している

。
ポインタ (プログラミング) 命令セットでのポインタ
プログラムはInstructionとも呼ばれるコンピュータやプロセッサに対応した命令を処理順序に従って並べることで実現されている。
並べた命令を自動的に実行するために、プログラムカウンタ、Program Counter(PC)とも呼ばれるレジスタが用いられる。
プログラムカウンタは、現在実行中(あるいは次に実行予定の)命令のアドレスを記憶していて、次の命令に遷移する際に自動的に命令サイズ分だけ加算される。
プログラムには、条件分岐やループといった処理も必要になる。
これらはジャンプ等の命令を実行することで、間接的にプログラムカウンタの値をジャンプ先のアドレスに書換えることで実施される。プログラムカウンタは命令ポインタ、Instruction Pointer(IP)と呼ぶ場合もあり、場所を指示するポインタの1つである。
ポインタ (プログラミング) 命令セットでのポインタ
高級言語が利用されプログラムが大規模で複雑になると、プログラムを分割して作成管理利用するようになる。
分割されたプログラムは、言語によってサブルーチン(Subroutine)やプロシージャ(Procedure)、関数(Function)やメソッド(Method)などと呼ばれる。
これらの実現には、引数の受渡し、戻り値の受渡し、呼出し先へのジャンプ、呼出し元へのジャンプなどが必要になるが、多くの場合スタックと呼ばれるLIFO(Last In, First Out)のデータ構造を利用して実現している。スタック先頭を示すレジスタが用意される場合もあり、Stack Pointer(SP)などと呼ばれ、これもポインタの1つである
。
ポインタ (プログラミング) データ構造でのポインタ
コンピュータで扱うデータ形式は有限桁の整数か浮動小数点数を基本とし、それらを規格や処理内容に従い、適切にエンコード（符号化）して記憶装置に配置する必要がある。
多く用いられるソート整列や探索、文字列処理や数値計算などは、コンピュータの命令セットやプログラミング言語の種類に依存しない、一般化された解法アルゴリズムとして類型化されている。
また各種アルゴリズムに適したデータ構造も類型化されている
。
例えば学生のデータを作成し処理する場合、学生毎に記憶する内容は氏名や住所や生年月日、各授業の出欠状況や試験結果など多岐にわたる。
こうした学生1人分のデータは、構造体やクラスを用いて実現される。
複数の学生データの全体について、氏名の辞書順やある試験結果の順に並べるソート処理や、ある年に生まれた学生や及第点の学生の存在有無を調べる探索処理、転入した学生の追加処理などを考慮してデータ構造が設計採用される。
データ構造の類型として、配列や構造体に加えて連結リストが挙げられる。
連結リストは、学生の氏名や住所などデータそのものに加えて、別の学生への連結(リンク)を1つ以上持つデータ構造であり、データの追加削除や整列に適している

。
ポインタ (プログラミング) データ構造でのポインタ
連結リストは、LISPやJavaやC++では言語仕様やクラスライブラリで用意されている。一方でC言語ではポインタをメンバーとする構造体として、利用者が設計し実現する必要がある。
連結リストにより制限をかけた利用方法が後入先出のスタックと先入先出のキューである。
また上下(親子)関係を明確にしたものが木構造である。
グラフ構造は連結リストをより一般化したものである


。
下記は前後用にリンクを2つ持つリストのための、構造体の例である。
『プログラミング言語C』では上記のような構造体を、自己参照的構造体として紹介し、木構造が具体例で用いられている



。
ポインタ (プログラミング) C言語のポインタ
最も典型的なポインタの例としては、C言語におけるポインタが挙げられる。C言語のポインタは「特定のメモリ領域を指し示す」ものである。ポインタを経由してメモリ上のデータにアクセスする際、参照するデータの型に応じたポインタ型を用いる。たとえば、int型のデータにアクセスする場合は、int*型を用いる。int*型を持つ変数を「intへのポインタ」(pointer to int) と呼ぶ。
C言語にポインタが存在する理由は、効率上の問題である。C言語は、元々UNIXを記述するシステム用言語として開発されたものである。したがって、アセンブリ言語で実行できる操作のほぼ全てを行える必要があった。そのため、特定のメモリ領域への値の直接代入能力を持つなど、他のプログラミング言語と比較すると異色とも言える強力なポインタ機能を備えている。
C言語の実行モデルでは、実行プログラム上の関数コード、データが全て1次元のアドレスに直列配置される。そのため、データはおろか、関数のアドレスを取得し、他の関数にエントリーポイント情報として渡すこともできる。
ポインタ (プログラミング) C言語のポインタ
また、C言語の関数では、引数は、値渡しだけをサポートし、参照渡しをサポートしない。これは、アドレスの数値を取得すれば、参照に可能な全てを行えるため、実質的に参照を数値と同一視できるからである。実際、初期のC言語では、アドレス値は、整数型互換するものとして扱われていた。これは、値と参照を明確に区別するPascalなどとは対照的である。現在でもC言語は、void*により任意のメモリ領域にアクセスできる。なお後発のC++では参照渡しもサポートするようになった。
しかし、コード領域も含むメモリを直接扱えるということは、言語レベルでは（意図的でないとしても）不正なメモリアクセスを事実上保護できないということを示しており、C言語のプログラムにおけるポインタ関連のバグの多さがそれを証明している。
一般的なC言語のソースコードでは、ポインタが指している領域の値を参照する間接演算子 (indirection operator) "*"と、アドレス演算子 (address operator) "&"を用いて記述される。未初期化のポインタ変数は、不定の領域を指している。しかし、その場合、「未初期化状態」と「有効な領域を指している状態」の区別がつかない。そのため、Null(ヌル)値を代入することによって、ポインタが無効な領域を指していることを明示する必要がある。
ポインタ (プログラミング) C言語のポインタ
アスタリスク*前後のスペースの有無は任意である。
上記の2つの変数nとptrは、以下のようにまとめて宣言することもできるが、混乱を招く恐れがある。
複数のポインタ変数をまとめて宣言する場合は、以下のように書く必要がある。
C言語の処理系では通例、無効なポインタを示す値として下記のようなNULLマクロが定義されている。
C言語では、voidへのポインタは任意の型へのポインタに自由に代入することができる。ポインタに無効値を代入する場合、通例このNULLマクロを使う。
一方、C++では、NULLは整数定数のゼロに等しい。
そのため、C++では下記のように書くこともできる。
C++ではNULLが整数定数のゼロに等しいことから起こる関数オーバーロードのルックアップに関する問題を解決するため、C++11以降では、std::nullptr_t型として評価されるキーワードnullptrが定義された。C++11以降でもNULLは引き続き利用可能だが、整数定数のゼロに等しいとは限らず、実装は処理系依存となる。
下記はポインタptrの参照先である変数nに整数値10を代入することになる。
C言語における配列（固定長配列）とポインタはそれぞれ異なるデータ型であるが、配列の添え字演算子は、ポインタの加減算とデリファレンスの糖衣構文である。
ポインタ (プログラミング) C言語のポインタ
実行時に要素数の決まる配列を作成する際など、動的にメモリ領域を確保するときは結果をポインタで受け取る。確保したメモリを解放するときもポインタを利用する。メモリ解放直後のポインタは無効な領域を指しており、これを「ダングリングポインタ」(dangling pointer) と呼ぶ。ダングリングポインタが指している領域を誤って使用することのないように、セキュリティ対策として明示的にNULLを代入しておく手法が推奨されている。
C言語の関数は前述のように参照渡しをサポートせず、値渡しのみをサポートするため、出力は戻り値（返り値）による1つのみを持つことしかできないが、ポインタを利用することで疑似的に複数の出力を持つ関数を定義することが可能となる。
下記は標準入力を整数値に変換し、scanf関数の第2引数の参照先であるnにその整数値を出力する例である。scanf関数は書式文字列に応じて、可変長引数に渡された実引数の型が何であるかを判断する。例えば%d書式はintへのポインタが渡されたとみなす。
または
「ポインタへのポインタ」（多重間接参照、ダブルポインタ）を定義することも可能である。動的に確保したメモリへのポインタを関数引数で返却するときや、ポインタ配列を扱うときなどに利用される。
ポインタ (プログラミング) C言語のポインタ
ポインタ配列先頭要素へのポインタargvを操作して、それぞれの要素が指すゼロ終端文字列（char*）を標準出力に書き出している。しかし、間接演算子"*"とインクリメント演算子"++"のどちらの優先度が高いのかを知らないと、このような記述を理解することはできない。したがって、保守作業の際にバグを誘発しやすいため、以下のように記述したほうがよいとする主張もある。
上述の通り、C言語では関数を指すポインタ (pointer to function / function pointer) を作成することができる。
記憶域 (メモリ) のアドレス空間は、1次元空間である。たとえば32ビットシステムのアドレス空間は、16進数表記で 0x00000000 から 0xFFFFFFFF (4GiB-1) までの整数値が有効な範囲である。ポインタはこのアドレス空間を抽象化し、メモリ上の任意位置のデータ（オブジェクト）にアクセスするためのデータ型である。なお、プロセスのアドレス空間は物理メモリ上のアドレス（物理アドレス）に直接対応するとは限らない。通例、オペレーティングシステムによって物理メモリは抽象化され、プロセスごとに仮想アドレス空間が割り当てられ、プロセスごとの仮想アドレス空間におけるメモリの読み書き処理はOSによって物理アドレスに対する処理に変換される（メモリマッピング）。
ポインタ (プログラミング) C言語のポインタ
ポインタに対する算術演算は、加減算のみが許可される。ポインタに加減算すると、そのポインタが指すデータ型のサイズに比例したオフセットがアドレスに加減算されることになる。これは配列の添え字演算子が、ポインタの加減算とデリファレンスの糖衣構文であることからも自明である。つまり、ある型Tへのポインタの加減算は、メモリ全体をTの配列とみなして、インデックスを増減していることに他ならない。
バイト単位のアドレッシングが必要な場合、char / signed char / unsigned charへのポインタを利用する。これらの型はサイズが1であることが規格で保証されているため、これらの型へのポインタに対する加減算操作はバイト単位のアドレッシングとなる。
なお、汎用ポインタvoid*は型が不明のため、アドレスの加減算を行なうことができないが、GCC拡張の非標準動作ではvoid型のサイズに1を割り当てるため、加減算が可能となっている。
ポインタ型のサイズは処理系依存であり、通例ターゲットとするプロセッサアーキテクチャのレジスタ幅と同じサイズを持つ。
オフセット計算などでポインタ間の差を得る必要がある場合、<stddef.h>で定義されているptrdiff_t型を用いる。ポインタ（アドレス値）を整数型に代入する必要がある場合、<stdint.h>で定義されているポインタ互換の整数型intptr_tやuintptr_tを用いる（C99およびC++11で標準化されている）。なお、C/C++ではintやlongなどの組み込み整数型のサイズもまた処理系依存である。移植性を損なうため、ポインタを扱う目的で組み込み整数型を直接使用してはならない。
ポインタ (プログラミング) 問題点
ポインタには不正な領域を示しうるという問題がある。たとえば、近年セキュリティ上で問題となっているバッファオーバーランの原因の多くは、ポインタ演算のエラーで起こる不正領域の書き換えによるものである。また、「オブジェクトそのものに対する操作」と「オブジェクトの位置に対する操作」が混在することは、プログラマの混乱を招きやすい。このような問題もあって、JavaやC#など、C言語よりも新しい後発のプログラミング言語では、言語レベルでのポインタ機能は、排除されるか制限される方向にある。
しかし、プログラマーに直接ポインタ操作を許可していない言語でも、ポインタ概念は存在する。たとえば、配列中にオブジェクトを格納し、それを要素のインデックスで参照すれば、これは「ポインタ概念」を活用していることになる。したがって、配列の要素数を超えた領域をアクセスすれば、エラーが発生する。しかし、配列へのインデックスアクセスを完全に排除してしまうと、その言語の制限が厳しくなり、単純な動作を簡易に記述できる領域を狭めてしまう（言語の表現力が低下する）。このように、ポインタには危険性があるが、プログラミングをするうえでは、非常に強力なテクニックである。また、C言語でマイコンの周辺デバイスを制御する場合、メモリバス上の特定のアドレスにあるレジスタに値を読み書きする必要があるため、必須のテクニックとなる。
ポインタ (プログラミング) 問題点
一方、関数型言語などの発展により、ポインタの必要性は、今後減少する可能性が考えられる。また、データベース領域では、SQLのように関係式からデータを導き出し情報の位置を抽象化する概念が古くからあり、こちらもプログラミングパラダイムに影響を与えることが考えられる。
ポインタ (プログラミング) 参照
C++における参照は、ポインタと同様「変数がメモリ上に置かれている場所」と解される場合もあるが、それよりもむしろ「その変数を参照する（＝変数の値を操作したり出来る）権限」と解されることが多い。参照の概念そのものはメモリの概念と切り離して考えることが可能である（実装上はポインタと同じであることも多い）。
この場合変数n2はnを参照している。n2とnはオブジェクトを共有しているのでn2と呼んでもnと呼んでも同じものを表す。すなわち変数nにエイリアス（別名）n2が付いたことになる。
ポインタは未初期化の状態や、何も参照していない状態（ヌルポインタ）が許可されるが、C++における参照は必ず初期化が必要となり、何も参照していない状態は許可されない。ただし、ダングリングポインタと同様、破棄された領域への参照は不正となる。
ポインタ (プログラミング) ダングリングポインタ
ダングリングポインタ（英: dangling pointer）は解放後のメモリ領域を参照するポインタである。
メモリ領域は変数のために確保され利用後に解放される。ゆえにその領域が正しい意味を持つのは確保から解放までの間のみであり、解放後にその領域へアクセスすること (Use-After-Free) は未定義の動作を引き起こす。ダングリングポインタは解放後のメモリ領域を参照しているため、このポインタの利用は Use-After-Free であり予測できない結果を生み出してしまう。
防止策が無い場合、ダングリングポインタは容易に生成されうる。例えば、参照を生成し元の変数を free するだけで参照先が解放された状態になってしまう（参照先と参照での生存期間ズレ）。可変長配列のスライス参照ではより複雑で、配列へのpushに伴うメモリ再割り当てで変数の生存期間中なのに最初の領域が解放されるケースがある。
このためダングリングポインタはバグの大きな原因であり、それを悪用したハッキングにしばしば利用される。これを事前に防ぐためにモダンなプログラミング言語では言語仕様レベルでのダングリングポインタ防止策が取り入れられている（例: Rust の借用チェッカー）。
ポインタ (プログラミング) スマートポインタ
動的確保したメモリのアドレスをポインタにより管理するとき、注意深くプログラミングしないと解放忘れやダングリングポインタといった問題が発生しやすい。C++ではポインタをクラスでラップし、デストラクタの機構を利用して解放処理を自動化した「スマートポインタ」が利用されることが多い。またオブジェクトの所有権の移動や共有といった、生のポインタでは扱いが難しい概念をスマートポインタの機能として簡潔に実現するライブラリも存在する。
フライ・フィッシング
フライ・フィッシング（英: Fly fishing）とは、欧米式の毛針であるフライを使う釣りである。起源はイギリスの貴族で、現在も格調高い紳士のスポーツとして楽しまれている。
日本では1902年（明治35年）、栃木県日光市の湯川と湯ノ湖に、英国商人トーマス・グラバーがカワマスを放流して楽しんだことが始まりとされる。このため、この一帯は「日本のフライフィッシングの聖地」と称される。
日本の伝統的な毛針を使った釣りであるテンカラ釣りがこれと大きく異なる点は、リールを使用しないことと毛針による誘い方の違いである。
フライ・フィッシング 概要
フライ・フィッシングの要素を大きく4つに分けると次のようになる。
キャスティング
フライは非常に軽量である。フライフィッシングでは錘（オモリ）は使わず、釣り糸（ライン）自体の重さによってフライを投入するため、キャスティングを習得することから始まる。これは他の疑似餌を使う釣り、ルアーフィッシングなどではその重量によって遠方まで投入できるのと大きく異なる。ラインを前後に振り、勢いと方向性を付け投げる「オーバーヘッドキャスト」、頭上後方までゆっくりロッドを立てた後前に振り、水面をラインが転がるようにして投げる「ロールキャスト」、ラインの一部を水面に触れさせた状態で後方にループを形成し投げる「スペイキャスト」など、方法は多岐にわたる。原理的には革紐や鎖などの鞭（むち）を振りかざす動作を似せて、フライを目的とするポイントへ投入し、フライを手元で匠に動作させる。引き寄せる際にはリトリーブという。
ファイト
ヒットした魚を釣り上げる技術のことである。他の釣りに比べると魚と釣り竿（ロッド）との間にあるのはラインのみであり、オモリや疑似餌の重量などに邪魔されず、直接的に魚とやり取りができるためエキサイティングな手応えとなる。
タイイング
魚の食べ物に似ている (imitate)フライを製作すること（詳細はフライの項を参照）。
フライ・フィッシング 概要
自然観察
フライフィッシングの哲学とも言われる。その所以は、釣りをする時期の、現地に棲む水生昆虫や小魚の種類を確認し、魚が捕食していると思われる餌に似たフライを選ばなければ釣果につながらないからである。
いずれの分野も一朝一夕で身につくものではなく、奥の深い趣味と言える。この釣法の独特の技術と趣味性から、一般的にはハードルが高いという面もある。
使用するフライに応じてドライフライ・フィッシングとウェットフライ・フィッシングの2つに大別することが出来る。
ドライフライ・フィッシング
フライを水面に浮かせる釣り方。
ウェットフライ・フィッシング
フライを水中に沈める釣り方。
ニンフフィッシング
フライを水中に沈める釣り方ではあるが、ニンフ（水生昆虫）と呼ばれるフライを使用する場合は一般にウェットフライ・フィッシングとは呼ばない。
フライ・フィッシングではサケ科の魚をターゲットにすることが多い。そのため、サケ科の魚が生息する河川や湖沼で釣りをする場合が多い。使うフライに似た水生昆虫や小魚などを捕食するサケ科以外の魚を狙ったり、それらが意図せず釣れてしまったりすることもある（後述）。最近では管理池や海でフライフィッシングを楽しむムーブメントもある。
フライ・フィッシング タックル
必須タックル（最低限必要なもの）
ロッド
リール
フライライン
リーダー（フライラインの先に付ける糸）
フライ
その他のタックル
ティペット（リーダーの先に付ける糸）
フロータント（フライやリーダー、フライラインを浮かせる塗布剤）
フィッシングベスト類（フライボックスなどを入れる上着。移動の多いフィッシングにおいては必須とも言える）
ウェーダー（胴付長靴。フライフィッシングにおいては必須とも言える）
摘要：他にも状況や釣法、対象魚によって様々なタックルが必要となる。
ロッド、リール、フライラインのサイズは○番、#○と呼ぶ。なお、呼び方は違っても意味は同じである。
ロッド、リール、フライラインのサイズは数字が大きくなればなるほど大型になる。小さいもので#0（メーカーによっては#000というものもある）、最大では#15まである（さらに大きい番手もある可能性がある）。
ただし、人によっては上記に当てはまらない場合もある。
近年では鯉やブラックバスをフライフィッシングで釣る人も多くなってきた。バス狙いのフライをバスフライと呼ぶ。
バス狙いでのタックル番数は6～8番付近が多いようである。
フライをピンポイントに遠方へ投げるため、フライラインとその重量バランスを考慮しなければならない。小麦（粒）を計量するときに使われるグレインという重量単位を使うこともある。