hpprc/jawiki-books-paragraphs huggingface dataset:
C言語/標準ライブラリ/stdint.h
ヘッダー <stdint.h> では、指定された幅を持つ整数型の集合を宣言し、それに対応するマクロの集合を定義しています。
また、他の標準ヘッダーで定義された型に対応する整数型の限界を指定するマクロも定義しています。
型は以下のカテゴリーで定義されています。
(これらの型のいくつかは同じ型を表すことがあります)
対応するマクロは、宣言された型の制限を指定し、適切な定数を構築します。
ここに記述されている各型のうち、実装が提供するものについては、<stdint.h>はそのtypedef名を宣言し、関連するマクロを定義しなければならない。
逆に、ここに記述されている型のうち、実装が提供していないものについては、<stdint.h>はそのtypedef名を宣言せず、関連するマクロを定義してはならない。
実装は、「必須("required")」と記述されている型を提供しなければならないが、「任意("optional"))」と記述されているその他の型を提供する必要はない。
機能テストマクロ __STDC_VERSION_STDINT_H__ は、 yyyymmL というトークンに展開されます。
整数型

最初のuの有無だけが異なる型名が定義されている場合、それらは§6.2.5 Types に記載されているように対応する符号付き及び符号なしの型を表すものとする。 §6.2.5 Types に記述されているように、対応する符号付きおよび符号なしの型を示す。 これらの対応する型の一方を提供する実装は、他方も提供しなければならない。
整数型

以下の記述では、記号 N は、先頭にゼロを持たない符号なしの10進整数を表す(例えば、8や24であり、04や048ではない)。
整数型

これらの型はオプションです。ただし、8、16、32、64ビットの幅を持ち、パディングビットを持たない整数型を提供する場合は、対応するtypedef名を定義しなければならない。
整数型

以下の各型は、少なくとも指定された幅を持つすべての整数型の中で、通常、最も高速に演算できる整数型を指定しています。
指定幅の整数型の幅

以下のオブジェクト型マクロは、<stdint.h>で宣言された型の幅を指定します。各マクロ 名前は#整数型と同様の型名に対応しています。
指定幅の整数型の幅

定義されたマクロの各インスタンスは、#if 前処理ディレクティブで使用するのに適した定数式で置き換えられなければならない。その実装定義値は、以下に示す値と同等以上でなければならない。 ただし、正確に指定された値であると述べられている場合を除く。実装では、実際に提供する 型名に対応するマクロのみを定義しなければならない。
整数定数用マクロ

例えば、uint_least64_tがunsigned long long int型の名前である場合、UINT64_C(0x123)は整数定数0x123ULLに展開されます。
整数型の最大値と最小値

幅を表す接尾辞_WIDTHを持つマクロが存在するすべての整数型に対して、接尾辞_MAXを持つ最大値マクロと、すべての符号型に対して接尾辞_MINを持つ最小値マクロは、以下のように定義されます。 § 5.2.4.2. Characteristics of integer types <limits.h> で定義されています。符号付きか符号なしかの指定がなく、実装上、符号なしの型となっている場合は、接尾辞_MIN の最小マクロと、対応する型の値 0 が定義される。
C言語/標準ライブラリ/stdnoreturn.h
ヘッダー <stdnoreturn.h> では1つのマクロが定義されています。
注

<stdnoreturn.h>は、C++11と組み合わせて使用することはできません。
C言語/標準ライブラリ/time.h
ヘッダー <time.h> では、いくつかのマクロが定義されており、時間を操作するための型や関数が宣言されています。
多くの関数は、(グレゴリオ暦に基づく)現在の日付と時刻を表すカレンダータイムを扱います。いくつかの関数は、特定のタイムゾーンで表現されるカレンダータイムであるローカルタイムや、ローカルタイムを決定するアルゴリズムの一時的な変更である夏時間を扱います。ローカルタイムゾーンと夏時間は実装で定義されます。
C2xでは、機能テストマクロ __STDC_VERSION_TIME_H__ は、 yyyymmL というトークンに展開されます。その他のマクロはNULLが定義されています(§7.19 Common definitions <stddef.h>に記載)。
ヘッダー <time.h> で定義されているマクロと型と、宣言されている関数。
境界チェックインターフェース

処理系が __STDC_LIB_EXT1__ を定義し、ユーザが __STDC_WANT_LIB_EXT1__ を 1 に停止した場合、以下の境界チェックインターフェースが有効になります。
境界チェックインターフェース

POSIX(IEEE Std 1003.1)では、time.hに2つの関数を追加しています。asctime_rとctime_rです。 これらはasctimeとctimeのリエントラント版( reentrant version )です。どちらの関数も、呼び出し側が、ある瞬間のテキスト表現を格納するバッファを提供することを必要とします。 以下のサンプルでは、リエントラント版のlocaltimeとasctimeの使用方法を示しています。
境界チェックインターフェース

これらの関数はC++の標準にはないので、C++の名前空間stdには属していません。
Microsoft PowerPoint/挿入
Microsoft PowerPointには挿入というものがあります。
挿入

挿入とは、スライド上に図形や画像などを追加させることである。
操作

挿入は、上の挿入タブから実行できる。
刑事訴訟法第99条の2
法学>コンメンタール>コンメンタール刑事訴訟法=コンメンタール刑事訴訟法/改訂
条文

(記録命令付差押え)
解説

2011年改正により新設。
刑事訴訟法第110条の2
法学>コンメンタール>コンメンタール刑事訴訟法=コンメンタール刑事訴訟法/改訂
条文

(電磁的記録に係る記録媒体の差押え執行方法)
解説

2011年改正により新設。
刑事訴訟法第111条の2
法学>コンメンタール>コンメンタール刑事訴訟法=コンメンタール刑事訴訟法/改訂
条文

(協力要請)
解説

2011年改正により新設。
刑事訴訟法第498条の2
法学>コンメンタール>コンメンタール刑事訴訟法=コンメンタール刑事訴訟法/改訂
条文

(不正に作られた電磁的記録等の処分)
解説

2011年改正にて新設。
刑事訴訟法第499条の2
法学>コンメンタール>コンメンタール刑事訴訟法=コンメンタール刑事訴訟法/改訂
条文

