C#とは?

シー [1] 【 C ・ c 】

英語のアルファベット第三字。
創案Celsius頭文字から〕 摂氏温度であることを表す記号( C )。
蛇口などで)冷たい(cold)ことを表す記号( C )。 ↔ H
等級三番目。 「 -クラス落ちる」
〘音〙
ハの音。
四分の四拍子記号( C )。 〔本来は右の一部を欠いた円〕
世紀century)を示す記号( C )。
炭素carbon)の元素記号( C )。
サイクルcycle)を表す記号( c )。
ローマ数字100( C )。
電気量単位クーロンcoulomb)を表す記号( C )。
センチcenti-)を表す記号( c )。
プログラム言語の名称( C )。

C

等級の 3 番目。
創案Celsius頭文字から)摂氏温度であることを表す記号
アメリカ・イギリス・ドイツの音名の一(ドイツ語読みツェー)。ハ調長音階の第 1 音「ド」,日本音名の「ハ」。また,4 分の 4 拍子記号
Century世紀を表す記号
オランダ cyaan青緑色を表す記号シアンの略。
衣料品の,胸囲あるいはチェストを表す記号

c

centi
単位冠する接頭語で,10-2倍を表す。

AB(C)ロール 【AB(C)rolls】


炭素(C)

炭素(Carbon)は、元素記号 C で表され、原子番号は6、原子量は約12.01比重は2.25(g/cc)である。炭素族属する。同位体存在し、炭素12原子量基準とされるダイヤモンド黒鉛無定形炭素三種同素体天然産する化学的安定通常の溶媒に溶けず、酸・アルカリにもおかされない。
ステンレス鋼添加されると、オーステナイト結晶粒界Cr炭化物析出し、粒界腐食起こす種々の元素化合物をつくり、硬さ強度を増す。

ダイアモンド

分子式C
その他の名称:ダイアモンド、Diamond


アセチレンブラック

分子式C
その他の名称:炭素動物性,植物性】、カーボンブラックエキストラクト、Carbon black extractCarbon、C、活性炭Activated carbon活性炭素、Graphitized carbon blackCarbon blackAcetylene blackせきぼく、Grapite、カーボンブラック、アセチレンブラック、黒鉛化カーボンブラック、Activeated carbonpowder】、活性炭粒状】、Activeated carbongranule】、活性炭粉末】、AST-120、クレメジン、Kremezin
体系名:炭素


システイン

同義/類義語:シスチン
英訳・(英)同義/類義語:Cys, cysteine, C , Cys , cysteien, cysteine

タンパク質を構成するアミノ酸一種で、残基部分SH基を持つためタンパク質分子中で立体構造保持活性部位として働くこともある。また、分泌タンパク質では2つのSH基結合されてーS-S-結合作りタンパク質立体構造安定化に働く場合もある。略号Cys , C

シチジン

英訳・(英)同義/類義語:cytidine, C , Cyd, cytidine

ピリミジン塩基シトシンリボースがグリコシル結合してできたヌクレオシド

シトシン

英訳・(英)同義/類義語:C, cytosine, , Cyt, cytosine

ウラシルチミンと共に核酸構成するピリミジン塩基

補体

英訳・(英)同義/類義語:C, complement

血清中に存在するタンパク群で、抗体働き助け標的細胞破壊することから補体とよばれる

C

C → シトシン (核酸)
C → システイン (アミノ酸)


シトシン

ピリミジン塩基であり、シトシンヌクレオチドの基本骨格

名前Cytosine
C

CC Attribution-Noncommercial-Share Alike 3.0 Unported
Bio Wikiの記事を複製・再配布した「分子生物学用語集」の内容は、特に明示されていない限り、次のライセンスに従います:
CC Attribution-Noncommercial-Share Alike 3.0 Unported


補体(Complement、略号=C)

動物血清中の約20種類蛋白構成される物質遺伝的な欠損症の研究もとづき補体第1成分C1)から第9成分C9)まで分類されている。補体系抗体細菌成分によって刺激されると連鎖反応起こし食細胞機能増強抗原抗体結合強化リンパ球からの活性物質放出促進、あるいは細菌溶解など多彩な働きをする。最近研究から、異種移植で起こる超急性拒絶反応でも補体系が重要な役割をはたしているといわれる

読み方:しー

  1. 軍団のことをいふ。独語Die Corp(ディーコープ)の頭字を取つたものである。〔軍隊語〕

分類 軍隊

隠語大辞典は、明治以降の隠語解説文献や辞典、関係記事などをオリジナルのまま収録しているため、不適切な項目が含れていることもあります。ご了承くださいませ。 お問い合わせ

C

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2018/08/02 13:22 UTC 版)

Jump to navigation Jump to search
Cc Cc
ラテン文字
  Aa Bb Cc Dd  
Ee Ff Gg Hh Ii Jj
Kk Ll Mm Nn Oo Pp
Qq Rr Ss Tt Uu Vv
  Ww Xx Yy Zz  

Cは、ラテン文字アルファベット)の3番目の文字。小文字は c

字形

大文字、小文字とも半円形である。同形のキリル文字С сは別字で、ラテン文字のSに相当する文字である。

フラクトゥールではのようである。

歴史

C は、ギリシア文字のガンマ(Γ)が「く」の字の角度で書かれたものを丸めた形に由来する[1]。キリル文字のГは同系である。なおGを参照。

呼称

音価

現代では多くの言語の正書法や音標記号などにおいて用いられるが、その流儀は大きく2つに分類できる。

Cの置かれた位置によって2種類の音を表す正書法

元々のラテン語c は常に [k] で発音されるものだった[2]が、俗ラテン語時代になると転訛しはじめ、c の直後に“前舌母音”( e · i · y · æ )が来る場合に限り、その影響を受けて、c[c]「ティ」と「キ」の間のような子音)や [ʧ]「チャチュチョ」のような子音)で発音するようになった。これを軟音化と呼ぶ。 [k]と発音するのを「固い (hard) c」、摩擦音 (/s/) や破擦音で発音するのを「柔らかい (soft) c」と呼ぶ (en:Hard and soft C)。

時代が下りロマンス諸語が分化するにつれ、この音はさらに多様な音へと分化した。現在のロマンス諸語の正書法は、こうした自然の音変化を受け継いだものである。また、フランス語の影響を大きく受けた英語でも、同様の読み方をする[3]

どの言語においても、a · o · u · l · r などの前の c はラテン語時代と変わらない [k] 音を保っている[5]。 また、フランス語やルーマニア語などでは語末に c を置く単語がいくらかあり、これらも [k] で発音する[6]

(例) フランス語: lac [ラック] 「湖」 (同上)、ルーマニア語: bec [ベック] 「電球」 (同上)

英仏語のCとヨーロッパの言語

上記以外のヨーロッパ圏の言語では c をこのように使い分けることはないが、ラテン語やフランス語、英語などから c を含む単語を借用する場合、e · i · y ( · ä [7] ) の前の cz, c, s などに、a · o · u · l · r の前の ck に、それぞれ置き換えて用いるのが伝統的であった。一例を挙げれば:

いずれも英語やフランス語の concert 「コンサート、演奏会」の借用で、各言語の規則にしたがって字を置き換えたものである。

ベトナム語

ベトナム語の正書法「クオック・グー」では c はつねに [k] を表すが、その位置は a, o, u などの前[8]や音節末[9]に限られる。 その他の場所では [k] 音に kq を用いる。 わかりやすく言うと、ka, kê, ki, kô, ku, kwôk などと書けば済みそうなところ、わざわざ cq を持ち込んで、ca, kê, ky, cô, cu, quôc などと表記するルールだが、もともとクオック・グーはフランス人宣教師によって考案されたものであり、考案の際にロマンス諸語的な表記法を大いに参考にしたことがこうした部分にもよく表れているといえる。

Cの位置にかかわらず破擦音などを表す用法

インドネシア風かき氷 es campur を売るジャカルタ市内の屋台。「エス・チャンプル」と発音する。

正書法

その他

  • 国際音声記号では、[c]無声硬口蓋閉鎖音を表す。
  • ラテン文字による正書法のない言語などで音素寄りの音標文字としてラテン文字を使う場合は、c は [c][ʧ] の音に当てることが多い。主要な例としてサンスクリットがある。また日本人になじみの深い例として、アイヌ語のラテン文字表記を挙げることができる。
    (例) サンスクリット: candraḥ [チャンドラ] 「月」、アイヌ語: cise [チセ] 「家」

記号付き文字、多重音字などについて

  • 各種ダイアクリティカルマークの付いた c については、#関連項目を参照。
  • 二重音字としては、ゲルマン系の言語で ck [k] が広く定着しているほか、多くの言語で ch が様々に使われている。 後者については ch を参照のこと。
  • 国際音声記号で用いる ɔɕ については、それぞれの項目を参照。

C の意味

学術的な記号・単位

  • ラテン語で100を意味するcentum、ないしその派生語の略。
    • 1/100 を表すSI接頭辞センチ(小文字)。
    • ¢は英語ではセントと読み、基本通貨単位(ユーロドルなど)の1/100を表す単位として多くの国で使われる(国によって呼び名は異なる)。
  • ローマ数字の100。
  • circa (c.)
  • 12<∀N≤20のN進数において、十二十進数での12)を一(一文字)で表すために用いられる。
  • 炭素元素記号
  • 電荷の単位クーロンのシンボル。
  • 温度を示すセルシウス度(摂氏)で用いられる記号(℃)。
  • 数学では一般に既知の数、集合、行列等を示す、A, Bに次ぐ文字として用いられる。
  • 大文字太字の Cは、数学において複素数 (complex number) 全体の集合を表す。
  • 中心化群 CG(S)
  • 関数の滑らかさ Ck
  • 定数 (constant) を表す。特に積分定数を表す時は通例大文字。
  • nCm組合せ (combination) の総数。
  • 対称操作のひとつである回転を表現する記号。具体的な使用例は分子対称性を参照。
  • 実数連続体の基数
  • 光速度celeritas)を表す(小文字)。
  • 自然科学では熱容量電気容量capasity、大文字だが比熱容量を表す際は小文字)、濃度(concentration)、光度カンデラ:candela)を示す文字に用いる。電気容量を表すことから、回路素子のコンデンサ (condenser, capacitor) を表す際にも用いる
  • 加熱を示すときに用いられる場合がある。加熱を表すフランス語「Chauffage」の略。
  • トランジスタの端子の1つ。コレクタ (collector)
  • C言語。プログラミング言語の1つ。ここから派生した言語であるC++と組み合わせてC/C++と表記されることもある。
  • 虫歯を表す。また C1 - C4 (CはCariesの頭文字。)でその進行度を表す。
  • 文法で、補語 (complement)、可算名詞 (countable) の略号。
  • 音楽で用いられる拍子の1つ、4 分の 4拍子の記号は大文字の C に似ているが、起源的に関係がない。
  • カラー印刷などで使われる基本色 YMC, YMCK の中のシアン (Cyan)。
  • 音楽で用いられる音名の1つ(英米式、ツェー(独式))。イタリア式で「do」(ド)、日本式では「」に相当。 → ハ (音名)
    • 音階の1番目の音であることから、日本の音楽・芸能関係者の間で1を表す隠語として使われる。例:C(ツェー)万=1万(円)
  • 写真印画紙の面種が光沢仕上げ (crystal) であることを意味する。対する絹目はS (silk) で示す。
  • 視力検査で用いられるランドルト環は、Cを基にしている。
  • ケッペンの気候区分温帯を表すC
  • マクロ経済学で、Cは消費 (consumption)を表す。また、cは限界消費性向を表す。

その他の記号

商品名・作品名

符号位置

大文字 Unicode JIS X 0213 文字参照 小文字 Unicode JIS X 0213 文字参照 備考
C U+0043 1-3-35 &#x43;
&#67;
c U+0063 1-3-67 &#x63;
&#99;
半角
U+FF23 1-3-35 &#xFF23;
&#65315;
U+FF43 1-3-67 &#xFF43;
&#65347;
全角
U+24B8 &#x24B8;
&#9400;
U+24D2 1-12-35 &#x24D2;
&#9426;
丸囲み
🄒 U+1F112 &#x1F112;
&#127250;
U+249E &#x249E;
&#9374;
括弧付き
𝐂 U+1D402 &#x1D402;
&#119810;
𝐜 U+1D41C &#x1D41C;
&#119836;
太字
𝐶 U+1D436 &#x1D436;
&#119862;
𝑐 U+1D450 &#x1D450;
&#119888;
イタリック体
𝑪 U+1D46A &#x1D46A;
&#119914;
𝒄 U+1D484 &#x1D484;
&#119940;
イタリック体太字
𝒞 U+1D49E &#x1D49E;
&#119966;
𝒸 U+1D4B8 &#x1D4B8;
&#119992;
筆記体
𝓒 U+1D4D2 &#x1D4D2;
&#120018;
𝓬 U+1D4EC &#x1D4EC;
&#120044;
筆記体太字
U+212D &#x212D;
&#8493;
𝔠 U+1D520 &#x1D520;
&#120096;
フラクトゥール
U+2102 &#x2102;
&#8450;
𝕔 U+1D554 &#x1D554;
&#120148;
黒板太字
𝕮 U+1D56E &#x1D56E;
&#120174;
𝖈 U+1D588 &#x1D588;
&#120200;
フラクトゥール太字
𝖢 U+1D5A2 &#x1D5A2;
&#120226;
𝖼 U+1D5BC &#x1D5BC;
&#120252;
サンセリフ
𝗖 U+1D5D6 &#x1D5D6;
&#120278;
𝗰 U+1D5F0 &#x1D5F0;
&#120304;
サンセリフ太字
𝘊 U+1D60A &#x1D60A;
&#120330;
𝘤 U+1D624 &#x1D624;
&#120356;
サンセリフイタリック
𝘾 U+1D63E &#x1D63E;
&#120382;
𝙘 U+1D658 &#x1D658;
&#120408;
サンセリフイタリック太字
𝙲 U+1D672 &#x1D672;
&#120434;
𝚌 U+1D68C &#x1D68C;
&#120460;
等幅フォント
U+216D 1-3-35 &#x216D;
&#8557;
U+217D 1-3-67 &#x217D;
&#8573;
ローマ数字100
記号 Unicode JIS X 0213 文字参照 名称
U+1D04 &#x1D04;
&#7428;
LATIN LETTER SMALL CAPITAL C
U+1D9C &#x1D9C;
&#7580;
MODIFIER LETTER SMALL C
🄲 U+1F132 &#x1F132;
&#127282;
SQUARED LATIN CAPITAL LETTER C
🅒 U+1F152 &#x1F152;
&#127314;
NEGATIVE CIRCLED LATIN CAPITAL LETTER C
🅲 U+1F172 &#x1F172;
&#127346;
NEGATIVE SQUARED LATIN CAPITAL LETTER C
🄫 U+1F12B &#x1F12B;
&#127275;
CIRCLED ITALIC LATIN CAPITAL LETTER C