(電磁的記録に係る記録媒体の交付又は複写ができない場合の取扱い)
解説

2011年改正にて新設。
民事訴訟法第125条
法学>民事法>民事訴訟法
条文

(所有者不明土地に関する訴訟手続の中断及び受継)
条文

2021年民法改正により新設(2023年施行予定)。
条文

2004年改正まで「破産財団に関する訴訟手続の中断及び受継」について規定されていたが、同年の破産法改正により、破産法第44条に定められたため削除。空番となっていた。
民事訴訟法第3条の5
法学>民事法>民事訴訟法>コンメンタール民事訴訟法
条文

(管轄権の専属)
解説

2011年改正において新設。
民事訴訟法第3条の10
法学>民事法>民事訴訟法>コンメンタール民事訴訟法
条文

(管轄権が専属する場合の適用除外)
解説

2011年改正において新設。
近江弁/文末詞
ここでは近江弁の語尾で使われる表現(終助詞・間投助詞をひっくるめて文末詞と呼ぶことにします)を解説します。
～ほん

主に湖北と湖東で使われ、関西のほかの方言にはない「これぞ近江弁」という表現ですが、若い世代ではほとんど使われなくなっています。頻度は低いですが、「~ほんな」と言うこともあります。次の二つの用法があります。
～で

相手に呼びかけたり注意したりする際に使われる、関西全般で共通する表現です。近江弁には接続助詞の「で」(=から)もありますが、発音が少し違います。
～わ

相手に自分の考えや事情を伝える際に使われる、関西全般で共通する表現です。「です」「ます」にも付けます。
～な

共通語の「ね」に相当する、関西全般で共通する表現です。年配層では「です」「ます」にも付けます。湖東・湖北の高齢女性の丁寧な言い方として「~なーし」「~なし」もあります。湖西などでは「~のー」とも言います。
～よ

共通語の「さ」に相当する、主に湖東・甲賀・湖南で使われる表現です。特に「~けどよ」「~さかいによ」「~しよ」のように接続助詞とともによく使われます。HLと抑揚を付けて伸ばして言うこともよくあります。
～じょ

湖東・甲賀・湖南などの一部で「ぞ」を「じょ」と言うことがあります。
COBOL
メインページ > 工学 > 情報技術 > プログラミング > COBOL
COBOL(コボル)は、1959年に事務処理用に開発されたプログラミング言語です。 名前は「Common Business Oriented Language」(共通事務処理用言語)に由来します。 Fortran・Lispとともに最も古いプログラミング言語の1つですが、 それ故、多くのソフトウェア資産の蓄積があり、2022年の今日でも現役のプログラミング言語として使用されています。
COBOLの特徴

COBOLの特徴を簡単なコード例とともに示します。以下は、COBOLのいくつかの特徴を示す基本的なコードスニペットです。
簡単なCOBOLプログラム

以下は簡単なCOBOLのプログラムです。
環境構築

GnuCOBOL(旧OpenCOBOL、短期間GNU Cobolとして知られていました)は、COBOLのフリーな実装です。 GnuCOBOLは、ネイティブのCコンパイラを使用するCへのトランスコンパイラです。
環境構築

ディストリビューションにより、パッケージマネージャとパッケージ体系に違いがありますが、例えば Fedora Linux では、
環境構築

FreeBSD Ports/Packages Collection の、ports/lang/gnucobol にあるので、
環境構築

でビルドしインストールできます。 また
環境構築

でビルド済みパッケージをインストールできますが、GnuCOBOL自身のバージョンアップやportsのパッチレベルの更新で gnu-cobol-3.1.2_1の部分は変わるので、
環境構築

の様に、最初に最新のパッケージ名を確認してください。
コマンドラインでのコンパイルと実行

簡単なCOBOLプログラムのソースコードを hello.cbl という名前で保存し、コンパイルし実行してみよう。
COBOLの正書法

COBOLの正書法には、自由書式正書法と固定書式正書法の2種類があります。
COBOLの正書法

それぞれの正書法には以下のような特徴があります。
COBOLの正書法

処理系によっては、コマンドラインオプションなどで正書法の切り替えが可能な場合があるので、詳しくは使用している処理系のマニュアルを参照してください。
COBOLプログラムの構成

COBOLプログラムのトップレベルは
COBOLプログラムの構成

の4つのパートから構成され、順序もこの順序である必要があります。
COBOLプログラムの構成

IDENTIFICATION DIVISIONは、COBOLプログラムの最初のパートで、 プログラム名、作成者、作成日などのプログラム保守情報を含みます。 これらは、見出し部の段落として記述します。
COBOLプログラムの構成

ENVIRONMENT DIVISIONは、COBOLプログラムの2番目のパートで、 作成するプログラムをコンパイルして実行するコンピュータの名前、環境変数の受け渡しに関する情報、プログラムとの間で読み書きするファイルの名前と種類を定義します。
COBOLプログラムの構成

DATA DIVISIONはCOBOLプログラムの3番目のパートで、これまでのDIVISIONはCOBOLプログラムを構築するためのメタデータで、 DATA DIVISIONからが実際にプログラムを構築していくところだと言えます。 DATA DIVISIONでは、入出力ファイルの配置、データ項目(変数)、外部プログラムとのインタフェース(引数)など、プログラムで扱うすべてのデータを定義します。
COBOLプログラムの構成

PROCEDURE DIVISIONは、COBOLプログラムの最後のパートで、プログラムが実行する処理を記述します。
COBOLプログラムの構成

前3つのDIVISIONとは異なり、手続き部には定義された節や段落の様な既定の構造はありません。 節や段落は、プログラマが必要に応じて作成します。
COBOLプログラムの構成

COBOLにおいて、FortranのSubroutineやC言語の関数に相当する構文は、主に「サブルーチン」と「関数」です。以下に、それぞれの概要を説明します。
COBOLプログラムの構成

COBOLのサブルーチンと関数は、プログラムの構造を明確にし、再利用性を高めるために使われます。
COBOLの変遷

COBOL(Common Business-Oriented Language)は、ビジネスアプリケーション向けに開発されたプログラミング言語で、1959年にアメリカ国防総省の委員会が設立したCODASYL(Conference on Data Systems Languages)委員会によって設計されました。以下に、COBOLの変遷について簡単に説明します。
COBOLの変遷

これらのバージョンは、COBOLの進化を示しています。それぞれの規格で新しい機能や改善が導入され、COBOLは長い間にわたって広く利用され続けています。
ガリア戦記 第2巻/注解
『ガリア戦記 第2巻』の単語や構文を詳しく読み解く 注解編 の目次。
弁護士法第23条の2
法学>コンメンタール>コンメンタール弁護士法
条文

(報告の請求)
解説

いわゆる弁護士会照会の根拠規定である。
弁護士法第23条
法学>コンメンタール>コンメンタール弁護士法
条文

(秘密保持の権利及び義務)
条文

弁護士又は弁護士であつた者は、その職務上知り得た秘密を保持する権利を有し、義務を負う。但し、法律に別段の定めがある場合は、この限りでない。
解説

弁護士の守秘義務および秘密保持権の根拠規定である。
参照条文

弁護士職務基本規定第23条 - 弁護士の守秘義務に関する日本弁護士連合会会則上の規定。
弁護士法第77条
法学>コンメンタール>コンメンタール弁護士法
条文

(非弁護士との提携等の罪)
解説

いわゆる非弁行為および非弁提携ならびに係争権利の譲受の禁止に関する罰則規定である。
罪数論
法学>刑事法>刑法>刑法総論>罪数論
条文

第1編総則 第9章 併合罪(第45条 - 第55条)
情報技術/構造化プログラミング
概要

構造化プログラミングは、非構造化プログラミングの解毒剤として提案されたものです。 非構造化プログラミングは、構造化プログラミングが発明される数十年前から既に存在していました。
初めに、非構造化プログラミングがあった

非構造化プログラミングとは、手続き型のプログラムのことで、書かれている通りに文が順番に実行されます。しかし、このタイプのプログラミングでは、GOTO文を使用します。GOTO文は、プログラム内の任意の場所に制御を渡すことができます。 GOTO文が実行されると、GOTOの対象から順番に実行されます。このように、プログラムの仕組みを理解するためには、プログラムを実行するふりをしなければなりません。つまり、このようなプログラムの論理を理解するのは難しい場合が多いのです。プログラムコンパイラの中には、GOTOの接続先をクロスインデックス化して、ソースコードを高速にナビゲートする実用的なものもある。 しかし、いくつかのプログラミング言語では、GOTOの行き先に関連した変数を使用することが一般的であったため、自動インデックス化は実用的ではありませんでした。 構造化されたプログラミング言語の中には、多くの人が同じコンピュータのデータを人間の言語で見ることができるようにするための外国語ビューの実装方法など、同様の問題があります。
初めに、非構造化プログラミングがあった

これは、構造化プログラミングのように、プログラムがどのように動作するかを理解するために、ある種の抽象化を使用するという考えとは対照的です。
初めに、非構造化プログラミングがあった

このような理由から、ダイクストラはGOTO文を禁止すべきだと提案しました。
構造化プログラミング

構造化されたプログラミングとは、危険なGOTO文を使わないようにしたプログラミングという見方があります。これにより、混乱を招く恐れのある制御の移行を防ぐことができます。 多くの構造化プログラミング言語はGOTO文をサポートしており、構造化された方法で使用することができます。 例えば、ルーチンの最後に抜けたり、ループの最初に戻ったりするために使用します。
構造化プログラミング

別の見方をすれば、構造化プログラミングは、1つのエントリーポイントと1つのエグジットポイントのみを持つ制御構造を使用することに限定される。これらの構造のうち最も重要なものは、順接、選択(ifおよびif...else)、反復(while)です。
構造化プログラミング

また、構造化されたプログラムとは、抽象化によって容易に理解できるように書かれたプログラムであるという見方もあります。抽象化とは、細かい部分を理解しなくても、コードの全体的な目的を理解できるようにすることです。抽象化のための代表的なメカニズムは、プロシージャ(メソッド)です。しかし、上記のような単一エントリ単一出口の構造もまた抽象化に役立ちます。
構造化プログラミング

構造化されたプログラミングを可能にしたのは、高レベルの言語と関連するプログラムのパッケージであり、プログラマーでなくても理解できるソフトウェアの図解技術を用いてフローチャートを作成することができる。
発明者紹介

構造化プログラミングのアイデアを発見し、それを他のプログラマーの世界に伝えたのは、数人のコンピュータ科学者である。構造化プログラミングを最初に具現化したのはALGOL(Algorithmic Language)言語で、これはバロース B5000 MCP(OS)でシステムプログラミングに使われた最初の高級言語となりました(設計したのはBob Bartonで、後にユタ大学の教授となり、GUIウィンドウを発明した学生Alan Kayに影響を与え、Smalltalkの開発者の一人となりました)。その結果、ALGOLは最初のオブジェクト指向言語であるSimulaの基礎となりました。
発明者紹介

ALGOLは、John BackusとPeter Naurの名前をとってBNF(Backus-Naur Form)と呼ばれる言語設計形式をベースにしていました。
発明者紹介

この技術の画期的な本は、"Structured Programming"(Academic Press 1972: ISBN 978-0-12-200550-3)で、Edsger W. Dijkstraの "Notes on Structured Programming"、C.A.R. Hoareの "Notes on Data Structuring"、Ole-Johan DahlとC.A.R. Hoareの "Hierarchical Program Structures "という3つのセクションで構成されています。最後のセクションでは、Simulaとそのオブジェクト指向および並行処理機能が紹介されています。
発明者紹介

Edsgar Djikstraは「A Discipline of Programming」(Prentice Hall, 1976: ISBN 978-0132158718)という本も書いています。
発明者紹介

また、構造化プログラミングの世界では、Donald Knuthも有名です。彼は、複数巻からなる『The Art of Computer Programming』を執筆しました。
発明者紹介

その後、Ed YourdonとLarry Constantineによって『Structured Design』(ISBN 978-0138544713)という本が書かれ、多くの人がこれを構造化プログラミングとみなしていますが、そうではありません。これはグラフィカルな手法で、実際には非常に退屈なものだった。ほとんど放棄されてしまったが、UMLのような他の非形式的なアプローチの後継者がいる。ストラクチャード・デザインとストラクチャード・プログラミングで説明されている手法は全く異なるものであり、Structuredという言葉を共有しているからといって混同してはならない。
高等学校古文/古典文法入門
文語と口語