他の表現法

関連項目

脚注

[ヘルプ]
  1. ^ ギリシア文字のガンマ(Γ)は元々様々な角度で書かれていた。
  2. ^ ただし、G が発明されるより前の最初期のラテン語では、[k · g] の両音兼用だった。
  3. ^ オランダ語も同様。ただしラテン語やフランス語由来の語彙自体が英語よりはずっと少ない。
  4. ^ a b c フランス語・英語以外では cy の組み合わせは稀。
  5. ^ ただし cl の組み合わせは言語によって変形を被っていることが多い。例: ラテン語: clavis 「鍵」 [クラヴィス] > フランス語: clef [クレ] / イタリア語: chiave [キァーヴェ] / スペイン語: llave [リャベ] / ポルトガル語: chave [シャヴィ]
  6. ^ フランス語では無音の場合もある。 (例) blanc [ブラン] 「白い」。
  7. ^ ドイツ語ではラテン語の æä に置き換える。
  8. ^ 正確には、a · o · ô · u · ơ · ư · ă · â の前。
  9. ^ 正確には音節末では若干違った音になる。

C--

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2018/04/22 06:23 UTC 版)

C--
パラダイム 命令型プログラミング ウィキデータを編集
登場時期
  • 1997 ウィキデータを編集
開発者 Simon Peyton Jones ウィキデータを編集
最新リリース 2 / 2月 23, 2005[1]
影響を受けた言語 C ウィキデータを編集
ウェブサイト
拡張子 c-- ウィキデータを編集
テンプレートを表示

C--(シーマイナスマイナス)は、人間ではなくコンパイラが生成することを想定したC言語風のプログラミング言語中間言語)である。

歴史

1990年代、マルチプラットフォームプログラミング言語は、元言語ソースコードをC言語ソースコードトランスパイルして、C言語ソースコードを対象プラットフォームマシンコードコンパイルしていた[2]。C言語コンパイラは多様なプラットフォームのマシンコード出力をサポートしていたため、C言語を中間言語として採用することは現実的に利にかなった手法である。しかし、C言語は人間が読み書きするプログラミング言語として設計されているため、機械が処理してトランスパイルして生成する中間言語としては最適設計ではなかった。例えば、C言語ではガベージコレクション例外処理は意図的に言語仕様に組み込んでおらず、それらの機能を利用したプログラミング言語からC言語へのトランスパイルは一部機能が利用不可となる制限がありえた。

1997年、それらの課題を解決するため、ノーマン・ラムゼーはC--をImplementing Functional LanguagesワークショップでC--: A Portable Assembly Languageのタイトルで、コンパイラが扱うC言語に代わる中間言語として発表した[3]。C--は人間が読み書きするプログラミング言語としての特性より機械が処理する中間言語としての特性を重視し、多種プログラミング言語をフロントエンドに置きうるバックエンド仕様、マルチプラットフォームのマシンコード値型、ガベージコレクション・例外処理などのランタイムインターフェースを提供した。

1999年5月23日、C--バージョン1の言語仕様リファレンスがリリースされた[4]

2005年2月23日、C--バージョン2の言語仕様リファレンスがリリースされた[5]

2003年10月6日から2006年10月31日までの間、C--およびQuick C--の開発はアメリカ国立科学財団の支援を受けていた[6]

設計

C--は、人間が読み書きするためのプログラミング言語としてではなく、マシンが解釈するアセンブリ言語として設計されている。C--コードは極力プラットフォームアーキテクチャに依存せず、直交性・最小性より性能・利便性を重要視した言語仕様である。C--の文法は、C言語の言語仕様に似たプログラミング言語の特徴を持っている[7]

データ
プリミティブ型・参照型で定義される。プリミティブ型には16bit正数値のint型、 8bit文字のchar型、真偽値のboolean型がある。参照型にはプリミティブ型配列の配列型、複数型から成る構造体型がある。文字列はchar配列で表される。
変数
スタック型・ヒープ型で定義される。関数内のローカル変数はスタック変数、関数外のグローバル変数はヒープ変数として扱われる。
関数
関数名・返り値型・ブロック文で定義される。返り値は無を返す場合でも省略することは出来ず、キーワードvoidの返却を明記する。
演算子
C言語演算子を踏襲した比較演算・四則演算・ビット演算などが定義される。
空文・式文・ブロック文・if文・while文・do-while文・for文・return文・break文・continue文で定義される。

処理系

C--コードをマシンコードにコンパイルする処理系は複数存在する[8]。2018年現在、大半の処理系がソースコードの公開を含めメンテナンスされていない。

Quick C--
Quick C--は、The Quick C-- Teamが開発するコンパイラである[9]。C--バージョン2のC--コードをIntel x86のLinuxマシンコードへコンパイルする。他プラットフォームのマシンコードへのコンパイルは試験版機能として実装されている。従来はC--言語仕様の開発と平行してQuick C--が開発されていたが、2018年現在はgithubにソースコードが保管されているのみで開発は継続していない[10]
cmmc
cmmcは、Fermin ReigがML言語で実装したC--コンパイラである。Alpha・Sparc・X86のマシンコードを出力する。
Trampoline C-- Compiler
Trampoline C-- Compilerは、1999年5月にSergei Egorovが開発したC--からC言語へのトランスパイラである。
Oregons Graduate Institutes C-- compiler
Oregons Graduate Institutes C-- compiler(OGI C-- Compiler)は、1997年にML言語で実装された最初期のプロトタイプのC--コンパイラである[11]。Quick C--の開発が始まってからはメンテナンスは継続していない。

類似言語

Universal Computer Oriented Language英語版
Universal Computer Oriented Language(UNCOL)は、1958年にメルヴィン・コンウェイが提唱した中間言語である[12]。言語仕様として完全なものは存在しておらず、プログラミング言語とコンパイラの在り方に対する新しいコンセプトとして提案された。
GNU Assembler
GNU Assembler(GAS)は、1986年代に発表されたGCCのアセンブリ言語である[13]。GCCはC/C++ソースコードからGASソースコードへトランスパイルして、GASソースコードで処理最適化を実施してから、対象プラットフォームのマシンコードへコンパイルする。GCCはC/C++以外のプログラミング言語にも対応しており、他プログラミング言語のコンパイルでも同様の処理を経てマシンコードを出力する。
LLVM Assembly
LLVM Assembly(LLVM IR)は、2000年代以降に開発されているLLVMの中間言語である[14]。LLVMはコンパイルのバックエンド処理を主に担うコンパイラコンポーネントである。フロントエンド処理を担うのはclangrustcswiftcなどのプログラミング言語毎の異なるコンポーネントである。LLVMはLLVM IRソースコードで処理最適化を実施してから、対象プラットフォームのマシンコードへコンパイルする。

脚注

  1. ^ 出典URL: https://www.cs.tufts.edu/~nr/c--/extern/man2.pdf
  2. ^ Christopher Heng (30 August, 2017). “Free Modula-3 Compilers and Development Environment”. 2018年4月22日閲覧。 “It uses the GNU C Compiler as a backend to generate binaries.”
  3. ^ Norman Ramsey (2007年2月5日). “C--: A Portable Assembly Language”. 2018年4月22日閲覧。
  4. ^ Norman Ramsey (1999年5月23日). “The C-- Language Specification Version 2.0”. 2018年4月22日閲覧。
  5. ^ Norman Ramsey (2007年2月5日). “C-- Manual Version 1 (pdf)”. 2018年4月22日閲覧。
  6. ^ NSF Award Search: Award#0325460 - ITR Collaborative Research: A Reusable, Extensible, Optimizing Back End”. National Science Foundation. 2018年4月22日閲覧。
  7. ^ 柳 洋輔 (2015年9月15日). “C--言語からC言語への変換系の実用化”. 2018年4月22日閲覧。
  8. ^ Norman Ramsey (2007年2月5日). “C-- Downloads - Other C-- compilers”. 2018年4月22日閲覧。
  9. ^ The Quick C-- Team (2014年1月24日). “Release notes for the Quick C-- compiler Release 20140124 (pdf)”. 2018年4月22日閲覧。
  10. ^ Norman Ramsey (2014年1月25日). “The Quick C-- Compiler”. 2018年4月22日閲覧。
  11. ^ Pacsoft Research C-- Compiler”. Pacific Software Research Center. (1998年3月4日). 2007年8月16日時点のオリジナル[リンク切れ]よりアーカイブ。
  12. ^ Melvin E. Conway. “Proposal for an UNCOL”. Communications of the ACM. 2018年4月22日閲覧。
  13. ^ Dean Elsner. “Using as The gnu Assembler (pdf)”. The Regents of the University of Michigan. 2018年4月22日閲覧。
  14. ^ LLVM IR and Transform Pipeline (pdf)”. 2018年4月22日閲覧。

外部リンク


C++

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2018/07/26 23:07 UTC 版)

Jump to navigation Jump to search
C++
パラダイム マルチパラダイム手続き型プログラミングデータ抽象オブジェクト指向プログラミングジェネリックプログラミングの組み合わせ)
登場時期 1983年
設計者 ビャーネ・ストロヴストルップ
最新リリース ISO/IEC 14882:2017/ 2017年12月1日(7か月前) (2017-12-01
評価版リリース ISO/IEC 14882:2017
型付け nominative, 安全でない強い静的型付け
主な処理系 GCC
Clang
Microsoft Visual C++
Intel C++ Compiler
C++ Builder
影響を受けた言語 C言語SimulaAda
影響を与えた言語 JavaC#D言語PHP
ウェブサイト isocpp.org
拡張子 .cc, .cpp, cxx; .h, .hpp
テンプレートを表示

C++シープラスプラス)は、汎用プログラミング言語の一つである。日本語では略してシープラプラシープラなどとも呼ばれる。

概要

1983年にベル研究所のコンピュータ科学者のビャーネ・ストロヴストルップが、C言語の拡張として開発した。当時の名前は「C with Classes」(クラス付きのC言語)だった。拡張はクラスの追加に始まり、仮想関数多重定義多重継承テンプレート例外処理といった機能が続いていった。

標準規格化がISOIEC共同で行われており、現在最新のバージョンは、2017年に制定されたISO/IEC 14882:2017、通称「C++17」である。

表現力と効率性の向上のために、手続き型プログラミングデータ抽象オブジェクト指向プログラミングジェネリックプログラミングの複数のプログラミングパラダイムを組み合わせている[1]アセンブリ言語以外の低水準言語を必要としない、使わない機能に時間的・空間的費用を要しないことが、言語設計の重要な原則となっている[2][3]。また、静的な型システムを持つ。

歴史

ストロヴストルップはプログラミング言語C with Classesの開発を1979年に開始した。彼は大規模なソフトウェアの開発に有用な特徴をSimulaが備えていることに気がついたが、Simulaは実行速度が遅く実用的ではなかった。一方でBCPLは実行速度こそ速かったものの、大規模なソフトウェア開発を念頭に置いた場合にあまりにも低級だった。

これらの事情を鑑みて、ストロヴストルップは当時既に汎用的な言語だったC言語にSimulaの特徴を取り入れることを試みた。この取り組みにあたってはALGOL68AdaCLUML等の言語の影響も受けている。最初はクラスと派生クラス、型検査機構の強化、インライン関数、デフォルト引数の機能を、Cfrontを介してC言語に追加した。1985年10月に最初の商用リリースがなされた[4]