現在私たちが使っている言葉を口語(現代語)と言う。対して、明治初期まで使用されていた言葉を文語(古典語)という。高校の学習や一般社会において文語は、奈良時代から江戸時代までの言葉を指すことが多い。
文語と口語

次の文章は『竹取物語』の冒頭部分である(この文章の内容は中学校国語 古文/竹取物語を参照)。
文語と口語

この文章から、現代語と古典語の違いをまとめる。
文語と口語

「竹取の翁といふもの(が)ありけり」 「もと(が)光る」
文語と口語

「野山にまじりて」(現代語では「まじって」となる)
文語と口語

「いふ」(いう)「よろづ」(よろず)
品詞

全ての単語は3つの基準で分類される。
民事訴訟法/多数当事者訴訟
共同訴訟

訴訟は必ずしも原告1人と被告1人との一対一である必要は無い。
共同訴訟

「共同訴訟」という制度では、複数の原告または複数の被告が、ひとつの訴訟に参加する事もできる。
共同訴訟

原告の意思によって訴えの始めから併合される場合を訴えの主観的併合という。 共同訴訟の起きる要因は主に、
共同訴訟

である。
共同訴訟

なお、これに対して「訴えの客観的併合」とは共同訴訟とは異なり、「訴えの客観的併合」とは複数の請求がひとつの訴えから出てくる場合であるので、主に請求の併合に関するものである(136条)。
共同訴訟

なお、共同訴訟において、判決の内容の統一を図る必要がある場合には、そのことを「合一確定の必要がある」とも言う。 また、合一確定の必要があるかないかによって共同訴訟は「通常的共同訴訟」と「必要的共同訴訟」に分類される。
共同訴訟

以下の通常共同訴訟などは、共同訴訟における主観的併合の類型でもある。
共同訴訟

通常共同訴訟は、合一確定の必要とされていない種類の共同訴訟である。
共同訴訟

通常共同訴訟によって、証拠を共通とする事ができるので、裁判を効率化できる(共同訴訟人間の証拠共通)。 より詳細には、通常共同訴訟人では、共同訴訟人の1人がした訴訟行為は、その行為が同陣営の他の共同訴訟人の利益になる場合に限り、同陣営の他の共同訴訟人にも効力が生じる(40条1項)。
共同訴訟

また、共同訴訟は併合して審理されるので、たとえば審理は同一期日になる。
共同訴訟

しかし、共同訴訟人の一人に対して生じた事項は、他の共同訴訟人には影響を及ぼさず(39条)、これを「共同訴訟人独立の原則」という。具体的には、この独立の原則により、共同訴訟人の各人はそれぞれ独立に、請求の放棄、和解、訴えの取り下げをできる。
共同訴訟

以下3つの要件のいずれかを満たせば、通常共同訴訟が可能である。 (1) 訴訟の目的である権利または義務が数人について共通であるとき(38条前段)、
共同訴訟

(2) 訴訟の目的である権利または義務が同一の事実上および法律上の原因にもとづくとき(38条前段)、
共同訴訟

(3) 訴訟の目的である権利または義務が同種であって、事実上および法律上の同種の原因に基づくとき(38条後段)、
共同訴訟

必要的共同訴訟は法律上、訴訟の目的の合一確定が要請されている(民訴40 I)。では合一確定とは何かが問題になるが、通説では、判決を共同訴訟人の個々人に別々に出す事が許されずに判決をひとつにまとめる事だと解されている。
共同訴訟

固有必要的共同訴訟とは、全員が共同で訴える、または共同で訴えられなければ不適法になるという訴訟であり、次のような類型がある。
共同訴訟

(1)他人間の権利関係の変動を生じさせる訴訟
共同訴訟

(2)数人共同の管理処分権を行使すべき訴訟
共同訴訟

(3)法律上、数人が共同で管理・共有すべき財産に関する訴訟
共同訴訟

もし団体の構成員たちが固有必要的共同訴訟をしようとする場合に、構成員のひとりでも反対すると、条文などをそのまま解釈すれば訴訟できなくなる。だが実際は、団体構成員の中にいる反対者を被告に加えるという方法により、とりあえず反対者も法廷での訴訟に関与させるという形式により、要件から反対者が無しという条件を除外しているのが判例である(最判平成20・7・17民集62巻7号1994頁<百選97>)。
共同訴訟

類似必要的共同訴訟とは、実体法上は共同で訴える事は要請されていないが、共同訴訟をした以上、合一確定を要請されるべきという訴訟である。
訴訟参加

たとえば債務請求訴訟において、その債務の保証人は、その訴訟に当事者の補助として参加できる。
訴訟参加

決して誰でも参加できるわではなく、例にあげた保証人のように、訴訟内容と深い関係をもつ人物でないとならない(42条)。
訴訟参加

単に友人や家族といった程度では、裁判所は補助参加人としての参加を認めない可能性が比較的に高いだろう。
訴訟参加

補助参加人は、自らの固有の請求をもたない。従って、補助参加人は、当事者ではなく、また判決の名宛人にもならない。
訴訟参加

補助参加人には、独立的な地位が与えられており、その結果、期日の呼出しや書類の送達なども被参加人とは別に行われる。
訴訟参加

しかし、補助参加人の役割はあくまで補助であるので、まず、
訴訟参加

たとえば、建物明渡し訴訟で、原告と被告とが所有権を争っているときに、第三者がその建物の所有権は自分にあると主張するとき、この第三者は原告被告どちらの陣営にも属すべきではない。
訴訟参加

このように、第三者の主張が、もとの訴訟の原告・被告のいずれの主張とも対立するとき、もとの訴訟が係属中なら、第三者に独立の当事者としての参加できる。このような仕組みを、独立当事者参加という。
訴訟参加

この場合、もとの訴訟の原告をA、もとの被告をB、第三者をCとすれば、訴訟は、A対B、B対C、C対Aという三面的な構造になる。
訴訟参加

独立当事者参加人が訴訟に参加するための手続としては、条文的には、もとの訴訟の原告および被告に、それぞれ訴状を送って訴えを提起しなければならないとされる(47条3項)。
訴訟参加

だが実際には、独立当事者参加人がもとの訴訟の原告または被告の片方と利害が一致していて争いのない場合もあり、このような場合、争いのある残り片方だけに訴状を送れば良いと許容するのが現行法の規定である(47条1項)。(旧法では議論になっており許容説が有力説であった。)
民事訴訟法/訴えの提起
訴えの提起

訴えの提起は、裁判所に訴状を提出して行うのが原則である(133条1項)。
訴えの提起

訴訟を起こすと、その時点で時効の進行は止まる(民147上1項1号)。
訴えの提起

地方裁判所以上の訴訟代理人は原則として弁護士でなければならないが(54条)、しかし例外がいくつかある。
訴えの提起

例外的に、船舶における船長(商713条1項)、または企業における支配人(商21条1項、会社11条1項)は、代理人になる事が認められている。船長など、これらの法令による訴訟代理人は、弁護士である必要は無い(54条1項)。
訴えの提起

日本の民事訴訟では、代理人を選任せずとも、当事者本人が自ら訴訟をする事もできる。これを本人訴訟という。しかし、本人が裁判をできるだけの充分に理解力および主張・陳述する能力(弁論能力)を持たない場合、そのままでは裁判が遅延してしまうので、裁判所は当事者の陳述を禁止できるとともに(155条1項)、必要があれば当事者に弁護士の付き添いを命じる事ができる(155条2項)。
代替的紛争解決手続き

民事訴訟の他にも、調停や仲裁など、訴訟以外の方法で紛争解決をする手続きもある。なお、仲裁については仲裁法に規定がある。
Go/ソースコードの表現方法
文字

ソースコードは、UTF-8でエンコードされたUnicodeテキストです。テキストは正規化されていないので、1つのアクセント付きコードポイントは、アクセントと文字を組み合わせて作られた同じ文字とは区別され、それらは2つのコードポイントとして扱われます。『The Go Programming Language Specification』では、簡単のために、原文中のUnicodeコードポイントを参照するために、修飾語ではないcharacterを使用します。
文字

例えば、大文字と小文字は異なる文字です。
文字

実装上の制限。他のツールとの互換性のために、コンパイラーはソース・テキスト中の NUL 文字(NUL character; U+0000)を許可しないことがあります。
文字

実装上の制限。他のツールとの互換性のため、コンパイラーは UTF-8 でエンコードされたバイトオーダーマーク(BOM; U+FEFF)がソース・テキスト内で最初の Unicode コードポイントである場合、それを無視してもかまいません。バイトオーダーマークは、ソース内の他の場所では許可されません。
文字

この様に、ソースコードの文字コードを言語仕様書で明確に規定しているので、それ以外の文字コードを使うことは仕様に反した使用方法です。
文字

UTF-8エンコードに規定されているのはソースコードだけなので、他の文字コードでエンコーディングされたファイルの読み書きは専用のパッケージで定義された関数を使います。
文字

以下の用語は、特定のUnicode文字クラスを示すために使用されます。
文字

The Unicode Standard 8.0の4.5項「General Category」では、一連の文字カテゴリが定義されています。 Goでは、LetterカテゴリのLu、Ll、Lt、Lm、Loのいずれかに含まれるすべての文字をUnicodeの文字として扱い、NumberカテゴリのNdに含まれる文字をUnicodeの数字として扱います。
文字

アンダースコア文字「_」(U+005F)は、文字とみなされます。
Go/型と値の特性
基礎となる型

型と値の特性(Properties of types and values)
基礎となる型

各型Tには、基礎となる型(underlying type)があります。 Tがあらかじめ宣言された論理型、数値型、文字列型、あるいは型リテラルのいずれかである場合、対応する基礎となる型はT自身です。 そうでない場合、Tの基礎となる型は、Tが宣言の中で参照する型の基礎となる型です。 型パラメーターの場合は、その型制約の基礎となる型で、それは常にインターフェースです。
基礎となる型

非インタフェース型Tはそれぞれコア型(core type)を持ち、それはTの基礎となる型と同じです。 インターフェースTがコア型を持つのは、以下の条件のいずれかが満たされる場合である。
基礎となる型

他のインターフェースはコア型を持たない。
基礎となる型

インターフェースのコアタイプは、満たされる条件によって、次のいずれかになります。
基礎となる型

定義上、コア型は定義された型、型パラメータ、インタフェース型ではありません。
基礎となる型

型同一性(Type identity)
基礎となる型

2つの型の間にある関係は、同じか異なるかのどちらかです。
基礎となる型

定義された型は、常に他の型とは異なります。それ以外の場合、2つの型は、その基礎となる型リテラルが構造的に等価である場合、つまり、同じリテラル構造を持ち、対応するコンポーネントが同じ型を持つ場合、同一の型となります。詳しくは:
基礎となる型

次に示す宣言があったとき
基礎となる型

これらの型は同一です。
基礎となる型

func(int, float64) *B0 と func(x int, y float64) *[]string は、B0 が []string と異なるため、異なるものとなります。
基礎となる型

代入可能性(Assignability)
基礎となる型

値x がT 型の変数に代入可能である(「x はTに代入可能である」)のは、次のいずれかの条件が当てはまる場合である。
基礎となる型

表現可能性(Representability)
基礎となる型

定数 xは、以下の条件のいずれかに当てはまる場合、T 型の値で表現可能(representable)である。
Go/ブロック・宣言とスコープ
ブロック(Blocks)は、一致する波括弧の中に宣言とステートメントを並べた、空の可能性のあるシーケンスです。
ソースコードには、明示的なブロックの他に、暗黙のブロックがあります。
ブロックはスコーピングに影響を与えます。
脚註

宣言とスコープ(Declarations and scope)
脚註

宣言は、空白でない識別子を、定数、型、変数、関数、ラベル、パッケージに結びつけるものです。 プログラム内のすべての識別子は宣言されなければなりません。 同一ブロック内で2回宣言することはできず、ファイルブロックとパッケージブロックの両方で宣言することはできません。
脚註