1983年にはC with ClassesからC++に名称を変更した。この際に、仮想関数と、関数と演算子の多重定義参照型、const型、ユーザー制御可能な自由領域メモリ制御、型検査機構の改良、BCPL形式(「//」による)の行単位のコメントアウトなどの機能が追加された。1985年には『The C++ Programming Language』の初版が出版された(邦訳『プログラミング言語C++』1988年))。この時点では公式な標準が策定されていなかったために、この本が事実上のリファレンスとなった。1989年C++のヴァージョン2.0として、多重継承抽象クラス、静的メンバ関数constメンバ関数、protectedメンバ等の機能が追加されたものがリリースされた。1990年に『The Annotated C++ Reference Manual (ARM)』[5](邦訳『注解C++リファレンスマニュアル』[6])が出版され、将来の標準化の土台となるものを提供した。後に追加された機能にはテンプレート例外処理名前空間、新形式のキャストブール型が含まれた。

ARMが事実上の標準として使われた時代が続いたが、標準化が進んだ。C++言語の最初の標準は1998年にISO/IEC 14882:1998として承認された。2003年の改訂版を経て、2011年にメジャーアップデートとして制定されたのがISO/IEC 14882:2011、通称「C++11」である。このバージョンは、元々、非公式に「C++0x」と呼ばれていた。2000年代中に制定され、正式に「C++09」と呼称されることを見越した仮称だったが、2000年代中には実現しなかった。2011年8月10日まで続いた最終国際投票で C++0x は全会一致で承認された。これにより C++0x と呼ばれてきた C++ の次期改正案はついに国際標準になり、C++11と呼べるようになった。また、2014年にはISO/IEC 14882:2014、通称「C++14」が策定された。2018年現在の最新バージョンは2017年に策定されたISO/IEC 14882:2017、通称「C++17」である。2020年にはISO/IEC 14882:2020、「C++20」が策定される予定である。

C++言語の進化に伴い、標準ライブラリもまた進化していった。C++標準ライブラリに最初に追加されたのは、従来のC言語の printf()scanf() といった関数を置き換えるストリームI/Oライブラリである。また、C++98における標準ライブラリへの追加で最も重要なものはStandard Template Library (STL)である。C++11では、正規表現による検索・置換や複数スレッドでの同時実行、ハッシュテーブル・ハッシュセットの追加などさらなる拡充が続いている。

標準規格

規格制定日 C++ 標準規格 非公式名称
1998年9月1日 ISO/IEC 14882:1998[7] C++98
2003年10月16日 ISO/IEC 14882:2003[8] C++03
2007年11月15日 ISO/IEC TR 19768:2007[9] C++TR1
2011年9月1日 ISO/IEC 14882:2011[10] C++11
2014年12月15日 ISO/IEC 14882:2014[11] C++14
2017年12月 ISO/IEC 14882:2017[12] C++17
2020年予定 C++20

長年にわたる作業の後、ANSIとISOの合同委員会はC++言語を1998年に標準化した(ISO/IEC 14882:1998)。1998年の標準の公式なリリースから数年間に渡って委員会は不具合の報告を続け、2003年に訂正版を出版した。2003年12月に制定された日本工業規格JIS X 3014:2003(プログラム言語 C++)は、ISO/IEC 14882:2003(E)の日本語への翻訳である。

2007年11月15日に『C++ Technical Report 1』 (TR1)というテクニカルレポートがリリースされた。これは標準の公式な一部ではないが、次のバージョンのC++に含まれると期待される、標準ライブラリへの数多くの拡張を与えた。TR1の内容は、多少の修正を加えてC++11に取り込まれている。

2011年9月1日、C++98以来初の大きな改訂となるISO/IEC 14882:2011が発行された。

2014年8月18日、ISO/IEC 14882:2014(C++14)が投票で承認され[13]、2014年12月15日、公式に出版された。

2017年12月、ISO/IEC 14882:2017(C++17)が公式に発行された。

現在、C++20の仕様策定が進められている。

将来

C++に対しては、今もなお要望が絶えない。特にBoostはC++の方向性の決定に大きく貢献し、さらにC++標準化委員会へ改良すべき点などを意見している。現在はマルチパラダイムプログラミングをより自然に行えるようにすることに力が注がれており、たとえばBoostでは、C++の関数型プログラミングメタプログラミングの可能性を模索している。

C++11と呼ばれている新しいバージョンのC++標準ではこれらの一部が取り込まれ、今後のC++でもさらなる追加が行われると見られている。

C++という名称

この名称はRick Mascittiの功績で、最初に使用されたのは1983年の12月である。初期の研究期間では、開発中の言語は「C with Classes」と呼ばれていた。最終名は、変数の値を一つ加算する、C言語の++インクリメント)演算子からの派生である。また一般的な命名規則での「+」の使用は、機能強化されたコンピュータプログラムを意味する。ストロヴストルップによれば「この名前は、C言語からの変更の革新的な本質を示している」ということである。C+は、より初期の無関係なプログラミング言語の名前である。

ストロヴストルップは著書『The C++ Programming Language』の前文で名前の起源を語り、ジョージ・オーウェルの小説『1984年』の付録から「C++」が連想されるかもしれないと付け加えている。新語法という架空の言語の解説に宛てられた3つの章の中に、科学技術に関する専門用語とジャーゴンの解説に宛てられた「C vocabulary」という章がある。新語法で「ダブルプラス」は最上級の修飾語である。ゆえに新語法で「C++」は「最も極端な専門用語またはジャーゴン」という意味になるだろう。

1992年、Rick Mascittiは名前について非公式に質問されると、彼はおふざけのつもりで命名したという旨の回答をした。彼はこの言語の正式な名称になるとは夢にも思っていなかった。

哲学

ビャーネ・ストロヴストルップは著書『C++の設計と進化(1994)』でC++を設計する際に用いたルールを述べている。

  • C++はCと同等の実行効率と移植性を持つ静的に型付けされた汎用言語である。
  • C++は直接的かつ包括的に複数のプログラミングスタイル(手続き型プログラミング抽象化オブジェクト指向ジェネリックプログラミング)をサポートする。
  • C++はもしプログラマが間違っている可能性があったとしてもプログラマに選択の余地を与える。
  • C++は可能な限りC言語との互換性を持ち、C言語からスムーズに移行できる。
  • C++はプラットフォームに固有な機能や汎用的でない機能の実装を避ける。
  • C++は利用しない機能についてはオーバーヘッドが生じない(ゼロオーバーヘッドの原則)。
  • C++は高級な実行環境を必要としない。

C++のコンパイラがどのようにコードを出力しメモリのレイアウトを決めるのかということについては『Inside the C++ Object Model』(Lippman, 1996)に記載されている。ただしコンパイラが出力するコードの仕様はコンパイラ制作者の裁量に任されている。

標準ライブラリ

1998年に施行されたANSI/ISO C++ 規格は言語仕様とライブラリの2つのパートで構成される。ライブラリ規格の大半はStandard Template Library (STL)とC言語の標準ライブラリの改良版についての内容である。標準規格以外にも様々なライブラリが数多く存在し、リンカを使用することにより、C言語FORTRANPascalBASICのような言語を用いて作成されたライブラリを利用できる。規格外のライブラリが利用できるかどうかはコンパイラに依存する。

C++標準ライブラリはC++向けに若干の最適化が施されたC言語標準ライブラリを含んでいる。C++標準ライブラリの大部分はSTLである。 コンテナ可変長配列リストなど)、コンテナを配列のように扱えるようにするイテレータ、検索やソートを行うアルゴリズムといった有用なツールが提供されている。さらにmapmultimapのような連想配列や、setmultisetのようなソート済みコンテナも提供され、これらは全てインターフェイスに互換性がある。テンプレートを用いることにより、あらゆるコンテナ(またはイテレータで定義したシーケンス)に適用できる汎用的なアルゴリズムを記述できる。C言語と同様にライブラリの機能には#include ディレクティブを使ってヘッダファイルを読み込むことによってアクセスする。C++には69本の標準ヘッダファイルがあるが、このうち19本については非推奨となっている。

STLは標準規格に採用される前は、ヒューレット・パッカードの(一時はシリコングラフィックスの)商用ライブラリだった。STLは標準規格の単なる一部分に過ぎず規格書にSTLという表記は見られないが、入出力ストリーム、国際化、デバッグ機能、C言語標準ライブラリ等の、STL以外の部分と区別するために、今でも多くの人がSTLという用語を使っている。

大半のC++コンパイラはSTLを含むC++標準ライブラリの実装を提供している。STLPortのようなコンパイラ非依存のSTLも存在する。様々な目的でC++標準ライブラリを独自に実装しているプロジェクトは他にもある。

C++の標準ライブラリは大きく次のように分けられる。多種多様な実行環境が存在することを考慮して、GUIに関するライブラリは標準に含まれていない。

外部ライブラリ

以下に、C++で広く使われていると思われるライブラリを挙げる。

Boost
次期C++標準とも言われる様々なライブラリの集合。正規表現を扱うBoost.Regexや無名関数(ラムダ計算)を簡潔に記述できるBoost Lambda Libraryなどがある。現標準であるC++11や次期標準であるC++14でも、Boostに存在するライブラリが標準ライブラリに採用されたり、標準ライブラリとして提案された項目がBoostで先行して実装されたりしている。これにより、実際に実装・使用することでの知見が得られ、標準ライブラリとして採用される際に活かされている。
Apache Xerces
C++での主要XMLパーサの一つ。Java版も存在する。
CppUnit
C++でのユニットテストフレームワーク。 クラス毎の動作確認に威力を発揮する。

特徴

C言語に、オブジェクト指向プログラミングをはじめとする様々なプログラミングパラダイムをサポートするための改良が加えられたものといえる。ただし、他のプログラミング言語と違い、旧来のCと同様に手続き型言語としても扱えるという特徴がある。このことから、C++をbetter Cというふうに呼ぶことがある。すなわち、基本的にC言語に対して上位互換性がある。初期のC++はCへのトランスレータとして実装され、C++プログラムを一旦Cプログラムに変換してからコンパイルしていた。

ただし、C++という名称が定まった当初の時期から、C言語とC++との間には厳密な互換性はない[14][15]。当時、Cとの互換性について議論の末、「C++とANSI Cの間には不正当な非互換性はない」という合意が形成されることとなった。そのため、正当な非互換性を巡って多くの議論が発生した[16]。ただし、まだANSIによるC言語の標準規格も策定途中の時期である。

その後、先祖であるC言語のANSIによる標準規格制定時には、関数のプロトタイプ宣言やconst修飾など、C++の機能がC言語に取り入れられることにもなった。C99の出現により、//コメントなどのC++で使われていた便利な機能が加わってCとC++の互換性が高まる一方、別々に審議し、別の時期に発行していることと、開発対象が必ずしも同じでないために利害関係者が異なることによる違いもある[要出典]​。

次のような多種多様な機能を持っており、言語仕様は大変複雑である。

ここから、よりオブジェクト指向を強化し、「なんでもあり」ではない代わりに分かりやすくスマートな設計を目指した新たな言語(JavaD言語など)が作られることとなった。

Hello, World!

C++はC言語およびそのプリプロセッサの構文をほぼ継承している。以下のサンプルはビャーネ・ストロヴストルップの書籍「The C++ Programming Language, 4th Edition」(ISBN 978-0321563842) の「2.2.1 Hello, World!」に記載されている標準C++ライブラリのストリーム機能を用いて標準出力に出力するHello worldプログラムである[17][18]

#include <iostream>

int main()
{
     std::cout << "Hello, World!\n";
}

書籍でも明記されているが、main()関数で意図的に返り値を返さない手法が使用されている。

演算子と演算子のオーバーロード

C++には四則演算、ビット演算、参照、比較、論理演算などの30を超える演算子がある。メンバーアクセス演算子(..*)のような一部の例外はあるが、大半の演算子はユーザー定義によるオーバーロードが可能である。オーバーロード可能な演算子が豊富に揃えられているためC++を一種のドメイン固有言語として利用できる。またオーバーロード可能な演算子はスマートポインタのような先進的な実装テクニックに欠かせないものとなっている。演算子をオーバーロードしても演算の優先順位は変化せず、また演算子のオペランドの数も変化しない。ただし指定したオペランドが無視される可能性はある。

テンプレート

C++には、ジェネリックプログラミングを実現する機能としてテンプレートが存在する。テンプレートにできる対象は、関数とクラスである。テンプレートは型、コンパイル時定数またはその他のテンプレートによってパラメタライズできる。テンプレートはコンパイル時にインスタンス化(実体化・具現化などとも)される。コンパイラは関数やクラスをインスタンス化するためにテンプレート仮引数を特定の値に置き換える。テンプレートはジェネリックプログラミングテンプレートメタプログラミング、コード最適化などのために利用される強力なツールであるが、一定のコストを伴う。各テンプレートのインスタンスはテンプレート仮引数毎にテンプレートコードのコピーを生成するためコードサイズが肥大化する。コンパイル時に型の情報を削除して単一のテンプレートインスタンスを生成するランタイム型のジェネリクスを実装したJavaなどの言語とは対照的である。

テンプレートとマクロはいずれもコンパイル時に処理される言語機能であり条件に基づいたコンパイルが行われるが、テンプレートは字句の置き換えに限定されない。テンプレートはC++の構文と型を解析し、厳密な型チェックに基づいた高度なプログラムの流れの制御ができる。マクロは条件コンパイルに利用できるが、新しい型の生成、再帰的定義、型の評価などは行えないため、コンパイル前のテキストの置き換えや追加・削除といった用途に限定される。つまりマクロは事前に定義されたシンボルに基づいてコンパイルの流れを制御できるものの、テンプレートとは異なり独立して新しいシンボルを生成することはできない。テンプレートは静的な多態(下記参照)とジェネリックプログラミングのためのツールである。