空白の識別子は、他の識別子と同様に宣言の中で使用することができますが、結合を導入しないため、宣言されません。 パッケージブロックでは、識別子initはinit関数の宣言にのみ使用することができ、空白の識別子のように新しいバインディングを導入することはありません。
脚註

宣言された識別子のスコープは、その識別子が指定された定数、型、変数、関数、ラベル、パッケージを示すソーステキストの範囲です。
脚註

Goはブロックを使って語彙的にスコープを設定します。
脚註

ブロックで宣言された識別子は、内側のブロックで再宣言することができる。内側の宣言の識別子がスコープ内にある間は、内側の宣言によって宣言されたエンティティを表します。
脚註

package節は宣言ではなく、パッケージ名はどのスコープにも表示されない。その目的は、同じパッケージに属するファイルを識別することと、インポート宣言のデフォルトのパッケージ名を指定することです。
脚註

ラベルはラベル付きステートメントで宣言され、break, continue, goto 文で使用されます。 一度も使用されないラベルを定義することは違法です。 他の識別子とは異なり、ラベルはブロックスコープを持たず、ラベルではない識別子とは衝突しません。 ラベルのスコープは、ラベルが宣言されている関数のボディであり、ネストされた関数のボディは含まれません。
脚註

ラベル付けされたステートメントは、goto, break, continue 文のターゲットになることがあります。
脚註

ブランク識別子はアンダースコア文字「_」で表されます。 通常の(ブランクではない)識別子の代わりに匿名のプレースホルダーとして機能し、宣言、オペランド、代入において特別な意味を持ちます。
脚註

ユニバースブロックでは、いくつかの識別子が暗黙的に宣言されています。
脚註

識別子は、他のパッケージからのアクセスを可能にするためにエクスポートすることができます。識別子は以下の場合にエクスポートされます。
脚註

それ以外の識別子はエクスポートされません。
脚註

識別子の集合が与えられたとき、識別子が集合内の他のすべてのものと異なる場合、その識別子は一意と呼ばれます。 2つの識別子が異なる場合とは、スペルが異なる場合や、異なるパッケージに含まれていてエクスポートされない場合などです。 それ以外の場合は、同じです。
脚註

定数宣言は、識別子のリスト(定数の名前)を定数式のリストの値に束縛します。 識別子の数は式の数と等しくなければならず、左からn番目の識別子は右からn番目の式の値に束縛されます。
脚註

定数宣言の中で、宣言済み識別子 iota は、連続する型付けされていない整数定数を表します。その値は、定数宣言内のそれぞれのConstSpecのインデックスで、ゼロから始まります。この識別子は、関連する定数のセットを構築するために使用できます
脚註

型宣言は、識別子である型名を型に結びつけるものです。型宣言には、エイリアス宣言と型定義の2つの形式があります。。
脚註

識別子のスコープ内では、型のエイリアスとして機能します。
脚註

新しい型は、定義された型と呼ばれます。この型は、作成された型を含め、他の型とは異なります。
脚註

変数宣言では、1つまたは複数の変数を作成し、対応する識別子を結合し、それぞれに型と初期値を与えます。
脚註

関数宣言(Function declarations)は、識別子である関数名を関数に結びつけるものです。
脚註

関数のシグネチャが結果仮引数を宣言している場合、関数本体のステートメントリストは終了ステートメントで終わらなければなりません。
脚註

関数宣言で型パラメータを指定した場合、関数名はジェネリック関数を表します。ジェネリック関数は、呼び出したり値として使用したりする前に、インスタンス化されなければなりません。
脚註

型パラメータを持たない関数宣言では、ボディを省略することができます。 このような宣言は、アセンブリルーチンのようなGoの外部で実装される関数のシグネチャを提供します。
脚註

メソッド(A method)とは、レシーバーを持つ関数です。メソッド宣言では、識別子であるメソッド名をメソッドに結びつけ、そのメソッドとレシーバーの基底型を関連付けます。
脚註

レシーバーは、メソッド名の前にある追加の仮引数・セクションで指定されます。 この仮引数・セクションでは、単一の非可変仮引数であるレシーバーを宣言しなければなりません。 その型は、定義済みの型Tまたは定義済みの型Tへのポインタでなければならず、その後に角括弧で囲まれた型パラメータ名 [P1, P2, ...] のリストが続く場合もあります。 Tはレシーバー基底型と呼ばれます。レシーバー基底型はポインタやインタフェース型であってはならず、メソッドと同じパッケージで定義されなければなりません。メソッドはそのレシーバー基底型に束縛されていると言われ、メソッド名は型Tまたは*Tのセレクター内でのみ表示されます。
脚註

空白ではないレシーバーの識別子は、メソッドの署名(Signature)の中で一意でなければなりません。レシーバーの値がメソッドの内部で参照されない場合、その識別子は宣言で省略することができます。これは、関数やメソッドの仮引数についても同様です。
脚註

基底型の場合、それに束縛されるメソッドの空白でない名前は一意でなければならない。基本型が構造体の場合、空白でないメソッド名とフィールド名は一意でなければなりません。
脚註

型 Point が定義されている場合の宣言は
脚註

レシーバーの型が*PointであるメソッドLengthとScaleを基本型Pointにバインドします。
脚註

レシーバーの基本型がジェネリック型の場合、レシーバー仕様(receiver specification)はメソッドが使用する対応する型パラメータを宣言する必要があります。 これにより、レシーバー型パラメータはメソッドから利用できるようになります。 型パラメタの宣言は、文法的にはレシーバー基本型のインスタンス化のようなもので、型引数は宣言された型パラメタを示す識別子で、レシーバー基本型の各型パラメタに対して1つずつ宣言する必要があります。 型パラメータ名はレシーバー基本型の定義にある対応するパラメータ名と一致する必要はなく、空白でないパラメータ名はすべてレシーバー仮引数セクションとメソッドシグネチャーで一意である必要があります。レシーバー型パラメターの制約は、レシーバー基本型の定義が暗示するものであり、対応する型パラメターは対応する制約を持ちます。
Go/EBNF
The Go Programming Language Specification からEBNFで書かれた構文を抜粋しました。
Go/再帰的関数呼出し
フィボナッチ数

Goの関数は、再帰的関数呼出し(recursive function call)が可能です。
フィボナッチ数

strd()は、11行目と16行目で自分自身を呼び出しています。
フィボナッチ数

再帰的関数呼出しの定番、フィボナッチ数。
Go/メソッドチェイン
脚註

Goのメソッドは、メソッドチェイン(method chaining)が可能です。
脚註

28行目がメソッドチェーンです。 メソッド PrintName() と PrintAge() とも戻り値はレシーバと同じ Student で、この様なメソッドは戻り値を次のメソッドのレシーバーにできます。 レシーバーと戻り値の型が一致していなくてもメソッドチェインは可能ですが、型の組合せを慎重に考える必要があります。
架空世界の作り方
ここでは、主に現代的な架空世界の作り方を説明します。
架空世界とは

架空世界とは、その名の通り現実ではない想像上の世界のことです。なお、この本では、過去の歴史を改変し、現在とは違う世界線を作り出すもの(歴史改変SF、パラレルワールド)も架空世界として扱います。
準備するもの

リアリティのあるものを作るのにあたって、
準備するもの

などは必須道具となりますが、あなたの頭の中で作り上げることも可能ではあります。
準備するもの

また、もっとリアルなものを制作したいのであれば、
準備するもの

などの道具を用意することを検討してみてください。
目次

架空世界を作る上での基本的な知識や方法について。
目次

より、リアリティを出す方法について。
目次

あなたの作った架空世界を公開したり、それらを舞台とするコンテンツの作り方について。
架空世界の作り方/この本で扱う架空世界について
架空世界には大きく分けて二種類があります。
この本は主に後者を対象として作っています。逆に架空世界を作ってからそれに合わせた小説を書いたりする方法も書きます。
星座
星座は、全天を88分割したもの。その一つ一つに、ギリシア神話の神や道具、動物などに見立てて名前が付けられている。現在の88星座は1928年に国際天文学連合で定められたものである。88ある星座のうち、黄道が通るのは13である。
ガリア戦記/ガリア語の名前
『ガリア戦記』で言及されるガリア人の地名・部族名・人名などの名前(固有名詞)について解説する。
ガリア語とは

ガリア語 (羅 Lingua Gallica、英 Gaulish、仏 Gaulois) とは、ガリア (ガッリア)・イタリア半島北部・ヒスパニア中部・ルシタニアなどで5世紀頃まで話されていたケルト諸語の一派で、他の地域に居住する話者も母語として話していたとされている。ガリア語は死語ではあるが、多くの単語がヨーロッパ諸語、とりわけ地名に残されている。
ガリア語とは

下の表および右下の系統樹に、ガリア語を含むケルト諸語の言語学的分類を示す。ただし、これはケルト諸語を「島嶼ケルト」「大陸ケルト」に二分する伝統的な分類法であるが、近年では「Pケルト語」「Qケルト語」に二分する分類法もある。これは例えば、『ガリア戦記』でも言及されているように、アトレバテース族 Atrebates がブリタンニア島と大陸の双方にまたがって居住していたように、単純に島嶼・大陸と分けにくいことにもよる。
語彙集

以下では、仏語訳を緑色で示す。アステリスク * は再構を表わす。
Go/パッケージ
このページでは、Goのパッケージに関する構文と意味を解説しています。 標準パッケージライブラリーについては、Go/標準ライブラリーを参照してください。
ソースファイルの構成

式(An expression)は、 Goプログラムは、パッケージ(Packages)をリンクして構築されます。パッケージは、そのパッケージに属する定数、型、変数、関数を宣言した1つまたは複数のソースファイルから構成されます。これらの要素は、エクスポートして別のパッケージで使用することができます。
ソースファイルの構成

ソースファイルの構成(Source file organization)
ソースファイルの構成

各ソースファイルは、所属するパッケージを定義するパッケージ節、使用するパッケージを宣言するimport宣言(空の場合もある)、関数、型、変数、定数の宣言(空の場合もある)から構成されています。
ソースファイルの構成

パッケージ節(Package clause;PackageClause)は、各ソースファイルの先頭にあり、そのファイルが属するパッケージを定義します。
ソースファイルの構成

PackageNameは、ブランク識別子であってはなりません。
ソースファイルの構成

同じPackageName(パッケージ名)を持つファイルの集合が、パッケージの実装となります。パッケージの実装では、パッケージのすべてのソースファイルが同じディレクトリに存在することが要求される場合があります。
ソースファイルの構成

インポート宣言(Import declarations)とは、その宣言を含むソース・ファイルが、インポートされたパッケージの機能(§プログラムの初期化と実行)に依存し、そのパッケージのエクスポートされた識別子へのアクセスを可能にすることを意味します。インポートには、アクセスに使用する識別子(PackageName)と、インポートするパッケージを指定するImportPathが指定されます。
ソースファイルの構成

PackageNameは、インポートするソースファイル内のパッケージのエクスポートされた識別子にアクセスするための修飾識別子として使用されます。これは、ファイルブロックで宣言されています。PackageNameが省略された場合は、インポートされたパッケージのpackage節で指定された識別子がデフォルトとなります。名前の代わりに明示的なピリオド(.)が現れた場合、そのパッケージのpackage節で宣言された全てのパッケージのエクスポートされた識別子は、インポート元ファイルのfile節で宣言され、修飾子なしでアクセスしなければなりません。
ソースファイルの構成

ImportPathの解釈は実装に依存しますが、通常はコンパイルされたパッケージの完全なファイル名の部分文字列であり、インストールされたパッケージのリポジトリへの相対パスかもしれません。
ソースファイルの構成

実装上の制限。コンパイラは、ImportPathを、UnicodeのL、M、N、P、Sの一般カテゴリに属する文字(スペースを含まないグラフィック文字)のみを使用した空でない文字列に制限することができます。また、文字 !"#$%&'()*,:;<=>?[\]^`{|} および Unicode の置換文字 U+FFFD を除外することもできます。
ソースファイルの構成

関数Sinをエクスポートするパッケージ節package mathを含むパッケージをコンパイルし、コンパイルしたパッケージを「lib/math」で識別されるファイルにインストールしたとします。次の表は、さまざまなタイプのインポート宣言の後にパッケージをインポートするファイルで、Sinにどのようにアクセスするかを示しています。
ソースファイルの構成