C++のテンプレートはコンパイル時におけるチューリング完全なメカニズムである。これはテンプレートメタプログラムを用いて実行する前にコンピュータが計算可能なあらゆる処理を表現できることを意味している。

概略すれば、テンプレートはインスタンス化に必要な引数を明確にしなくても記述できるコンパイル時にパラメタライズされる関数またはクラスである。インスタンス化した結果は、テンプレート仮引数に指定した型に特化した形で記述されたコードと全く等価になる。これによりテンプレートは、汎用的かつおおまかに記述された関数及びクラス(テンプレート)と特定の型に特化した実装(インスタンス化されたテンプレート)の依存関係を解消し、パフォーマンスを犠牲にすることなく抽象化できる手段を提供する。

オブジェクト

C++はC言語オブジェクト指向プログラミングをサポートするための改良を加えたものといえる。C++のクラスには、オブジェクト指向言語で一般的な抽象化カプセル化継承多態の4つの機能がある。オブジェクトは実行時に生成されるクラスの実体である。クラスは実行時に生成される様々なオブジェクトのひな形と考えることができる。

なお、C++はSmalltalkなどに見られるメッセージ転送の概念によるオブジェクト指向を採用していない。

カプセル化

カプセル化とは、データ構造を保証し、演算子が意図したとおりに動作し、クラスの利用者が直感的に使い方を理解できるようにするためにデータを隠蔽することである。クラスや関数はC++の基礎的なカプセル化のメカニズムである。クラスのメンバはpublicprotectedprivateのいずれかとして宣言され明示的にカプセル化できる。publicなメンバはどの関数からでもアクセスできる。privateなメンバはクラスのメンバ関数から、またはクラスが明示的にアクセス権を与えたフレンド関数からアクセスできる。protectedなメンバはクラスのメンバおよびフレンド関数に加えてその派生クラスのメンバからもアクセスできる。

オブジェクト指向では原則としてクラスのメンバ変数にアクセスする全ての関数はクラスの中にカプセル化されなければならない。C++ではメンバ関数およびフレンド関数によりこれをサポートするが、強制はされない。プログラマはメンバ変数の一部または全体をpublicとして定義でき、型とは無関係な変数をpublicな要素として定義できる。このことからC++はオブジェクト指向だけでなく、モジュール化のような機能分割のパラダイムもサポートしているといえる。

一般的には、全てのデータprivateまたはprotectedにして、クラスのユーザに必要最小限の関数のみをpublicとして公開することがよい習慣であると考えられている。このようにしてデータの実装の詳細を隠蔽することにより、設計者はインターフェイスを変更することなく後日実装を根本から変更できる [19] [20]

継承

継承を使うと他のクラスの資産を流用できる。基底クラスからの継承はpublicprotectedprivateのいずれかとして宣言する。このアクセス指定子により、派生クラスや全く無関係なクラスが基底クラスのpublicおよびprotectedメンバにアクセスできるかどうかを決定できる。普通はpublic継承のみがいわゆる派生に対応する。残りの二つの継承方法はあまり利用されない。アクセス指定子を省略した場合、構造体public継承になるのに対し、クラスではprivate継承になる。基底クラスをvirtualとして宣言することもできる。これは仮想継承と呼ばれる。仮想継承は基底クラスのオブジェクトが一つだけ存在することを保証するものであり、多重継承の曖昧さの問題を避けることができる。

多重継承はC++の中でもしばしば問題になる機能である。多重継承では複数の基底クラスから一つのクラスを派生できる。これにより継承関係が複雑になる。例えば"FlyingCat"クラスは"Cat"クラスと"FlyingMammal"クラスから派生できる。JavaC#では、基底クラスの数を一つに制限する一方で、複数のインタフェースを継承でき、これにより制約はあるものの多重継承に近い機能を実現できる。インタフェースはクラスと異なりメンバ関数を宣言できるのみであり、関数の実装やメンバ変数は定義できない。JavaとC#のインタフェースや抽象クラスはC++の抽象基底クラスと呼ばれる関数宣言のみを持つクラスに相当する。JavaやC#の継承モデルを好むプログラマは、非抽象クラスからのみクラスを派生させる方法を選択できる。この場合は抽象基底クラスのメンバ関数を必ず明示的に定義しなければならず、またこのクラスを継承することはできない。

多態

多態(ポリモーフィズム)はよく多用されているインターフェイスの機能であり、様々な状況下でオブジェクトに異なる振る舞いをさせることができる。

C++は静的な多態動的な多態の両方をサポートする。コンパイル時に解決される静的な多態は実行時には考慮されないのに対し、ランタイム時に解決される動的な多態はパフォーマンス的に不利である。

静的な多態

関数のオーバーロードは名称が同じ複数の関数を宣言できる機能である。ただし引数は異なっていなければならない。関数は引数の型や数で区別される。同名の関数はコードの文脈によってどの関数が呼ばれるのかが決まる。関数の戻り値の型で区別することはできない。

関数を宣言する際にプログラマはデフォルト引数を指定できる。関数を呼び出すときに引数を省略した場合はデフォルト引数が適用される。関数を呼び出すときに宣言よりも引数の数が少ない場合は、左から右の順で引数の型が比較され、後半部分にデフォルト引数が適用される。たいていの場合は一つの関数にデフォルト引数を指定するよりも引数の数が異なる関数をオーバーロードする方が望ましい。

C++のテンプレートではより洗練された汎用的な多態を実現できる。特にCuriously Recurring Template Patternにより仮想関数のオーバーライドをシミュレートした静的な多態を実装できる。C++のテンプレートは型安全かつ チューリング完全であるため、 テンプレートメタプログラミングによりコンパイラに条件文を再帰的に解決させて実行コードを生成させることにも利用できる。

動的な多態

派生

基底クラスへのポインタ変数及び参照は、正確に型が一致するオブジェクトだけでなく、その派生クラスのオブジェクトを示すことができる。これにより配列やコンテナは複数の型へのポインタを保持できる。ポインタ変数は実行時に値が割り当てられるためこれは実行時の話である。

dynamic_castは基底オブジェクトから派生オブジェクトへの変換を安全に行うための演算子である(派生オブジェクトから基底オブジェクトへの変換ではキャストは必要ない)。この機能は実行時型情報 (RTTI)に依存している。オブジェクトが特定の派生オブジェクトであることがあらかじめわかっている場合はstatic_castでキャストすることもできる。static_castは純粋にコンパイル時に解決されるため動作が速くRTTIを必要としない。

仮想関数

基底クラスの関数を派生クラスでオーバーライドした場合、実際に呼び出される関数はオブジェクトの型によって決定される。派生クラスによってオーバーライドでされるのは引数の数や型が同じ関数である。基底クラスのポインタのみが与えられた場合、コンパイラはオブジェクトの型をコンパイル時に特定できず正しい関数を呼び出せないため、実行時にこれを特定する。これをダイナミックディスパッチと呼ぶ。仮想関数やメソッド[21]により、オブジェクトに割り当てられた実際の型に従って、最上位の派生クラスで実装した関数が呼び出される。一般的なC++コンパイラは仮想関数テーブルを用いる。オブジェクトの型が判明している場合はスコープ解決演算子を利用して仮想関数テーブルを使わないようにバイパスすることもできるが、一般的には実行時に仮想関数の呼び出しを解決するのが普通である。

標準のメンバ関数に加え、オーバーロードした演算子やデストラクタも仮想関数にできる。原則的にはクラスが仮想関数を持つ場合はデストラクタも仮想関数にすべきである。コンストラクタやその延長線上にあるコピーコンストラクタはコンパイルされた時点でオブジェクトの型が確定しないため仮想関数にできない。しかし、派生オブジェクトへのポインタが基底オブジェクトへのポインタとして渡された場合に、そのオブジェクトのコピーを作らなければならない場合は問題が生じる。このような場合はclone()関数(またはそれに準じる物)を仮想関数として作成するのが一般的な解決方法である。clone()は派生クラスのコピーを生成して返す。

= 0を関数宣言の閉じ括弧とセミコロンの間に挿入することによりメンバ関数を純粋仮想関数にできる。純粋仮想関数を持つクラスは純粋仮想クラスと呼ばれ、このクラスからオブジェクトを生成することはできない。このような純粋仮想クラスは基底クラスとしてのみ利用できる。派生クラスは純粋仮称関数を継承するため、派生クラスのオブジェクトを生成したい場合は全ての純粋仮想関数をオーバーライドして実装しなければならない。純粋仮想関数を持つクラスのオブジェクトを生成しようと試みるようなプログラムは行儀が悪い。

テンプレート

型消去と呼ばれるテンプレートを活用して動的な多態性を実現する手法が存在する。この手法はC++の標準ライブラリでもstd::functionstd::shared_ptrの削除子で採用されている。いずれも、コンストラクタや代入演算子で(一定の条件を満たす)任意のオブジェクトを実引数として渡せるようにすることから多態性を実現している。

単一行コメント

かつてC言語とC++との分かりやすい差異として、// で始まり改行で終わる、単一行コメントの有無があった。

単一行コメントはもともと、C言語の祖先にあたるBCPLに含まれていた仕様である。現在のC++のコンパイラの多くがC言語のコンパイラとしても使えるようになっているのと同様に、C言語が生まれて間もない頃は、C言語に加えB言語やBCPLのコンパイルができるコンパイラが用いられていた。それらコンパイラは、C言語のソースであってもBCPLと同様に単一行コメントが使用できるよう独自の拡張がなされていたため、BCPLの単一行コメントに慣れ親しんでいたプログラマ達は、C言語でも単一行コメントを使い続けた。その慣習がC++の誕生時まで生き残っていたため、C++では単一行コメントを「復活」させることになった。