インポート宣言は、インポートするパッケージとインポートされるパッケージの間に依存関係を宣言します。パッケージが自分自身を直接または間接的にインポートしたり、エクスポートされた識別子を参照せずにパッケージを直接インポートすることは違法です。副作用(初期化)のみを目的としてパッケージをインポートする場合は、空白の識別子を明示的なパッケージ名として使用します。
ソースファイルの構成

以下は、同時進行の素数ふるいを実装した完全なGoパッケージです。
Go/プログラムの初期化と実行
ゼロ値

プログラムの初期化と実行(Program initialization and execution)
ゼロ値

ゼロ値(The zero value) -- 宣言やnewの呼び出しによって変数にストレージが割り当てられたとき、あるいは複合リテラルやmakeの呼び出しによって新しい値が生成されたとき、明示的な初期化が行われなければ、その変数や値にはデフォルト値が与えられます。このような変数や値の各要素には、その型に応じたゼロ値が設定されます。ブーリアンはfalse、数値型は0、文字列は""、ポインタ、関数、インターフェース、スライス、チャンネル、マップはnilとなります。この初期化は再帰的に行われるので、例えば、構造体の配列の各要素は、値が指定されていない場合、そのフィールドがゼロになります。
ゼロ値

この2つの単純な宣言は等価です。
ゼロ値

上を踏まえて
ゼロ値

とすると、次のようになります。
ゼロ値

また、次のようにしても同じことが言えます。
ゼロ値

パッケージの初期化(Package initialization) -- パッケージ内では、パッケージレベルの変数の初期化が段階的に行われます。各段階では、未初期化の変数に依存していない、宣言順で最も早い変数が選択されます。
ゼロ値

より正確には、パッケージレベルの変数がまだ初期化されておらず、初期化式を持たないか、初期化式が未初期化の変数に依存していない場合、初期化の準備ができているとみなされます。初期化は、初期化可能な変数がなくなるまで、宣言順序が最も早く、初期化可能な次のパッケージレベルの変数を繰り返し初期化することで進行します。
ゼロ値

この処理が終了した時点でまだ初期化されていない変数がある場合、その変数は1つ以上の初期化サイクルの一部であり、プログラムは有効ではありません。
ゼロ値

右辺の単一(多値)式で初期化された変数宣言の左辺にある複数の変数は、まとめて初期化されます。左辺の変数のいずれかが初期化された場合、それらの変数はすべて同じステップで初期化されます。
ゼロ値

パッケージの初期化のために、ブランク変数は宣言の中で他の変数と同じように扱われます。
ゼロ値

複数のファイルで宣言された変数の宣言順序は、ファイルがコンパイラーに提示される順序によって決まります。最初のファイルで宣言された変数は、2番目のファイルで宣言されたどの変数よりも先に宣言され、以下同様です。
ゼロ値

依存性分析は、変数の実際の値には依存せず、ソース中の変数への字句の参照のみを過渡的に分析します。例えば、変数xの初期化式が、本体が変数yを参照している関数を参照している場合、xはyに依存していることになります。
ゼロ値

例えば、次のような宣言があるとします。
ゼロ値

の場合、初期化の順序は d, b, c, a となります。なお、初期化式の部分式の順序は関係ありません。a = c + bとa = b + cは、この例では同じ初期化順序になります。
ゼロ値

依存関係の分析はパッケージごとに行われます。現在のパッケージで宣言された変数、関数、(インターフェイスではない)メソッドを参照しているものだけが考慮されます。変数間に他の隠れたデータ依存性が存在する場合、それらの変数間の初期化順序は特定されません。
ゼロ値

たとえば,次のような宣言があったとします。
ゼロ値

変数 a は b の後に初期化されますが、x が b の前に初期化されるのか、b と a の間に初期化されるのか、a の後に初期化されるのか、したがって sideEffect() が呼び出される瞬間(x が初期化される前か後か)も指定されていません。
ゼロ値

変数は、パッケージブロックで宣言された init という名前の関数を使って、引数や結果のパラメータを指定せずに初期化することもできます。
ゼロ値

このような関数は、1つのソース・ファイル内であっても、パッケージごとに複数定義することができます。パッケージ・ブロックでは、init識別子はinit関数を宣言するためにのみ使用できますが、 識別子自体は宣言されません。したがって、init関数はプログラムのどこからも参照できません。
ゼロ値

インポートのないパッケージは、パッケージレベルの変数に初期値を割り当てた後、すべての init関数を、コンパイラに提示された順に呼び出すことで初期化されます (複数のファイルに分かれている場合もあります)。パッケージがインポートされている場合、インポートされたパッケージは、パッケージ自体を初期化する前に初期化されます。複数のパッケージがあるパッケージをインポートしている場合、インポートされたパッケージは一度だけ初期化されます。パッケージのインポートは、構造上、周期的な初期化の依存関係が存在しないことを保証します。
ゼロ値

パッケージの初期化(変数の初期化とinit関数の呼び出し)は、単一のゴルーチンで、一度に一つのパッケージを順番に実行します。init関数は、他のゴルーチンを起動することができ、初期化コードと同時に実行することができます。しかし、初期化は常にinit関数を順番に実行し、前の関数が戻るまで次の関数を起動しません。
ゼロ値

再現性のある初期化動作を保証するために、ビルドシステムは、同じパッケージに属する複数のファイルを、辞書的なファイル名の順序でコンパイラに提示することが推奨されます。
ゼロ値

プログラムの実行(Program execution) -- 完全なプログラムは、mainパッケージと呼ばれる単一の非インポートパッケージと、そのパッケージがインポートするすべてのパッケージを過渡的にリンクすることで作成されます。mainパッケージはパッケージ名mainを持ち、引数を取らず値を返さない関数mainを宣言しなければならない。
ゼロ値

プログラムの実行は、mainパッケージを初期化し、関数mainを呼び出すことから始まります。その関数の呼び出しが戻ると、プログラムは終了します。
ゼロ値

他の(mainではない)goroutines が完了するのを待つことはありません。