そのためもあって、C言語での仕様外の単一行コメントの使用は半ば常習と化し、現在ではC99によって、C言語でも正式に単一行コメントがサポートされるようになった(//に対応していない古い仕様のCコンパイラでもcppを対応したものに変更することにより使用可能)。

C++ソースコードの処理とパーサ

LALR(1)のような旧式のパースアルゴリズムを用いてC++のパーサを記述することは比較的難しい[22]。その理由の一つはC++の文法がLALRではないことである。このため、コード分析ツールや、高度な修正を行うツール(リファクタリングツールなど)は非常に少ない。この問題を取り扱う方法としてLALR(1)でパースできるように改良されたC++の亜種(SPECS)を利用する方法がある。GLRパーサのようにより強力でシンプルなパーサもあるが処理が遅い。

パースはC++を処理するツールを作成する際の最も難しい問題ではない。このようなツールはコンパイラと同じように識別子の意味を理解しなければならない。従ってC++を処理する実用的なシステムはソースコードをパースするだけでなく、各識別子の定義を正確に適用し(つまりC++の複雑なスコープのルールを正確に取り扱い)、型を正しく特定できなければならない。

いずれにせよC++ソースコード処理ツールが実用的であるためには、GNU GCCVisual C++で使われているような、様々なC++の方言を取り扱えなければならず、適切な分析処理やソース変換やソース出力などが実装できなければならない。GLRのような先進的なパースアルゴリズムとシンボルテーブルを組み合わせてソースコードを変換する方法を利用すればあらゆるC++ツールを開発できる。

互換性

その言語文法の複雑さゆえ、C++規格に準拠したコンパイラを開発するのは一般的に難しい。20世紀末から何年にも渡りC++に部分的に準拠した様々なコンパイラが作られ、テンプレートの部分特殊化などの部分で実装にばらつきがあった。中でも、テンプレートの宣言と実装を分離できるようにするためのexportは問題のキーワードの一つだった。exportを定義したC++98規格がリリースされてから5年後の2003年前半にComeau C/C++が初めてexportを実装した。2004年にBorland C++ Builder Xexportを実装した。これらのコンパイラはいずれもEDGのフロントエンドをベースにしていた。大半のコンパイラで実装されていないexportは多くのC++関連書籍(例えば"Beginning ANSI C++", Ivor Horton著)にサンプルが記されているが、exportが記載されていることによる問題は特に指摘されていない。GCCをはじめとするその他のコンパイラでは全くサポートしていない。Herb SutterはC++の標準規格からexportを削除することを推奨していたが[23]、C++98では最終的にこれを残す決定がなされた[24]。結局、C++11では実装の少なさ・困難さを理由に削除された。

コンパイラ開発者の裁量で決められる範囲を確保するため、C++標準化委員会は名前修飾例外処理などの実装に依存する機能の実装方法を決定しないことに決めた。この決定の問題は、コンパイラが異なるとオブジェクトファイルの互換性が保証されない点である。特定の機種やOSでコンパイラの互換性を持たせ、バイナリレベルでのコード再利用性を高めようとするABI[25]のような非標準の規格もあり、一部のコンパイラではこうした準規格を採用している。

2015年現在のメジャーなC++コンパイラ(gcc,Clang,Intel C++ Compiler,Microsoft Visual C++など)の最新版はC++11規格にほぼ準拠しており、特にClangは2013年4月時点で全機能を実装完了した [26] [27]。ただしマイナーアップデートとなるC++14を含めると、処理系間でのばらつきは依然として存在する。

C言語との互換性

C++は基本的にC言語の上位互換であるが、厳密には異なる[28]。C言語で記述された大半のプログラムはC++でコンパイルできるように簡単に修正できるが、C言語では正当でもC++では不正になる部分や、C++とは動作が異なる部分が若干存在する。

例えば、C言語では汎用ポインタvoid*は他の型へのポインタに暗黙的に変換できるが、C++ではキャスト演算子によって変換を明示する必要がある。またC++ではnewclassといった数多くの新しいキーワードが追加されたが、移植の際に元のC言語のプログラムでそれらが識別子(例えば変数名)として使われていると、問題になる。

C言語の標準規格であるC99やその後継C11ではこうした非互換性の一部が解決されており、//形式のコメントや宣言とコードの混在といったC++の機能がC言語でサポートされている。その一方でC99では、可変長配列、複素数型の組み込み変数、指示初期化子、複合リテラルといった、C++でサポートしていない数多くの新機能が追加された[29]。C99で追加された新機能の一部はC++11に反映され、次期C++1yに対してもC99やC11との互換性を向上される提案が行われている。また、可変長配列や複素数型などのC99に追加された機能の一部はC11でオプションとなった[30]

C++で書かれた関数をC言語で書かれたプログラムから呼び出す、あるいはその逆を行なう場合など、C言語のコードとC++のコードを混在させるためにはCリンケージを利用する必要があり、関数をextern "C"で個別に修飾するか、extern "C" { ... }のブロックの中で宣言しなければならない。また、関数引数や戻り値などのインターフェイスはC言語互換形式に合わせる必要がある。Cリンケージを利用した関数については、C++名前修飾がされず、名前修飾に依存している関数オーバーロード機能は利用できない。

C/C++の相互運用性が確保されていることで、慣れ親しんだC言語標準ライブラリ関数の大半をC++でもそのまま利用し続けることができるということはC++の大きなメリットのひとつである。

主なC++処理系

脚注

[ヘルプ]
  1. ^ 『プログラミング言語C++』第4版、pp.12-13。
  2. ^ 『C++の設計と進化』、pp.152-153。
  3. ^ 『プログラミング言語C++』第4版、p.11。
  4. ^ Bjarne Stroustrup's FAQ - When was C++ invented?” (English). 2006年5月30日閲覧。
  5. ^ Bjarne Stroustrup; Margaret A. Ellis (1990). The Annotated C++ Reference Manual. Addison-Wesley Professional. ISBN 978-0201514599. 
  6. ^ Bjarne Stroustrup; Margaret A. Ellis 『The Annotated C++ Reference Manual』 足立高徳、小山裕司、シイエム・シイ、2001年ISBN 978-4901280396
  7. ^ ISO/IEC 14882:1998
  8. ^ ISO/IEC 14882:2003
  9. ^ ISO/IEC TR 19768:2007
  10. ^ ISO/IEC 14882:2011
  11. ^ ISO/IEC 14882:2014
  12. ^ https://www.iso.org/standard/68564.html
  13. ^ We have C++14! : Standard C++
  14. ^ Koenig, Andrew; Bjarne Stroustrup (1989年5月11日). “C++: as close as possible to C – but no closer (PDF)” (英語). 2016年11月19日閲覧。
  15. ^ Stroustrup, Bjarne. “Stroustrup: FAQ Is C a subset of C++?” (英語). 2016年11月19日閲覧。
  16. ^ 『C++の設計と進化』、pp.124-125。
  17. ^ Bjarne Stroustrup (2000年). The C++ Programming Language (Special Edition ed.). Addison-Wesley. pp. 46. ISBN 0-201-70073-5. 
  18. ^ Open issues for The C++ Programming Language (3rd Edition) - このコードはストロヴストルップ自身による訂正文からの引用(633ページ)。std::endl'\n'に改めている。またmain関数がデフォルトで0を返す件についてはwww.research.att.com及びwww.delorie.com/djgpp/ を参照されたし。このデフォルト仕様はmain関数のみであり他の関数にはない。
  19. ^ Sutter, Herb; Alexandrescu, Andrei (2004). C++ Coding Standards: 101 Rules, Guidelines, and Best Practices. Addison-Wesley. 
  20. ^ Henricson, Mats; Nyquist, Erik (1997). Industrial Strength C++. Prentice Hall. ISBN ISBN 0-13-120965-5. 
  21. ^ Stroustrup, Bjarne (2000). The C++ Programming Language (Special Edition ed.). Addison-Wesley. p. 310. ISBN 0-201-70073-5. "A virtual member function is sometimes called a method. (仮想関数のことをメソッドと呼ぶ場合がある)" 
  22. ^ Andrew Birkett. “Parsing C++ at nobugs.org”. Nobugs.org. 2009年7月3日閲覧。
  23. ^ Why We Can’t Afford Export (PDF, 266 KB)
  24. ^ Minutes of J16 Meeting No. 36/WG21 Meeting No. 31, April 7-11, 2003” (2003年4月25日). 2006年9月4日閲覧。
  25. ^ C++ ABI”. 2006年5月30日閲覧。
  26. ^ 後藤大地 (2013年4月22日). “LLVM Clang、C++11にフル対応”. マイナビニュース. 2013年9月7日閲覧。
  27. ^ GCC 4.8.1 - C++11全実装バージョン”. Faith and Brave - C++で遊ぼう (2013年6月7日). 2013年9月7日閲覧。
  28. ^ Bjarne Stroustrup's FAQ - Is C a subset of C++?”. 2008年1月18日閲覧。
  29. ^ C9X -- The New C Standard”. 2008年12月27日閲覧。
  30. ^ C言語の最新事情を知る: C99の仕様 - Build Insider

参考文献

関連項目

外部リンク


著作権マーク

(C# から転送)

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2018/06/30 19:05 UTC 版)

Jump to navigation Jump to search
この項目には、一部のコンピュータや閲覧ソフトで表示できない文字(丸の中にCなど、丸付き文字)が含まれています詳細
著作権マーク

著作権マーク(ちょさくけんマーク)またはコピーライトマーク(copyright mark)とは、大文字Cを丸で囲んだ記号(©)であり、音声録音[1]以外の作品の著作権表示に使用される記号である。

この記号の使用は、アメリカ合衆国の著作権法英語版[2]や、国際的には万国著作権条約[3]に規定されている。ただし、ベルヌ条約の下では、ほとんどの国で著作権マークによる明示をしなくても著作権を得ることができる。例えば、アメリカ合衆国は1989年3月1日に著作権表示の要件を廃止したが、それ以前に発表された作品では、著作権マークが表示されているか否かは、法的に重要である。

歴史

作品の著作権を示す記号の先駆は、1670年代のスコットランドの年鑑に見られる。その書籍には、その真正性を示すための紋章が印刷されていた[4]

著作権表示は、アメリカ合衆国の1802年の著作権法によって初めて規定された[5]。それは、"Entered according to act of Congress, in the year         , by A. B., in the office of the Librarian of Congress, at Washington."(        年、ワシントンにある議会図書館司書の事務所にA. B.が議会制定法英語版に従って記入した。)のように長いものであった。一般に、著作権表示は著作権で保護された作品自体に表示されていなければならなかったが、絵画のような美術作品の場合には、美術作品が設置されるべき物体の表面に刻印されていてもよい[6]。1874年、"Copyright, 18        , by A. B."と大幅に短縮された表示でも可能とするよう著作権法が改正された[7]

著作権マーク©は、1909年の著作権法(Copyright Act of 1909)第18条[8]で導入され、最初は絵画、グラフィック、彫刻作品にのみ適用された[9]。1954年、出版された著作物にもこの記号の使用が拡大された[9][10]

1909年の著作権法は、既存の著作権法を完全に書き直し、改訂することを意図していた。この法案の草案で最初に提案されたように、著作権の保護を受けるためには、芸術作品そのものに"copyright"という文言またはその認可された略語を入れることが要求された。この芸術作品には絵画も含まれていたが、額縁は取り外し可能であることから議論が起こった。1905年と1906年に行われた法案についての著作権保持者間の会議では、芸術家組織の代表者はこの要件に反対し、作品自体に作者名以外の文言を書くことを望まなかった。妥協案として、作品自体に書かれる作者名の横に、比較的邪魔されない記号(大文字のCを丸で囲んだ記号)を書き足す案が出された[11]。実際に、ハーバート・パトナム議会図書館司書の指導の下、著作権委員会がまとめた1906年の議会に提出された法案は、特別な著作権マーク、丸で囲まれた文字Cを、"copyright"やその略語"copr."の代わりに使用することができるが、それは芸術作品などの限られたカテゴリについてのみ使用でき、通常の書籍や定期刊行物は含まれないとしている[12]。1909年の著作権法は、1946年に合衆国法典第17号に組み込まれた時点でも変更されなかった。1954年の改正で、全ての著作物について記号©が"Copyright"または"Copr."の代替として許可された[10]

現在のアメリカ合衆国を含むベルヌ条約の加盟国では、著作権を確立するのに著作権表示を行う必要はなく、著作物の作成時に自動的に著作権が確立する[13]。アメリカ合衆国は1989年にベルヌ条約に加盟した。ほとんどの国がベルヌ条約に加盟しているため、著作権を得るために著作権表示を必要としない。

アメリカ合衆国の著作権表示

アメリカ合衆国では、1989年3月1日以前には以下の形式の著作権表示が必要とされた[14]

  • ©記号、または"Copyright"(あるいはその略語の"Copr.")という文言
  • その作品の最初の出版年
  • 名前、その省略形、または一般に知られている名称のいずれかによる著作権の所有者の識別

例えば、2011年に初めて出版された作品の場合は、以下のようになる。

© 2011 John Smith

この表示は、かつてはアメリカ合衆国で著作権保護を受けるためには必要だったが、ベルヌ条約に加盟している国では必要ない.[13]。アメリカ合衆国は1989年3月1日にベルヌ条約に加盟した[15]

デジタル表現

タイプライターASCIIベースのコンピュータシステムでは、この記号は長らく利用できなかったため、(C)と表現するのが一般的だった。

Unicodeでは、U+00A9 © copyright sign (HTML: &#169; &copy;)として割り当てられている[16]。Unicodeには他にU+24B8 circled latin capital letter c (HTML: &#9400;)とU+24D2 circled latin small letter c (HTML: &#9426;)もある[17]。これらは、著作権マークがフォントや文字セットで利用できない場合(一部の朝鮮語コードページなど)に代替として使用されることがある。

Windowsでは、Altを押しながら0 1 6 9を押すことで入力できる。Macintoshでは、オプションキーを押しながらgを押すことで入力できる。Linuxでは、compose O Cコンポーズキー英語版シーケンスで入力できる。

関連する記号

  • レコード原盤権マーク英語版(℗) - 大文字のPを丸で囲んだ記号であり、録音の原盤権を指定するために使用される[18]
  • コピーレフトマーク - 著作権マークを左右反転させた記号であり、コピーレフトのシンボルとして使用される。法的には意味を持たない[19]
  • 登録商標マーク(®) - 大文字のRを丸で囲んだ記号であり、公式の事務所に登録されている商標(登録商標)を指定するために使用される。
  • マスクワークマーク(Ⓜ) - 大文字のMを丸で囲んだ記号であり、マスクワーク英語版(半導体集積回路の回路配置)の表示に使用される[20]

関連項目

脚注

  1. ^ これはレコード原盤権マーク英語版(℗)で示される。
  2. ^ 合衆国法典第17編第401条 17 U.S.C. § 401
  3. ^ Universal Copyright Convention, Article III, §1. (Paris text, July 24, 1971.)
  4. ^ Mann, Alastair J.; Kretschmer, Martin; Bently, Lionel (2010). “A Mongrel of Early Modern Copyright”. In Deazley, Ronan. Privilege and property: essays on the history of copyright. Open Book Publishers. ISBN 978-1-906924-18-8. 
  5. ^ Copyright Law Revision Study Number 7, page 6”. 合衆国著作権局. 合衆国政府印刷局. 2013年6月14日閲覧。
  6. ^ Copyright Act of 1870, §97.
  7. ^ 1874 Amendment to the Copyright Act of 1870, §1.
  8. ^ Copyright Act of 1909, §18
  9. ^ a b Copyright Law Revision: Study 7: Notice of Copyright. Washington, D.C.: 合衆国政府印刷局. (1960). p. 11. http://www.copyright.gov/history/studies/study7.pdf. 
  10. ^ a b An Act to amend title 17, United States Code, entitled "Copyrights", Pub.L. 83–743, 68 Stat. 1030 1954年8月31日制定.
  11. ^ Arguments before the Committees on Patents of the Senate and House of Representatives, conjointly, on the bills S. 6330 and H.R. 19853, to amend and consolidate the acts respecting copyright. June 6–9, 1906. 合衆国政府印刷局. (1906). p. 68. https://books.google.com/books?id=ZlA-AAAAYAAJ&pg=PA68&cd=2#v=onepage. 
  12. ^ “Proposed Copyright Legislation”. The Writer XVIII (6): 87. (June 1906). https://books.google.com/books?id=fEhppVLGxR0C&pg=PA87&dq=%22proposed+copyright+legislation%22&lr=&ei=5XL3StfCJKO8zgSt2dW5Aw#v=onepage&q=%22proposed+copyright+legislation%22. 
  13. ^ a b Molotsky, Irvin (1988年10月21日). “Senate Approves Joining Copyright Convention”. The New York Times. https://www.nytimes.com/1988/10/21/arts/senate-approves-joining-copyright-convention.html 2011年9月22日閲覧。 
  14. ^ 合衆国法典第17編第401(b)条 17 U.S.C. § 401(b)
  15. ^ Circular 38A: International Copyright Relations of the United States. 合衆国著作権局. (2014). p. 2. http://copyright.gov/circs/circ38a.pdf 2015年3月5日閲覧。. 
  16. ^ https://www.unicode.org/charts/PDF/U0080.pdf
  17. ^ https://www.unicode.org/charts/PDF/U2460.pdf
  18. ^ Stephen Fishman (2010), “The Copyright Symbol”, The Public Domain, p. 356, ISBN 978-1-4133-1205-8, https://books.google.co.uk/books?id=4WKTNLRtUAsC&pg=PA356 
  19. ^ Hall, G. Brent (2008). Open Source Approaches in Spatial Data Handling. Springer. p. 29. ISBN 3-540-74830-X.  Additional 978-3-540-74830-4. See Open Source Approaches in Spatial Data Handling - Google ブックス, page 29
  20. ^ Federal Statutory Protection for Mask Works (Copyright Circular 100)”. 合衆国著作権局. pp. 5 (2012年9月). 2014年3月22日閲覧。

C Sharp

(C# から転送)

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2018/07/31 15:06 UTC 版)

Jump to navigation Jump to search
本来の表記は「C#」です。この記事に付けられた題名は、技術的な制限により、記事名の制約から不正確なものとなっています。
C#
C#のロゴマーク。テキスト上では#と代替表記されるが、正式には♯と描く。
C#のロゴ
パラダイム 構造化, 命令型, オブジェクト指向, 関数型, イベント駆動型, ジェネリック, リフレクション, 並行計算
登場時期 2000年 (2000)
設計者 マイクロソフトアンダース・ヘルスバーグ率いるチーム)
開発者 マイクロソフト
最新リリース 7.3/ 2018年5月7日(2か月前) (2018-05-07
型付け 強い静的型付け(4.0から動的型導入)
主な処理系 CLR, Mono
方言 1.0, 1.5, 2.0 (ECMA), 3.0, 3.5, 4.0, 5.0, 6.0, 7.0
影響を受けた言語 C++, Delphi, Eiffel, Java, LISP
影響を与えた言語 D言語, F#, Java, Nemerle, Vala
プラットフォーム Windows, macOS, Linuxなど
ライセンス Apacheライセンス (Roslyn)
テンプレートを表示

C#(シーシャープ)は、アンダース・ヘルスバーグが設計(デザイン)したプログラミング言語であり、構文(syntax)は(名前にもある通り)C言語や、C言語風に構文が設計されたC++Javaなどの影響があるが、構文以外についてはヘルスバーグが以前の所属であるBorlandで設計したDelphiからの影響がある[1]

Microsoftによる謳い文句としては、マルチパラダイムプログラミング言語、強い型付け命令型宣言型手続き型関数型ジェネリックオブジェクト指向の要素を持つ、などといった点が強調されている。

CLIといった周辺も含め、Microsoftのフレームワーク「.NET Framework」の一部である他、VJ++で「非互換なJava」をJavaに持ち込もうとしたような以前のMicrosoftとは異なり、その多くの[2]仕様を積極的に公開し標準化機構に託して自由な利用を許す(ECMA-334、ISO/IEC 23270:2003、JIS X 3015)など、同社の姿勢の変化があらわれている一面でもある(実際に「Mono」という、フリーソフトウェアの定義に合致したライセンスの、コミュニティによる実装がある)。

目次

概要

開発にはボーランド社のTurbo PascalDelphiを開発したアンダース・ヘルスバーグを筆頭に多数のDelphi開発陣が参加している。

C#は共通言語基盤共通言語ランタイムなど)が解釈する共通中間言語コンパイルされて実行される。

自動ボックス化デリゲートプロパティインデクサカスタム属性ポインタ演算操作、構造体(値型オブジェクト)、多次元配列可変長引数、などの機能を持つ。また、Javaと同様に大規模ライブラリプロセッサ・アーキテクチャに依存しない実行形態、ガベージコレクションJITコンパイルによる実行の高速化、などが実現されている(もっともこれらはC#の機能というより.NET Frameworkによるものである)。

.NET構想における中心的な開発言語であり、XML WebサービスASP.NETの記述にも使用される。他の.NET系の言語でも記述可能だが、生産性・機能においてC#が最も優れるとされる。マイクロソフトの統合開発環境では、Microsoft Visual C#がC#に対応している。

共通言語仕様のCLSによって、他のCLS準拠の言語(Visual Basic .NETVisual C++ (C++/CLI)など)と相互に連携することができる。

リリース時期

  • 1.0  2002年4月
    • 1.1  2003年5月
  • 2.0  2005年12月
  • 3.0  2007年12月
  • 4.0  2010年4月
  • 5.0  2012年8月
  • 6.0  2015年7月
  • 7.0  2017年3月
    • 7.1  2017年8月
    • 7.2  2017年12月

言語仕様

さまざまな意味において、基盤であるCLIの機能をもっとも反映している言語であるといえる。C#にある組み込み型のほとんどは、CLIフレームワークに実装されている値型と対応している。しかし、C#の言語仕様はコンパイラのコード生成については何も言及していない。つまり、CLRに対応しなければならないとか、共通中間言語 (CIL) などの特定のフォーマットのコードを生成しなければならないとかいうことは述べられていない。そのため、理論的にはC++FORTRANのように環境依存のマシン語を生成することも可能である。しかし、現在存在するすべてのC#コンパイラはCLIをターゲットにしている。

CやC++からの改良点

C#では、CやC++と比較してさまざまな制限や改良が加えられている。その例を次に挙げる。

構文や構文以外の改良点

  • 外のブロックで宣言した変数名を、内のブロックで再宣言しては(シャドウしては)いけない。これは便利なこともあれば、混乱や曖昧のもとと主張されることもあるが、C#では禁止されている。
  • C#にはブール型boolが存在し、whileifのように条件をとるステートメントには、bool型の式を与えなければならない。C言語では、ブール型が無くint型(の、0を偽とし、非0を真とする)に兼用させた上、(ヌルポインタを偽とみなすこととするといろいろと便利だった、ということもあり)ポインタでもwhile文やif文に与える式にできる、という仕様としていた。これは便利なこともあったが、ミスが見逃されることもあった。C#ではミスを防止するため[要出典]に、そのような仕様ではなくブール型を独立させ、またブール型をストリクトに要求する場所を多くしている。
  • switch文で、基本型のみならず、定数文字列によって分岐することができる。

ポインタとメモリ管理

  • ポインタをサポートする。ポインタはunsafeスコープ内のみで使用することができ、適切な権限をもつプログラムのみがunsafeとマークされたコードを実行することができる。オブジェクトへのアクセスの大部分は管理された安全な参照によってなされ、大部分の算術演算はオーバフローのチェックがなされる。unsafeポインタは値型や文字列を指すことができる。セーフコードでは、必ずしもそうする必要はないものの、IntPtr型を通してポインタをやりとりすることができる。
  • マネージドなメモリを明示的に解放する方法は存在せず、参照されなくなったメモリはガベージコレクタによって自動的に解放される。ガベージコレクタは、メモリの解放忘れによって起こるメモリリークを解消する。C#は、データベース接続のようなアンマネージドなリソースに対しても明示的に制御する方法を提供している。これはIDisposableインタフェースとusingステートメントによってなされる。

名前空間とオブジェクト指向な型システム

  • グローバル変数やグローバルメソッドは存在しない。すべてのメソッドとメンバはクラスの一部として宣言されなければならない。
  • Cのprintf()関数のように関数をグローバルで公開するのではなく、すべての関数はクラス内で宣言されなければならない。ほとんどの場合クラスは名前の衝突を避けるために名前空間に所属する。
  • 名前空間は階層構造をもつ。つまり、名前空間は他の名前空間の中に宣言することができる。
  • 原始型を含めたすべての型は、objectクラスの派生クラスである。つまりobjectクラスのもつすべてのプロパティやメソッドを継承する。例えば、すべての型はToString()メソッドをもつ。
  • クラスは複数のインタフェースを実装することができるが、多重継承はサポートされない。
  • C#はC++に比べて型安全である。既定の暗黙変換は、整数の範囲を広げる変換や、派生クラスから基底クラスへの変換といった、安全な変換のみに限定される。これは、コンパイル時、JITコンパイル時、そして一部の動的なケースでは実行時に強制される。ブール型と整数型、列挙型と整数型、の間は暗黙変換はできない。暗黙変換をユーザ定義する際は、明示的にそのように指定しなければならない。これはC++のコンストラクタとは違った仕様である。
  • 列挙型のメンバは、列挙型の名前空間の中におかれる。また、列挙型の定数名を取得することができる。さらに、列挙型の定数名から動的に定数値を得ることができる。
  • プロパティと呼ばれるアクセサは、C++におけるメンバフィールドのような構文でオブジェクトにアクセスすることができる。C++では、publicとしてメンバを宣言することでメンバを読むことも変更することもできるようになるが、C#ではプロパティによってメンバアクセスやデータの正当性チェックを制御することができる。

C# 2.0からの仕様

部分型

部分型 (Partial Type) が導入された。以下のようにクラスや構造体の宣言にpartial修飾子をつけることで、その宣言を分割することができる。

partial class MyClass { int a; }
partial class MyClass { int b; }

これは以下と同義である:

class MyClass { int a; int b; }

これによって、巨大なクラスを分割したり、自動生成されたコードを分離したりすることができる。partial 修飾子はすべての宣言につける必要がある。

ジェネリクス

ジェネリクスが導入された。これは.NET Framework 2.0の機能である。クラス、構造体、インタフェース、デリゲート、メソッドに対して適用することができる。.NETのGenericsはC++のテンプレート、あるいはJavaにおけるそれとも異なるもので、コンパイルによってではなく実行時にランタイムによって特殊化される。これによって異なる言語間の運用を可能にし、リフレクションによって型パラメタに関する情報を取得することができる。また、where節によって型パラメタに制約を与えることができる。一方、C++のように型パラメタとしてを指定することはできない。なお、ジェネリックメソッドの呼び出し時に引数によって型パラメタが推論できる場合、型パラメタの指定は省略できる。

静的クラス

静的クラスが導入された。static属性をクラスの宣言につけることで、クラスはインスタンス化できなくなり、静的なメンバしか持つことができなくなる。

yieldキーワード

yieldキーワードによるコルーチンを使うことで、イテレータを楽に実装できるようになった。

匿名デリゲート

クロージャの機能を提供する匿名デリゲートが導入された。

プロパティに対する個別のアクセス制御

プロパティのget もしくは setアクセサのどちらかにアクセス修飾子を指定することでアクセス制御が別個にできるようになった。次の例では、getアクセサはpublicsetアクセサはprivateである。

public class MyClass
{
  private string status = string.Empty;
  public string Status
  {
    get { return status; }
    private set { status = value; }
  }
}

Null許容型とnull結合演算子

nullを保持できる値型、Nullableが導入された。

int? i = 512;
i = null;

int? j = i + 500; //jはnullとなる。nullとの演算の結果はnullになる。

int?Nullable<int>糖衣構文である。また、nullを保持しているNull許容型のインスタンスをボックス化しようとすると、単に空参照 (null) に変換される[3]

int? x = null;
object o = x;
System.Console.WriteLine(o == null); //Trueが出力される

また、null結合演算子 (??)が導入された。これは、nullでない最初の値を返す。

object obj1 = null;
object obj2 = new object();
object obj3 = new object();
return obj1 ?? obj2 ?? obj3; // obj2 を返す

この演算子は主にNullable型を非Nullable型に代入するときに使われる。

int? i = null;
int j = i ?? -1; // nullをint型に代入することはできない

C# 3.0からの仕様

varキーワード

var キーワードが導入され、型推論を利用したローカル変数の宣言ができるようになった。

var s = "foo";
// 上の文は右辺が string 型であるため、次のように解釈される:
string s = "foo";
// 以下に挙げる文は誤りである(コンパイルエラーとなる):
var v; // 初期化式を欠いている (型を推論する対象が存在しない)
var v = null; // 型が推論できない (曖昧である)

拡張メソッド

拡張メソッドが導入された。既存のクラスを継承して新たなクラスを定義することなく新たなインスタンスメソッドを追加定義することができる。具体的には、独自の静的クラス内に this 修飾子をつけた、拡張メソッドを追加する対象の型の引数を最初に持つメソッドを定義することによって、通常の静的メソッドとしての呼び出しの他に指定した型のインスタンスメソッドとしての呼び出しを行うことができるメソッドを作ることができる。以下に例を挙げる:

public static class StringUtil
{
  public static string Repeat(this string str, int count)
  {
    var array = new string[count];
    for (var i = 0; i < count; ++i) array[i] = str;
    return string.Concat(array);
  }
}

この例は string 型に、文字列 (string 型のインスタンス)を指定した回数繰り返したものを返すメソッド Repeat を追加している。このメソッドは、以下のように呼び出すことができる:

// 静的メソッドとしての呼び出し
StringUtil.Repeat("foo", 4);
// 拡張メソッドとしての呼び出し
"foo".Repeat(4);
// (どちらの例も "foofoofoofoo" を返す)

また、列挙型やインターフェースなど本来メソッドの実装を持ち得ない型に、見かけ上インスタンスメソッドを追加することも可能である。以下に例を挙げる:

public enum Way
{
  None, Left, Right, Up, Down
}

public static EnumUtil
{
  public static Way Reverse(this Way src)
  {
    switch(src)
    {
      case Way.Left:  return Way.Right;
      case Way.Right: return Way.Left;
      case Way.Up:    return Way.Down;
      case Way.Down:  return Way.Up;
      default : return Way.None;
    }
  }
}

このメソッドは以下のように呼び出すことができる:

Way l = Way.Left;
Way r = l.Reverse(); // Way.Right

部分メソッド

部分メソッドが導入された。部分型(partial 型)内で定義された private で、かつ戻り値が void のメソッドに partial 修飾子をつけることでメソッドの宣言と定義を分離させることができる。定義されていない部分メソッドは何も行わず、何らエラーを発生させることもない。例えば:

partial class Class
{
  partial void DebugOutput(string message);
  
  void Method()
  {
    DebugOutput("Some message");
    Console.WriteLine("Did something.");
  }
}

上のコードにおいて Method() を呼び出すと、Did something. と表示されるだけだが、ここで以下のコード:

partial class Class
{
  partial void DebugOutput(string message)
  {
    Console.Write("[DEBUG: {0}] ", message);
  }
}

を追加した上で Method() を呼び出すと、[DEBUG: Some message] Did something. と表示される。

ラムダ式

匿名メソッドをより簡略化した記法として、ラムダ式が導入された。この名前はラムダ計算に由来する。

以下の匿名メソッド

// iを変数としてi+1を返すメソッド
delegate (int i) { return i + 1; }

は、ラムダ式を使って次のように記述できる:

(int i) => i + 1; /* 式形式のラムダ */
//或いは:
(int i) => { return i + 1; }; /* ステートメント形式のラムダ */

ラムダ式は匿名メソッドと同様に扱えるが、式形式のラムダがExpression<TDelegate>型として扱われた場合のみ匿名メソッドとして扱われず、コンパイラによって式木を構築するコードに変換される。匿名デリゲートが実行前にコンパイルされたCILを保持するのに対し、式木はCILに実行時コンパイル可能であるDOMのような式の木構造そのものを保持する。これはLINQクエリをSQLクエリなどに変換する際に役立つ。

以下は、3つの任意の名前の変数、整数、括弧、及び四則演算子のみで構成された式を逆ポーランド記法に変換する汎用的なコードである:

public static string ToRPN(Expression<Func<int, int, int, int>> expression)
{
  return Parse((BinaryExpression) expression.Body).TrimEnd(' ');
}

private static string Parse(BinaryExpression expr)
{
  string str = "";
  
  if (expr.Left is BinaryExpression)
  {
    str += Parse((BinaryExpression) expr.Left);
  }
  else if (expr.Left is ParameterExpression)
  {
    str += ((ParameterExpression) expr.Left).Name + " ";
  }
  else if (expr.Left is ConstantExpression)
  {
    str += ((ConstantExpression) expr.Left).Value + " ";
  }

  if (expr.Right is BinaryExpression)
  {
    str += Parse((BinaryExpression) expr.Right);
  }
  else if (expr.Right is ParameterExpression)
  {
    str += ((ParameterExpression) expr.Right).Name + " ";
  }
  else if (expr.Right is ConstantExpression)
  {
    str += ((ConstantExpression) expr.Right).Value + " ";
  }
  
  return str + expr.NodeType.ToString()
    .Replace("Add", "+")
    .Replace("Subtract", "-")
    .Replace("Multiply", "*")
    .Replace("Divide", "/")
    + " ";
}

// 呼び出し例:
ToRPN((x, y, z) => (x + 1) * ((y - 2) / z)); // "x 1 + y 2 - z / *" を返す

オブジェクト初期化の簡略化

オブジェクトの初期化が式として簡潔に記述できるようになった。

var p = new Point { X = 640, Y = 480 };
// 上の文は次のように解釈される:
Point __p = new Point();
__p.X = 640;
__p.Y = 480;
Point p = __p;

また、コレクションの初期化も同様に簡潔に記述できるようになった。

var l = new List<int> {1, 2, 3};
var d = new Dictionary<string, int> {{"a", 1}, {"b", 2}, {"c", 3}};
// 上の文は次のように解釈される:
List<int> __l = new List<int>();
__l.Add(1);
__l.Add(2);
__l.Add(3);
List<int> l = __l;
Dictionary<string, int> __d = new Dictionary<string, int>();
__d.Add("a", 1);
__d.Add("b", 2);
__d.Add("c", 3);
Dictionary<string, int> d = __d;

但し、上のコードでは匿名の変数に便宜的に __p、__l、__d と命名している。実際はプログラマはこの変数にアクセスすることはできない。

自動実装プロパティ

プロパティをより簡潔に記述するための自動実装プロパティが導入された。プロパティの定義に get; set; と記述することで、プロパティの値を保持するための匿名のフィールド(プログラマは直接参照することはできない)と、そのフィールドにアクセスするためのアクセサが暗黙に定義される。また、C# 5.0 までは get;set;のどちらか片方だけを記述することは出来なかったが、C# 6.0 からは get; のみが可能。以下のコード:

public int Value { get; set; }

は、以下のようなコードに相当する動作をする:

private int __value;
public int Value
{
  get { return __value; }
  set { __value = value; }
}

但し、上のコードでは匿名のフィールドに便宜的に __value と命名している。実際はプログラマはこのフィールドにアクセスすることはできない。

匿名型

一時的に使用される型を簡単に定義するための匿名型が導入された。以下に例を挙げる:

new { Name = "John Doe", Age = 20 }

上の式は、以下の内容のクラスを暗黙に定義する。定義されたクラスは匿名であるが故にプログラマは参照できない。

public string Name { get; }
public int Age { get; }

同じ型、同じ名前のプロパティを同じ順序で並べた匿名型は同じであることが保証されている。即ち、以下のコード:

var her = new { Name = "Jane Doe", Age = 20 }
var him = new { Name = "John Doe", Age = 20 }

において、her.GetType() == him.GetType()true である。

配列宣言の型省略

new キーワードを用いた配列の宣言の際、型を省略できるようになった。匿名型の配列を宣言する際に威力を発揮する。

var a = new[] {"foo", "bar", null};
// 上の文は次のように解釈される:
string[] a = new string[] {"foo", "bar", null};
// 以下の文:
var a = new[] {"foo", "bar", 123};
// は次のように解釈されることなく、誤りとなる:
object[] a = new object[] {"foo", "bar", 123};

クエリ式

LINQ をサポートするために、クエリ式が導入された。これは SQL の構文に類似しており、最終的に通常のメソッド呼び出しに変換されるものである。以下に例を示す:

var passedStudents =
  from s in students
  where s.MathScore + s.MusicScore + s.EnglishScore > 200
  select s.Name;

上のコードは以下のように変換される:

var passedStudents = students
  .Where(s => s.MathScore + s.MusicScore + s.EnglishScore > 200)
  .Select(s => s.Name);

C# 3.0で追加された構文の多くは式であるため、より巨大な式(当然クエリ式も含まれる)の一部として組み込むことができる。旧来複数の文に分けたり、作業用の変数を用意して記述していたコードを単独の式としてより簡潔に記述できる可能性がある。

出井秀行著の『実戦で役立つ C#プログラミングのイディオム/定石&パターン』(技術評論社、2017年)という書籍ではクエリ構文よりメソッド構文を推奨しており、クエリ構文ではLINQの全ての機能を使用できるわけではないこと、メソッド呼び出しは処理を連続して読める可読性があること、メソッド呼び出しであればMicrosoft Visual Studioの強力なインテリセンスが利用できることを理由に、著者はクエリ構文をほとんど使用していないと記している。

C# 4.0からの仕様

dynamicキーワード

dynamicキーワードが導入され、動的型付け変数を定義できるようになった。dynamic型として宣言されたオブジェクトに対する操作のバインドは実行時まで遅延される。

// xはint型と推論される:
var x = 1; 
// yはdynamic型として扱われる:
dynamic y = 2; 

public dynamic GetValue(dynamic obj)
{
  // objにValueが定義されていなくとも、コンパイルエラーとはならない:
  return obj.Value;
}

オプション引数・名前付き引数

VBC++に実装されているオプション引数・名前付き引数が、C#でも利用できるようになった。

public void MethodA()
{
  // 第1引数と第2引数を指定、第3引数は未指定:
  Console.WriteLine("Ans: " + MethodB(1, 2));  // Ans: 3 … 1 + 2 + 0となっている

  // 第1引数と第3引数を指定、第2引数は未指定:
  Console.WriteLine("Ans: " + MethodB(A: 1, C: 3));  // Ans: 4 … 1 + 0 + 3となっている
}

// 引数が指定されなかった場合のデフォルト値を等号で結ぶ:
public int MethodB(int A = 0, int B = 0, int C = 0)
{
  return A + B + C;
}

ジェネリクスの共変性・反変性

ジェネリクスの型引数に対してin、out修飾子を指定することにより、ジェネリクスの共変性・反変性を指定できるようになった。

IEnumerable<string> x = new List<string> { "a", "b", "c" };
// IEnumerable<T>インターフェイスは型引数にout修飾子が指定されているため、共変である。
// したがって、C# 4.0では次の行はコンパイルエラーにならない
IEnumerable<object> y = x;

C# 5.0からの仕様

  • 非同期処理 (await, async)
  • Caller Info 属性
  • foreach の仕様変更

C# 6.0からの仕様

  • 自動実装プロパティの初期化子
  • get のみの自動実装プロパティおよびコンストラクタ代入
  • 静的 using ディレクティブ
  • Dictionary 初期化子
  • catch/finally での await
  • 例外フィルタ
  • Expression-bodied メンバ
  • null条件演算子
  • 文字列補間(テンプレート文字列)
  • nameof 演算子
  • #pragma
  • コレクションの初期化子での拡張メソッド
  • オーバーロード解決の改善

静的 using ディレクティブ

静的 using ディレクティブを利用することで、型名の指定無しに他クラスの静的メンバの呼び出しを行えるようになった。
利用するにはusing staticの後に完全修飾なクラス名を指定する。

using static System.Math;
// ↑ソースコードの上部で宣言
class Hogehoge {
    // System.Math.Pow() , System.Math.PI を修飾無しで呼び出す
    double area = Pow(radius, 2) * PI;
}

例外フィルタ

catchの後にwhenキーワードを使用することで、処理する例外を限定することができるようになった。

try {
    // ...
}
catch (AggregateException ex) when (ex.InnerException is ArgumentException) {
    // ...
}

C# 7.0からの仕様

  • 出力変数宣言
  • パターンマッチング (is 式/switch 文)
  • タプル (タプル記法/分解/値の破棄)
  • ローカル関数
  • 数値リテラルの改善(桁セパレータ/バイナリリテラル)
  • ref戻り値、ref変数
  • 非同期戻り値型の汎用化
  • Expression-bodied 機能の拡充(コンストラクタ/デストラクタ/get/set/add/remove)
  • Throw 式

出力変数宣言

out引数で値を受け取る場合、その場所で変数宣言可能となった。

total += int.TryParse("123", out var num) ? num : 0;

パターンマッチング

is 式の拡張

is式の構文が拡張され、型の後ろに変数名を宣言できるようになった。 拡張されたis式はマッチした場合に宣言した変数にキャストした値を代入し、さらにtrueと評価される。 マッチしなかった場合はfalseと評価され、宣言した変数は未初期化状態となる。

void CheckAndSquare(object obj) {
    // objの型チェックと同時にnumに値を代入する。
    if (obj is int num && num >= 0) {
        num = num * num;
    }
    else {
        num = 0;
    }
    // if文の条件セクションは、ifの外側と同じスコープ
    Console.WriteLine(num);
}
switch 文の拡張

switch文のマッチ方法が拡張され、caseラベルに従来の「定数パターン」に加え、新たに「型パターン」を指定できるようになった。 また、「型パターン」のcaseラベルでは、when句に条件を指定することができる。 「型パターン」を含むswitch文では、必ずしも条件が排他的でなくなったため、最初にマッチしたcaseラベルの処理が実行される。 [4]

void Decide(object obj) {
    switch (obj) {
        case int num when num < 0:
            Console.WriteLine($"{num}は負の数です。");
            break;
        case int num:
            Console.WriteLine($"{num}を二乗すると{num * num}です。");
            break;
        case "B":
            Console.WriteLine($"これはBです。");
            break;
        case string str when str.StartsWith("H"):
            Console.WriteLine($"{str}はHから始まる文字列です。");
            break;
        case string str:
            Console.WriteLine($"{str}は文字列です。");
            break;
        case null:
            Console.WriteLine($"nullです");
            break;
        default:
            Console.WriteLine("判別できませんでした");
            break;
    }
}

タプル

タプルのための軽量な構文が導入された。 従来のSystem.Tupleクラスとは別に、System.ValueTuple構造体が新しく追加された。

タプル記法

2個以上の要素を持つタプルのための記法が導入された。 引数リストと同様の形式で、タプルを記述できる。

// タプル記法
(int, string) tuple = (123, "Apple");
Console.WriteLine($"{tuple.Item1}個の{tuple.Item2}");
分解

多値戻り値を簡単に扱えるように、分解がサポートされた。

var tuple = (123, "Apple");
// 分解
(int quantity, string name) = tuple;
Console.WriteLine($"{quantity}個の{name}");

分解はタプルに限らない。Deconstruct()メソッドが定義されたクラスでも、分解を利用できる。

以下に、DateTime型に分解を導入する例を示す。

static class DateExt {
    public static void Deconstruct(this DateTime dateTime, out int year, out int month, out int day) {
        year = dateTime.Year;
        month = dateTime.Month;
        day = dateTime.Day;
    }
}

上記のコードでDateTime型にDeconstruct()拡張メソッドを定義し、

// 分解
(int year, int month, int day) = DateTime.Now;

のように左辺で3つの変数に値を受け取ることができる。

値の破棄

分解、out引数、パターンマッチングで、値の破棄を明示するために_が利用できるようになった。 破棄された値は、後で参照することはできない。

// 年と日は使わない
(_, int month, _) = DateTime.Now;

// 解析結果だけ取得し、変換された値は使わない
bool isNumeric = int.TryParse(str, out _);

switch (obj) {
    // string型で分岐するが、値は使わない
    case string _:
        // Do something.
        break;
}

ref戻り値、ref変数

refキーワードの使用方法が拡張された。
これによって、安全な参照の使い道が広がった。

ref戻り値

戻り値の型をrefで修飾することで、オブジェクトの参照を戻り値とすることができる。

// 二つの参照引数の内、値の大きいものの参照戻り値を返す
static ref int Max(ref int left,ref int right) {
    if(left >= right) {
        return ref left;
    }
    else {
        return ref right;
    }
}

変数の寿命は変わらないため、メソッド終了時に破棄されるローカル変数をref戻り値とすることはできない。

static int s_count = 1;

// メンバーの参照はref戻り値になる。
static ref int ReturnMember() {
    return ref s_count;
}
// ref引数はもちろんref戻り値になる。
static ref int ReturnRefParam(ref int something) {
    return ref something;
}
// ローカル変数をref戻り値とすることはできない。
// static ref int ReturnLocal() {
//     int x = 1;
//     return ref x;
// }
ref変数

ローカル変数の型をrefで修飾することで、参照を代入することができる。

// 参照戻り値を参照変数で受け取る
ref int max = ref Max(ref x, ref y);
// limitとmaxは同じ値を参照する
ref int limit = ref max;

C# 7.1からの仕様

非同期なMainメソッド

Mainメソッドの戻り値として、Task型、Task(int)型が認められた。

static Task Main()
static Task<int> Main()

default式

型推論可能な場面では、defaultの型指定は省略可能となった。

int number = default;
string name = default;

C# 7.2からの仕様

C#7.2で追加された仕様は以下の通り。 [5] [6]

値型の参照セマンティクス

値型におけるパフォーマンス向上を意図した複数の機能が追加された。

in参照渡し、ref readonly参照戻り値

引数にinを指定することで、読み取り専用参照渡しを指定できる。 また、戻り値にref readonlyを指定することで、読み取り専用参照戻り値を指定できる。

これにより、構造体のコピーを避けると共に、意図しない値の変更を抑止できる。

readonly構造体

構造体宣言時にreadonlyを指定することで、真の読み取り専用構造体を定義できる。 readonly構造体の全てのフィールドはreadonlyでなければならず、thisポインタも読み取り専用となる。

これにより、メンバーアクセス時の意図しない防御的コピーを抑止できる。

ref構造体

構造体宣言時にrefを指定することで、ヒープ領域へのコピーを防ぐ構造体がサポートされる。 ref構造体では、box化できない、配列を作成できない、型引数になることができない、など、ヒープ領域へのコピーを防ぐための厳しい制限がかかる。

この機能は、Span<T>のような構造体をサポートするために利用され、unsafe文脈以外でのstackallocの利用をも可能とする。

末尾以外の場所での名前付き引数

C#4.0で追加された名前付き引数が末尾以外でも利用できるようになった。

Hogehoge(name: "John", 17);

private protected アクセス修飾子

同一アセンブリ内、かつ、継承先からのアクセス許可を表すprivate protectedアクセス修飾子が追加された。

数値リテラルの改善

十六進リテラルの0x、二進リテラルの0bの直後のアンダースコアが認められた。

int bin = 0b_01_01;
int hex = 0x_AB_CD;

C# 7.3からの仕様

C#7.3では以下の仕様が追加された。 [7]

  • ジェネリック型制約の種類の追加
    • System.Enum, System.Delegate
    • unmanaged (文脈キーワード)
unsafe class MyGenericsClass<T1,T2,T3> 
    where T1 : System.Enum
    where T2 : System.Delegate
    where T3 : unmanaged {

    public MyGenericsClass(T1 enum1, T1 enum2, T2 func, T3 unmanagedValue) {
        if (enum1.HasFlag(enum2)) {
            func.DynamicInvoke();
        }
        else {
            T3* ptr = &unmanagedValue;
        }
    }
}
  • refローカル変数の再割り当て
  • stackalloc初期化子
  • Indexing movable fixed buffers
  • カスタムfixedステートメント
  • オーバーロード解決ルールの改善
  • 出力変数宣言の利用箇所の追加
class MyOutVar {
    // メンバー変数初期化子やコンストラクタ初期化子で出力変数宣言が可能
    readonly int x = int.TryParse("123", out var number) ? number : -1;
}
  • タプル同士の比較
(long, long) tuple = (1L, 2L);
// タプルのすべての要素間で == が比較可能
if (tuple == (1, 2)) { }
// 要素数が異なるタプル同士は比較できない。
//if (tuple == (1, 2, 3)) { }
  • バッキングフィールドに対するAttribute指定
// C#7.2までは無効な指定(コンパイル自体は可能。無視される)
// C#7.3からはバッキングフィールドに対するAttribute指定と見なされる
[field: NonSerialized]
public int MyProperty { get; set; }

実装

C#の言語仕様は標準化団体Ecma Internationalを通じて公開・標準化されており、第三者がマイクロソフトとは無関係にコンパイラや実行環境を実装することができる。 現段階で、C#コンパイラの実装は次の5つが知られている。

  • マイクロソフト製
    • Visual Studio 2015 以降で使用されている、.NETコンパイラプラットフォーム英語版(開発名Roslyn)。ApacheライセンスオープンソースプロジェクトでGitHubで公開されている[8]WindowsmacOSLinuxで動作する。C#のコンパイラはC#、VB.NETのコンパイラはVB.NETで実装されている。以前のコンパイラと比べて、リファクタリングやIDE、スクリプティングなどへの利用が可能なAPIが公開されており、コンパイラ以外への様々な応用が可能。
    • Visual Studio 2013 まで使われていた、マイクロソフトによるVisual C# コンパイラ。
    • 2006年のC# 2.0当時の、マイクロソフトによるShared Source Common Language Infrastructure。共通言語基盤 (CLI) とC#コンパイラがソースコードで公開されている。
  • Mono ProjectによるMono内の Mono Compiler Suite (mcs)。
  • 2012年まで開発されていた、DotGNU ProjectによるPortable.NET内の the C-Sharp code compiler (cscc)。

名称

  • ECMA-334 4th edition によると、C# は「C Sharp」(シーシャープ)と発音し、「C#」 (LATIN CAPITAL LETTER C (U+0043) の後にNUMBER SIGN # (U+0023)) と書く [9]。 音楽のシャープ (♯, MUSIC SHARP SIGN (U+266F)) ではなくナンバーサイン (#) を採用したのは、フォントやブラウザなどの技術的な制約に加え、標準的キーボードには前者の記号が存在しないためである。
  • "#"接尾辞は、既存言語から派生した多くの.NET言語にも使用されている。これには、J#(Javaのマイクロソフトによる実装)、A#(Adaから)、F#(おそらくMLファミリに使われた型システムのSystem Fから[要出典])が含まれる。この接尾辞はGtk#GTK+などのGNOMEライブラリの.NETラッパ)、Cocoa#(Cocoaのラッパ)などのライブラリにも使用されている。
  • C#という名称の解釈として、「(A~Gで表された)直前の音を半音上げる」という音楽記号の役割に着目し、「C言語を改良したもの」を意味したのではないか、というものがある。これは、C++の名称が「C言語を1つ進めたもの」という意味でつけられたことにも似ている。
  • アンダース・ヘルスバーグは、「C#」が「C++++」(すなわち「C++をさらに進めたもの」)にみえるのが由来である、と語っている。[10][11]

脚注

  1. ^ ヘルスバーグはDelphiのリリース直後に、Microsoftによる引き抜きによって移籍している。
  2. ^ 全てではなく一部にプロプライエタリなコンポーネントもある。そのため、それに依存するものなど、後述のMonoなどで制限がある場合がある。
  3. ^ null 許容型のボックス化 (C# プログラミング ガイド) MSDNライブラリ
  4. ^ https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/keywords/switch
  5. ^ https://blogs.msdn.microsoft.com/dotnet/2017/11/15/welcome-to-c-7-2-and-span/
  6. ^ https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes#compiler
  7. ^ https://docs.microsoft.com/ja-jp/visualstudio/releasenotes/vs2017-relnotes#csharp
  8. ^ dotnet/roslyn - GitHub
  9. ^ Standard ECMA-334 C# Language Specification
  10. ^ レポート:コミュニティスペシャルセッション with Anders Hejlsberg in Microsoft Developers Conference 2006
  11. ^ C#への期待。アンダースからの返答

関連項目

外部リンク






C#と同じ種類の言葉


固有名詞の分類


英和和英テキスト翻訳>> Weblio翻訳
英語⇒日本語日本語⇒英語
  

「C#」に関係したコラム

  • FXやCFDの三角形移動平均とは

    FXやCFDの三角形移動平均とは、移動平均の移動平均のことです。つまり、移動平均値を算出して、さらにその数値の移動平均値を算出します。なお、移動平均には単純移動平均を用います。三角形移動平均は、三角移...

  • FXの三尊とは

    FX(外国為替証拠金取引)の三尊とは、釈迦三尊の並びのようにローソク足が並んでいる状態のことをいいます。ヘッドアンドショルダー(head and shoulder)ともいいます。三尊は、三尊天井と逆三...

  • FXでダウ理論を用いるには

    ダウ理論(Dow Theory)とは、ダウ・ジョーンズの創設者のチャールズ・ダウ(Charles Henry Dow)が提唱した相場理論のことです。ダウ理論には以下の6つの基本法則があります。ファンダ...

  • FXの口座明細の証拠金や維持率とは

    FX(外国為替証拠金取引)の口座明細には、証拠金や維持率のような専門用語が使われています。ここでは、それらの用語の意味や計算方法について解説します。建玉可能金額(たてぎょくかのうきんがく)新規に建玉(...

  • FXのダブルトップでのエントリーポイントを見つけるには

    ダブルトップとは、チャートが「W」の字を上下反転したように形成されていることです。ダブルトップが形成されると、2つのエントリーポイントが発生します。下の図は、ダブルトップを形成したチャートです。ダブル...

  • FXやCFDのシャンデモメンタムとは

    FXやCFDのシャンデモメンタムとは、相場の売られ過ぎや買われ過ぎを判断するためのテクニカル指標のことです。シャンデモメンタムは、0を中心に-100から100までの値で推移します。シャンデモメンタムで...

辞書ショートカット

カテゴリ一覧

全て

ビジネス

業界用語

コンピュータ

電車

自動車・バイク

工学

建築・不動産

学問

文化

生活

ヘルスケア

趣味

スポーツ

生物

食品

人名

方言

辞書・百科事典

すべての辞書の索引

「C#」の関連用語

C#のお隣キーワード

   

英語⇒日本語
日本語⇒英語
   
検索ランキング

画像から探す

Athlon

ボール マーカー

VALUESTAR N VN790/BS

ネック

Qosmio

ウィーク グリップ

変倍

ウォーター ハザード





C#のページの著作権
Weblio 辞書情報提供元は参加元一覧にて確認できます。

  
三省堂三省堂
Copyright (C) 2001-2018 Sanseido Co.,Ltd. All rights reserved.
株式会社 三省堂三省堂 Web Dictionary
社団法人日本映像ソフト協会社団法人日本映像ソフト協会
Copyright © 2000-2018 Japan Video Software Association
丸ヱム製作所丸ヱム製作所
© 1998-2018 Maruemu Works Co,. Ltd. All rights reserved.
独立行政法人科学技術振興機構独立行政法人科学技術振興機構
All Rights Reserved, Copyright © Japan Science and Technology Agency
JabionJabion
Copyright (C) 2018 NII,NIG,TUS. All Rights Reserved.
Bio WikiBio Wiki
Bio Wikiの記事を複製・再配布した「分子生物学用語集」の内容は、特に明示されていない限り、次のライセンスに従います:
CC Attribution-Noncommercial-Share Alike 3.0 Unported
トランスプラント・コミュニケーション [臓器移植の情報サイト]トランスプラント・コミュニケーション [臓器移植の情報サイト]
© 1996-2008 Transplant Communication All Rights Reserved (Unless otherwise noted.)
皓星社皓星社
Copyright (C) 2018 株式会社皓星社 All rights reserved.
ウィキペディアウィキペディア
All text is available under the terms of the GNU Free Documentation License.
この記事は、ウィキペディアのC (改訂履歴)、C-- (改訂履歴)、C++ (改訂履歴)、著作権マーク (改訂履歴)、C Sharp (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。 Weblio辞書に掲載されているウィキペディアの記事も、全てGNU Free Documentation Licenseの元に提供されております。

©2018 Weblio RSS