C++
(C23 から転送)
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2026/05/17 09:50 UTC 版)
| パラダイム | 手続き型プログラミング、データ抽象化、オブジェクト指向プログラミング、ジェネリックプログラミング[1] |
|---|---|
| 登場時期 | 1983年 |
| 開発者 | ビャーネ・ストロヴストルップ |
| 最新リリース | ISO/IEC 14882:2024/ 2024年10月19日 |
| 評価版リリース | ISO/IEC 14882:2026 (予定) / 2024年10月16日 |
| 型付け | nominative, 安全でない強い静的型付け |
| 主な処理系 | GCC、Clang、Microsoft Visual C++、Intel C++ Compiler、C++ Builder |
| 影響を受けた言語 | C言語、Simula、ALGOL 68、CLU、ML、Ada |
| 影響を与えた言語 | Java、Rust、C#、C++/CLI、D言語、PHP |
| ウェブサイト | isocpp |
| 拡張子 | .C、 .cc、 .cpp、 .cxx、 .c++、 .h |
C++(シープラスプラス)は、汎用プログラミング言語のひとつである。派生元であるC言語の機能や特徴を継承しつつ、表現力と効率性の向上のために、手続き型プログラミング・データ抽象・オブジェクト指向プログラミング・ジェネリックプログラミングといった複数のプログラミングパラダイムが組み合わされている[1]。C言語のようにハードウェアを直接扱うような下位層向けの低水準言語としても、複雑なアプリケーションソフトウェアを開発するための上位層向け高水準言語としても使用可能である。アセンブリ言語以外の低水準言語を必要としないこと、使わない機能に時間的・空間的コストを必要としないことが、言語設計の重要な原則となっている[2][3]。
C++は、1983年にAT&Tベル研究所の計算機科学者ビャーネ・ストロヴストルップによって公開された。また様々なプラットフォームでその開発環境が導入された。1998年からISOとIECの共同で言語仕様とテンプレートライブラリの標準化が行われるようになり、その後2003年、2011年、2014年、2017年、2020年、2023年に標準規格が改訂されている。2025年時点での最新規格は「ISO/IEC 14882:2024」通称「C++23 」[4]。
歴史
ストロヴストルップはプログラミング言語C with Classes(クラス付きのC言語)の開発を1979年に開始した。彼は大規模なソフトウェアの開発に有用な特徴をSimulaが備えていることに気がついたが、Simulaは実行速度が遅く実用的ではなかった。一方でBCPLは実行速度こそ速かったものの、大規模なソフトウェア開発を念頭に置いた場合にあまりにも低級だった。
これらの事情を鑑みて、ストロヴストルップは当時既に汎用的な言語だったC言語にSimulaの特徴を取り入れることを試みた。この取り組みにあたってはALGOL68やAda、CLU、ML等の言語の影響も受けている。最初はクラスと派生クラス、型検査機構の強化、インライン関数、デフォルト引数の機能を、Cfrontを介してC言語に追加した。1985年10月に最初の商用リリースがなされた[5]。
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)』[6](邦訳『注解C++リファレンスマニュアル』[7])が出版され、将来の標準化の土台となるものを提供した。後に追加された機能にはテンプレートと例外処理、名前空間、新形式のキャスト、ブール型が含まれた。
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と呼べるようになった。
C++言語の進化に伴い、標準ライブラリもまた進化していった。C++標準ライブラリに最初に追加されたのは、従来のC言語の printf() や scanf() といった関数を置き換えるストリームI/Oライブラリである。また、C++98における標準ライブラリへの追加で最も重要なものはStandard Template Library (STL) である。C++11では、正規表現による検索・置換や複数スレッドでの同時実行、ハッシュテーブル・ハッシュセットの追加などさらなる拡充が続いている。
国際規格
| 規格発行日 | C++ 国際規格 | 非公式名称 | 対応する日本工業規格 |
|---|---|---|---|
| 1998年9月1日 | ISO/IEC 14882:1998[8] | C++98 | ― |
| 2003年10月16日 | ISO/IEC 14882:2003[9] | C++03 | JIS X 3014:2003 |
| 2007年11月15日 | ISO/IEC TR 19768:2007[10] | C++TR1 | ― |
| 2011年9月1日 | ISO/IEC 14882:2011[11] | C++11 | ― |
| 2014年12月15日 | ISO/IEC 14882:2014[12] | C++14 | ― |
| 2017年11月30日[13] | ISO/IEC 14882:2017[14] | C++17 | ― |
| 2020年12月15日 | ISO/IEC 14882:2020[15] | C++20 | ― |
| 2024年10月19日 | ISO/IEC 14882:2024[4] | C++23 | ― |
長年にわたる作業の後、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) が投票で承認され[16]、同年12月15日に公式に発行された。
2017年11月30日[13]、ISO/IEC 14882:2017 (C++17) が公式に発行された。
2020年9月4日、ISO/IEC 14882:2020 (C++20) が投票で承認され[17][18]、同年12月15日、ISO/IEC 14882:2020 (C++20)に公式に発行された[19]。
2023年2月、ISO/IEC 14882:2023 (C++23 )の技術仕様がISO C++ 規格会議にてまとまり[20]、2024年10月19日に発行された[4]。2019年末から始まったCovid-19の世界的流行により、開発者同士の対面によるミーティングの開催を図ることが難しくなった[21][22][23]ことから、C++23の仕様策定は難航した。
Boost
Boost C++ライブラリを開発しているBoostコミュニティはC++の方向性の決定に大きく貢献し、さらにC++標準化委員会へ改良すべき点などを意見している。2006年当時はマルチパラダイムプログラミングをより自然に行えるようにすることに力が注がれており、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言語/FORTRAN/Pascal/BASICのような言語を用いて作成されたライブラリを利用できる。規格外のライブラリが利用できるかどうかはコンパイラに依存する。
C++標準ライブラリはC++向けに若干の最適化が施されたC言語標準ライブラリを含んでいる。C++標準ライブラリの大部分はSTLである。 コンテナ(可変長配列やリストなど)、コンテナを配列のように扱えるようにするイテレータ、検索やソートを行うアルゴリズムといった有用なツールが提供されている。さらにmapやmultimapのような連想配列や、setやmultisetのようなソート済みコンテナも提供され、これらは全てインターフェイスに互換性がある。テンプレートを用いることにより、あらゆるコンテナ(またはイテレータで定義したシーケンス)に適用できる汎用的なアルゴリズムを記述できる。C言語と同様にライブラリの機能には#include ディレクティブを使ってヘッダファイルを読み込むことによってアクセスする。C++には69本の標準ヘッダファイルがあるが、このうち19本については非推奨となっている。
STLは標準規格に採用される前は、ヒューレット・パッカードの(一時はシリコングラフィックスの)商用ライブラリだった。STLは標準規格の単なる一部分に過ぎず規格書にSTLという表記は見られないが、入出力ストリーム、国際化、デバッグ機能、およびC言語標準ライブラリ等の、STL以外の部分と区別するために、今でも多くの人がSTLという用語を使っている。
大半のC++コンパイラはSTLを含むC++標準ライブラリの実装を提供している。STLPortのようなコンパイラ非依存のSTLも存在する。様々な目的でC++標準ライブラリを独自に実装しているプロジェクトは他にもある。
C++の標準ライブラリは大きく次のように分けられる。多種多様な実行環境が存在することを考慮して、GUIに関するライブラリは標準に含まれていない。
外部ライブラリ
以下に、C++で広く使われていると思われる[独自研究?] ライブラリを挙げる。
- Boost C++ライブラリ
- 様々なC++汎用ライブラリの集合。正規表現を扱うBoost.Regexや無名関数(ラムダ計算)を簡潔に記述できるBoost Lambda Libraryなどがある。C++11やC++14などでも、Boostに存在するライブラリが標準ライブラリに採用されたり、標準ライブラリとして提案された項目がBoostで先行して実装されたりしている。これにより、実際に実装・使用することでの知見が得られ、標準ライブラリとして採用される際に活かされている。
- POCO C++ Libraries
- 汎用C++ライブラリ。 Javaクラスライブラリに類似。
- Apache Xerces
- C++での主要XMLパーサの一つ。Java版も存在する。
- CppUnit
- C++でのユニットテストフレームワーク。 クラス毎の動作確認に威力を発揮する。
特徴
C言語に、オブジェクト指向プログラミングをはじめとする様々なプログラミングパラダイムをサポートするための改良が加えられたものといえる。ただし、他のプログラミング言語と違い、旧来のCと同様に手続き型言語としても扱えるという特徴がある。また、C言語と比べて型チェックが厳しくなっており、型安全性が向上している。このことから、C++をbetter Cというふうに呼ぶことがある。すなわち、基本的にC言語に対して上位互換性がある。初期のC++はCへのトランスレータとして実装され、C++プログラムを一旦Cプログラムに変換してからコンパイルしていた。
ただし、C++という名称が定まった当初の時期から、C言語とC++との間には厳密な互換性はない[24][25]。当時、Cとの互換性について議論の末、「C++とANSI Cの間には不正当な非互換性はない」という合意が形成されることとなった。そのため、正当な非互換性を巡って多くの議論が発生した[26]。ただし、まだANSIによるC言語の標準規格も策定途中の時期である。
その後、先祖であるC言語のANSIによる標準規格制定時には、関数のプロトタイプ宣言やconst修飾など、C++の機能がC言語に取り入れられることにもなった。C99の出現により、//コメントなどのC++で使われていた便利な機能が加わってCとC++の互換性が高まる一方、別々に審議し、別の時期に発行していることと、開発対象が必ずしも同じでないために利害関係者が異なることによる違いもある[要出典]
。
C++はCにクラスのサポートを追加しただけでなく、さらに次のような多種多様な機能を持っており、言語仕様は大変複雑である。言語処理系すなわちコンパイラの実装も、Cなどと比べて難易度が非常に高い。
ここから、よりオブジェクト指向を強化し、「なんでもあり」ではない代わりにシンプルで分かりやすくスマートな設計を目指した新たな言語(JavaやD言語など)が作られることとなった。
Hello, World!
|
|
この節のサンプルは編集しないでください。詳細は編集コメントを参照してください。
|
C++はC言語およびそのプリプロセッサの構文をほぼ継承している。以下のサンプルはビャーネ・ストロヴストルップの書籍「The C++ Programming Language, 4th Edition」(ISBN 978-0321563842) の「2.2.1 Hello, World!」に記載されている標準C++ライブラリのストリーム機能を用いて標準出力に出力するHello worldプログラムである[27][※ 1]。
#include <iostream>
int main()
{
std::cout << "Hello, World!\n";
}
書籍でも明記されているが、main()関数で意図的に返り値を返さない手法が使用されている。
演算子と演算子のオーバーロード
C++には、四則演算、ビット演算、論理演算、比較演算、メンバーアクセスなどの30を超える演算子がある[28]。メンバーアクセス演算子 (.と.*) のような一部の例外はあるが、大半の演算子はユーザー定義によるオーバーロードが可能である。オーバーロード可能な演算子が豊富に揃えられているため、C++を一種のドメイン固有言語として利用できる。またオーバーロード可能な演算子はスマートポインタや関数オブジェクトのような組み込み型の機能を模倣したユーザー定義クラスの実装や、テンプレートメタプログラミングのような先進的な実装テクニックに欠かせないものとなっている。演算子をオーバーロードしても演算の優先順位は変化せず、また演算子のオペランドの数も変化しない。ただし指定したオペランドが無視される可能性はある。
テンプレート
C++には、ジェネリックプログラミングを実現する機能としてテンプレートが存在する。テンプレートにできる対象は、関数とクラスである。C++14以降では変数もテンプレートの対象となった。テンプレートはコード中の型および定数をパラメータ化できる。テンプレートのパラメータ(テンプレート仮引数)に、型、コンパイル時定数またはその他のテンプレート(テンプレート実引数)を与えることで、テンプレートはコンパイル時にインスタンス化(実体化・具現化などとも)される。コンパイラは関数やクラスをインスタンス化するために、テンプレート仮引数をテンプレート実引数に置き換える。テンプレートはジェネリックプログラミング、テンプレートメタプログラミング、コード最適化などのために利用される強力なツールであるが、一定のコストを伴う。各テンプレートのインスタンスはテンプレート仮引数毎にテンプレートコードのコピーを生成するためコードサイズが肥大化する。これはコンパイル時に実型引数の情報を削除することで単一の型インスタンスを生成するランタイム型のジェネリクスを実装したJavaなどの言語とは対照的である。なお、C# (.NET Framework) は実行時コンパイラにより実型引数の情報を削除することなく複数の型インスタンスを生成する方式を採用しており、C++とJavaの中間的なアプローチとなっている。
テンプレートとプリプロセッサマクロはいずれもコンパイル時に処理される言語機能であり、静的な条件に基づいたコンパイルが行われるが、テンプレートは字句の置き換えに限定されない。テンプレートはC++の構文と型を解析し、厳密な型チェックに基づいた高度なプログラムの流れの制御ができる。マクロは条件コンパイルに利用できるが、新しい型の生成、再帰的定義、型の評価などは行えないため、コンパイル前のテキストの置き換えや追加・削除といった用途に限定される。つまりマクロは事前に定義されたシンボルに基づいてコンパイルの流れを制御できるものの、テンプレートとは異なり独立して新しいシンボルを生成することはできない。テンプレートは静的な多態(下記参照)とジェネリックプログラミングのためのツールである。
C++のテンプレートはコンパイル時におけるチューリング完全なメカニズムである。これはテンプレートメタプログラミングを用いて実行する前にコンピュータが計算可能なあらゆる処理を表現できることを意味している。
概略すれば、テンプレートはコードの記述に本来必要な型や定数を明確にすることなく抽象的な記述ができる、パラメータ化された関数またはクラスである。テンプレート仮引数に実引数を与えてインスタンス化した結果は、テンプレート仮引数に指定した型に特化した形で記述されたコードと全く等価になる。これによりテンプレートは、汎用的かつおおまかに記述された関数およびクラス(テンプレート)と、特定の型に特化した実装(インスタンス化されたテンプレート)の依存関係を解消し、パフォーマンスを犠牲にすることなく抽象化できる手段を提供する。
オブジェクト
C++はC言語にオブジェクト指向プログラミングをサポートするための改良を加えたものといえる。C++のクラスには、オブジェクト指向言語で一般的な抽象化、カプセル化、継承、多態の4つの機能がある。オブジェクトは実行時に生成されるクラスの実体である。クラスは実行時に生成される様々なオブジェクトのひな形と考えることができる。
なお、C++はSmalltalkなどに見られるメッセージ転送の概念によるオブジェクト指向を採用していない。
カプセル化
カプセル化とは、データ構造を保証し、演算子が意図したとおりに動作し、クラスの利用者が直感的に使い方を理解できるようにするためにデータを隠蔽することである。クラスや関数はC++の基礎的なカプセル化のメカニズムである。クラスのメンバはpublic、protected、privateのいずれかとして宣言され明示的にカプセル化できる。publicなメンバはどの関数からでもアクセスできる。privateなメンバはクラスのメンバ関数から、またはクラスが明示的にアクセス権を与えたフレンド関数からアクセスできる。protectedなメンバはクラスのメンバおよびフレンド関数に加えてその派生クラスのメンバからもアクセスできる。
オブジェクト指向では原則としてクラスのメンバ変数にアクセスする全ての関数はクラスの中にカプセル化されなければならない。C++ではメンバ関数およびフレンド関数によりこれをサポートするが、強制はされない。プログラマはメンバ変数の一部または全体をpublicとして定義でき、型とは無関係な変数をpublicな要素として定義できる。このことからC++はオブジェクト指向だけでなく、モジュール化のような機能分割のパラダイムもサポートしているといえる。
一般的には、全てのデータをprivateまたはprotectedにして、クラスのユーザに必要最小限の関数のみをpublicとして公開することがよい習慣であると考えられている。このようにしてデータの実装の詳細を隠蔽することにより、設計者はインターフェイスを変更することなく後日実装を根本から変更できる[29] [30]。
継承
継承を使うと他のクラスの資産を流用できる。基底クラスからの継承はpublic、protected、privateのいずれかとして宣言する。このアクセス指定子により、派生クラスや全く無関係なクラスが基底クラスのpublicおよびprotectedメンバにアクセスできるかどうかを決定できる。普通はpublic継承のみがいわゆる派生に対応する。残りの二つの継承方法はあまり利用されない。アクセス指定子を省略した場合、構造体はpublic継承になるのに対し、クラスではprivate継承になる。基底クラスをvirtualとして宣言することもできる。これは仮想継承と呼ばれる。仮想継承は基底クラスのオブジェクトが一つだけ存在することを保証するものであり、多重継承の曖昧さの問題を避けることができる。
多重継承はC++の中でもしばしば問題になる機能である。多重継承では複数の基底クラスから一つのクラスを派生できる。これにより継承関係が複雑になる。例えばFlyingCatクラスはCatクラスとFlyingMammalクラスから派生できる。JavaやC#では、基底クラスの数を一つに制限する一方で、複数のインターフェイスを実装でき、これにより制約はあるものの多重継承に近い機能を実現できる(実装の多重継承ではなく型の多重継承)。インターフェイスはクラスと異なり抽象メソッド(純粋仮想関数)を宣言できるのみであり、関数の実装やフィールド(メンバ変数)は定義できない。JavaとC#のインターフェイスは、C++の抽象基底クラスと呼ばれる純粋仮想関数宣言のみを持つクラスに相当する。JavaやC#の継承モデルを好むプログラマは、C++において実装の多重継承は使わず、実装の継承は単一継承に絞り、抽象基底クラスによる型の多重継承のみを使うポリシーを採用することもできる。
多態
多態 (ポリモーフィズム) は様々な場面で多用されている機能である。多態により、状況や文脈に応じてオブジェクトに異なる振る舞いをさせることができる。逆に言うと、オブジェクト自身が振る舞いを決定することができる。
C++は静的な多態と動的な多態の両方をサポートする。コンパイル時に解決される静的な多態は柔軟性に劣るもののパフォーマンス面で有利である。一方、実行時に解決される動的な多態は柔軟性に優れているもののパフォーマンス面で不利である。
静的な多態
関数のオーバーロードは名称が同じ複数の関数を宣言できる機能である。ただし引数は異なっていなければならない。個々の関数は引数の数や型の順序で区別される。同名の関数はコードの文脈によってどの関数が呼ばれるのかが決まる。関数の戻り値の型で区別することはできない。
関数を宣言する際にプログラマはデフォルト引数を指定できる。関数を呼び出すときに引数を省略した場合はデフォルト引数が適用される。関数を呼び出すときに宣言よりも引数の数が少ない場合は、左から右の順で引数の型が比較され、後半部分にデフォルト引数が適用される。たいていの場合は一つの関数にデフォルト引数を指定するよりも、引数の数が異なる関数をオーバーロードする方が望ましい。
C++のテンプレートでは、より洗練された汎用的な多態を実現できる。特にCuriously Recurring Template Patternにより仮想関数のオーバーライドをシミュレートした静的な多態を実装できる。C++のテンプレートは型安全かつチューリング完全であるため、テンプレートメタプログラミングによりコンパイラに条件文を再帰的に解決させて実行コードを生成させることにも利用できる。
動的な多態
派生
基底クラスへのポインタおよび参照は、正確に型が一致するオブジェクトだけでなく、その派生クラスのオブジェクトを指すことができる(リスコフの置換原則)。これにより、複数の異なる派生型を、同一の基底型で統一的に扱うことが可能となる。また、基底型へのポインタの配列やコンテナは、複数の異なる派生型へのポインタを保持できる。派生オブジェクトから基底オブジェクトへの変換(アップキャスト)では、リスコフの置換原則により、明示的なキャストは必要ない。
dynamic_castは基底オブジェクトから派生オブジェクトへの変換(ダウンキャスト)を実行時に安全に行うための演算子である。この機能は実行時型情報 (RTTI) に依存している。あるオブジェクトが特定の派生型のオブジェクトであることがあらかじめ分かっている場合はstatic_cast演算子でキャストすることもできる。static_castは純粋にコンパイル時に解決されるため動作が速く、またRTTIを必要としない。また、static_castは従来のC言語形式のキャスト構文と違い継承階層のナビゲーションをサポートするため、多重継承した場合もメモリレイアウトを考慮したダウンキャストを実行することができる。ただし、static_castでは多重継承において継承関係を持たない基底型同士のキャスト(クロスキャスト)を実行することはできず、dynamic_castを用いる必要がある。とはいえ、ダウンキャストやクロスキャストが必要となる場合、通例そのプログラムの設計に問題があることが多く、本来は仮想関数のオーバーライドによる多態を用いるべきである。
仮想関数
クラスのメンバー関数をvirtualキーワードで修飾することにより、派生クラスでオーバーライド(再定義)することが可能な仮想関数 (virtual function) となる。仮想関数は「メソッド」と呼ばれることもある[31]。派生クラスにて、基底クラスの仮想関数と名前および引数の数や型の順序が同じ関数を定義することでオーバーライドする(C++11以降では、overrideキーワードにより修飾することでオーバーライドを明示することもできる)。基底クラスの仮想関数を派生クラスでオーバーライドした場合、実際に呼び出される関数はオブジェクトの型によって決定される。基底クラスのポインタのみが与えられた場合、コンパイラはオブジェクトの型をコンパイル時に特定できず正しい関数を呼び出せないため、実行時にこれを特定する。これをダイナミックディスパッチと呼ぶ。仮想関数により、オブジェクトに割り当てられた実際の型に従って、最上位の派生クラスで実装した関数が呼び出される。一般的なC++コンパイラは仮想関数テーブルを用いる。オブジェクトの型が判明している場合はスコープ解決演算子を利用して仮想関数テーブルを使わないようにバイパスすることもできるが、一般的には実行時に仮想関数の呼び出しを解決するのが普通である。
通常のメンバー関数に加え、オーバーロードした演算子やデストラクタも仮想関数にできる。原則的にはクラスが仮想関数を持つ場合はデストラクタも仮想関数にすべきである。コンストラクタやその延長線上にあるコピーコンストラクタはコンパイルされた時点でオブジェクトの型が確定しないため仮想関数にできない。しかし、派生オブジェクトへのポインタが基底オブジェクトへのポインタとして渡された場合に、そのオブジェクトのコピーを作らなければならない場合は問題が生じる。このような場合はclone()関数(またはそれに準じる物)を仮想関数として作成するのが一般的な解決方法である。clone()は派生クラスのコピーを生成して返す。
= 0をメンバー関数宣言の末尾セミコロンの直前に挿入することにより、メンバー関数を純粋仮想関数 (pure virtual function) にできる。純粋仮想関数を持つクラスは純粋仮想クラスと呼ばれ、このクラスからオブジェクトを生成することはできない。このような純粋仮想クラスは基底クラスとしてのみ利用できる。派生クラスは純粋仮称関数を継承するため、派生クラスのオブジェクトを生成したい場合は全ての純粋仮想関数をオーバーライドして実装しなければならない。純粋仮想関数を持つクラスのオブジェクトを生成しようと試みるようなプログラムは行儀が悪い。
テンプレート
型消去 (type erasure) と呼ばれる、テンプレートを活用して動的な(プログラム実行時の)多態性を実現する手法が存在する。この手法はC++の標準ライブラリでもstd::functionやstd::shared_ptrの削除子で採用されている。いずれも、コンストラクタや代入演算子で(一定の条件を満たす)任意のオブジェクトを実引数として渡せるようにすることから多態性を実現している。
単一行コメント
C99の制定前、C言語とC++との分かりやすい差異として、// で始まり改行で終わる、単一行コメントの有無があった。
単一行コメントはもともと、C言語の祖先にあたるBCPLに含まれていた仕様である。現在のC++のコンパイラの多くがC言語のコンパイラとしても使えるようになっているのと同様に、C言語が生まれて間もない頃は、C言語に加えB言語やBCPLのコンパイルができるコンパイラが用いられていた。それらコンパイラは、C言語のソースであってもBCPLと同様に単一行コメントが使用できるよう独自の拡張がなされていたため、 BCPLの単一行コメントに慣れ親しんでいたプログラマ達は、C言語でも単一行コメントを使い続けた。その慣習がC++の誕生時まで生き残っていたため、C++では単一行コメントを「復活」させることになった。[独自研究?]
そのためもあって、C言語での仕様外の単一行コメントの使用は半ば常習と化し、[独自研究?] C99によって単一行コメントが正式に規格として組み入れられた。
C++ソースコードの処理とパーサ
LALR(1)のような旧式のパースアルゴリズムを用いてC++のパーサを記述することは比較的難しい[32]。その理由の一つはC++の文法がLALRではないことである。このため、コード分析ツールや、高度な修正を行うツール(リファクタリングツールなど)は非常に少ない。この問題を取り扱う方法としてLALR(1)でパースできるように改良されたC++の亜種(SPECS)を利用する方法がある。GLRパーサのようにより強力でシンプルなパーサもあるが処理が遅い。
パースはC++を処理するツールを作成する際の最も難しい問題ではない。このようなツールはコンパイラと同じように識別子の意味を理解しなければならない。従ってC++を処理する実用的なシステムはソースコードをパースするだけでなく、各識別子の定義を正確に適用し(つまりC++の複雑なスコープのルールを正確に取り扱い)、型を正しく特定できなければならない。
いずれにせよC++ソースコード処理ツールが実用的であるためには、GNU GCCやVisual C++で使われているような、様々なC++の方言を取り扱えなければならず、適切な分析処理やソース変換やソース出力などが実装できなければならない。GLRのような先進的なパースアルゴリズムとシンボルテーブルを組み合わせてソースコードを変換する方法を利用すればあらゆるC++ツールを開発できる。
互換性
その言語文法の複雑さゆえ、C++規格に準拠したコンパイラを開発するのは一般的に難しい。20世紀末から何年にも渡りC++に部分的に準拠した様々なコンパイラが作られ、テンプレートの部分特殊化などの部分で実装にばらつきがあった。中でも、テンプレートの宣言と実装を分離できるようにするためのexportは問題のキーワードの一つだった。exportを定義したC++98規格がリリースされてから5年後の2003年前半にComeau C/C++が初めてexportを実装した。2004年にBorland C++ Builder Xがexportを実装した。これらのコンパイラはいずれもEDGのフロントエンドをベースにしていた。大半のコンパイラで実装されていないexportは多くのC++関連書籍(例えば"Beginning ANSI C++", Ivor Horton著)にサンプルが記されているが、exportが記載されていることによる問題は特に指摘されていない。GCCをはじめとするその他のコンパイラでは全くサポートしていない。Herb SutterはC++の標準規格からexportを削除することを推奨していたが[33]、C++98では最終的にこれを残す決定がなされた[34]。結局、C++11では実装の少なさ・困難さを理由に削除された。
コンパイラ開発者の裁量で決められる範囲を確保するため、C++標準化委員会は名前修飾や例外処理などの実装に依存する機能の実装方法を決定しないことに決めた。この決定の問題は、コンパイラが異なるとオブジェクトファイルの互換性が保証されない点である。特定の機種やOSでコンパイラの互換性を持たせ、バイナリレベルでのコード再利用性を高めようとするABI[35]のような非標準の規格もあり、一部のコンパイラではこうした準規格を採用している。
2019年現在のメジャーなC++コンパイラ(gcc, Clang, Intel C++ Compiler, Microsoft Visual C++など)の最新版はC++11およびC++14規格にほぼ準拠しており、特にClangは2013年4月時点でC++11の全機能を実装完了した[36][37]。ただしマイナーアップデートとなるC++17を含めると、処理系間でのばらつきは依然として存在する。
C言語との互換性
C++は基本的にC言語の上位互換であるが、厳密には異なる[38]。C言語で記述された大半のプログラムはC++でコンパイルできるように簡単に修正できるが、C言語では正当でもC++では不正になる部分や、C++とは動作が異なる部分が若干存在する。
例えば、C言語では汎用ポインタvoid*は他の型へのポインタに暗黙的に変換できるが、C++ではキャスト演算子によって変換を明示する必要がある。またC++ではnewやclassといった数多くの新しいキーワードが追加されたが、移植の際に元のC言語のプログラムでそれらが識別子(例えば変数名)として使われていると、問題になる。
C言語の標準規格であるC99やその後継C11ではこうした非互換性の一部が解決されており、//形式のコメントや宣言とコードの混在といったC++の機能がC言語でサポートされている。その一方でC99では、可変長配列、複素数型の組み込み変数、指示初期化子、複合リテラルといった、C++でサポートしていない数多くの新機能が追加された[39]。C99で追加された新機能の一部はC++11に反映され、C++14に対してもC99やC11との互換性を向上される提案が行われた。また、可変長配列や複素数型などのC99に追加された機能の一部はC11でオプションとなった[40][41]。
C++で書かれた関数をC言語で書かれたプログラムから呼び出す、あるいはその逆を行なう場合など、C言語のコードとC++のコードを混在させるためにはCリンケージを利用する必要があり、関数をextern "C"で個別に修飾するか、extern "C" { ... }のブロックの中で宣言しなければならない。また、関数引数や戻り値などのインターフェイスはC言語互換形式に合わせる必要がある。Cリンケージを利用した関数については、C++名前修飾がされず、名前修飾に依存している関数オーバーロード機能は利用できない。
C/C++の相互運用性が確保されていることで、慣れ親しんだC言語標準ライブラリ関数の大半をC++でもそのまま利用し続けることができるということはC++の大きなメリットのひとつである。
主なC++処理系
- Microsoft Visual C++ (MSVC)
- C++ Builder (Borland C++ Compiler, BCC)
- g++
- Intel C++ Compiler (ICC/ICL)
- Clang
注釈
- ↑ Open issues for The C++ Programming Language (3rd Edition) - このコードはストロヴストルップ自身による訂正文からの引用(633ページ)。
std::endlを'\n'に改めている。またmain関数がデフォルトで0を返す件についてはwww.research.att.com及びwww.delorie.com/djgpp/ を参照されたし。このデフォルト仕様はmain関数のみであり他の関数にはない。
出典
- 1 2 『プログラミング言語C++』第4版、pp.12-13。
- ↑ 『C++の設計と進化』、pp.152-153。
- ↑ 『プログラミング言語C++』第4版、p.11。
- 1 2 3 “ISO/IEC 14882:2024”. International Organization for Standardization. 2025年10月22日閲覧。
- ↑ “Bjarne Stroustrup's FAQ - When was C++ invented?” (English). 2006年5月30日閲覧。
- ↑ Bjarne Stroustrup; Margaret A. Ellis (1990). The Annotated C++ Reference Manual. Addison-Wesley Professional. ISBN 978-0201514599
- ↑ Bjarne Stroustrup; Margaret A. Ellis『The Annotated C++ Reference Manual』足立高徳、小山裕司、シイエム・シイ、2001年。 ISBN 978-4901280396。
- ↑ ISO/IEC 14882:1998
- ↑ ISO/IEC 14882:2003
- ↑ ISO/IEC TR 19768:2007
- ↑ ISO/IEC 14882:2011
- ↑ ISO/IEC 14882:2014
- 1 2 “ISO/IEC 14882:2017”. 2025年10月22日閲覧。
- ↑ https://www.iso.org/standard/68564.html [名無しリンク]
- ↑ https://www.iso.org/standard/79358.html [名無しリンク]
- ↑ We have C++14! : Standard C++
- ↑ “Current Status”. isocpp.org. 2020年9月7日閲覧。
- ↑ “C++20 Approved -- Herb Sutter”. isocpp.org. 2020年9月8日閲覧。
- ↑ “ISO/IEC 14882:2020”. 2021年3月16日閲覧。
- ↑ “C++23 "Pandemic Edition" is complete (Trip report: Winter ISO C++ standards meeting, Issaquah, WA, USA)”. herbsutter.com (2023年2月13日). 2025年10月22日閲覧。
- ↑ Sutter, Herb (2020年7月29日). “Business Plan and Convener's Report: ISO/IEC JTC1/SC22/WG21 (C++)”. 2021年3月16日閲覧。
- ↑ “Upcoming Meetings, Past Meetings”. 2021年3月16日閲覧。
- ↑ Ranns, Nina (2020年11月19日). “WG21 2020-11 Virtual Meeting: Minutes of Meeting”. 2021年3月16日閲覧。
- ↑ Koenig, Andrew; Bjarne Stroustrup (1989年5月11日). “C++: as close as possible to C – but no closer” (PDF) (英語). 2016年11月19日閲覧。
- ↑ Stroustrup, Bjarne. “Stroustrup: FAQ Is C a subset of C++?” (英語). 2016年11月19日閲覧。
- ↑ 『C++の設計と進化』、pp.124-125。
- ↑ Bjarne Stroustrup (2000年). The C++ Programming Language (Special Edition ed.). Addison-Wesley. pp. 46. ISBN 0-201-70073-5
- ↑ 式 - cppreference.com
- ↑ Sutter, Herb; Alexandrescu, Andrei (2004). C++ Coding Standards: 101 Rules, Guidelines, and Best Practices. Addison-Wesley
- ↑ Henricson, Mats; Nyquist, Erik (1997). Industrial Strength C++. Prentice Hall. ISBN 0-13-120965-5
- ↑ 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."
- ↑ Andrew Birkett. “Parsing C++ at nobugs.org”. Nobugs.org. 2009年7月3日閲覧。
- ↑ Why We Can’t Afford Export (PDF, 266 KB)
- ↑ “Minutes of J16 Meeting No. 36/WG21 Meeting No. 31, April 7-11, 2003” (2003年4月25日). 2006年9月4日閲覧。
- ↑ “C++ ABI”. 2006年5月30日閲覧。
- ↑ 後藤大地 (2013年4月22日). “LLVM Clang、C++11にフル対応”. マイナビニュース. 2013年9月7日閲覧。
- ↑ “GCC 4.8 Release Series — Changes, New Features, and Fixes - GNU Project”. gcc.gnu.org. 2022年11月7日閲覧。
- ↑ “Bjarne Stroustrup's FAQ - Is C a subset of C++?”. 2008年1月18日閲覧。
- ↑ “C9X -- The New C Standard”. 2008年12月27日閲覧。
- ↑ 可変長配列: §6.7.6.2
- ↑ C言語の最新事情を知る: C99の仕様 - Build Insider
参考文献
- Stroustrup, Bjarne 著、ロングテール、長尾高弘 訳『プログラミング言語C++』(第3版)アジソン・ウェスレイ・パブリッシャーズ・ジャパン , アスキー (発売)〈アスキーアジソンウェスレイシリーズ〉、1998年(原著1997年)。 ISBN 475611895X。 NCID BA39336320。
- Stroustrup, Bjarne 著、柴田望洋 訳『プログラミング言語C++』(第4版)SB Creative、2015年(原著2013年)。 ISBN 978-4-7973-7595-4。
- Stroustrup, Bjarne 著、岩谷宏 訳、επιστημη監修 編『C++の設計と進化』ソフトバンククリエイティブ、2005年(原著1994年)。 ISBN 4797328541。 NCID BA70383225。
関連項目
- C++/CLI
- Embedded C++
- プログラミング言語の比較
- SystemC - C++言語ベースのハードウェア記述言語
- テンプレートメタプログラミング
- キーワード (C++)
- CとC++の演算子
外部リンク
C23 (C言語)
(C23 から転送)
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2026/04/02 17:34 UTC 版)
|
|
この項目「C23 (C言語)」は翻訳されたばかりのものです。不自然あるいは曖昧な表現などが含まれる可能性があり、このままでは読みづらいかもしれません。(原文:英語版 "C23 (C standard revision)" 2024年11月2日 (土) 08:03 (UTC))
修正、加筆に協力し、現在の表現をより自然な表現にして下さる方を求めています。ノートページや履歴も参照してください。(2024年11月) |
|
|
原文と比べた結果、この記事には多数の(または内容の大部分に影響ある)誤訳があることが判明しています。情報の利用には注意してください。 (2024年11月)
|
C23(ISO/IEC 9899:2024)とは、C言語の現在のオープン標準であり、C17(ISO/IEC 9899:2018)の後継規格である[1]。2016年にC2xとして非公式に策定が開始され[2]、2024年10月31日に発行された[3]。発行された規格に最も近い自由に入手できる草案はN3220である(#利用可能な文書を参照)[4]。C2x草案の最初のWG14会議は2019年10月に開催され[5]、新型コロナウイルス感染症の世界的流行によって2020年は仮想リモート会議として開催され、その後、2024年まで様々な遠隔会議が継続的に開催された。
C23では、__STDC_VERSION__の値が201710Lから202311Lに変更される。一般名の「C17」や「C23」はISO規格識別子の年(9899:2018と9899:2024)ではなく、規格発行前に固定されるこれらの値を反映している。
機能
C23の最新の作業草案に統合された変更点は以下の通りである[6]。
標準ライブラリ
新規関数
<string.h>にmemset_explicit()関数を追加[7]。機密データを消去する目的で、最適化に関係なく常にメモリ書き込み (store) を実行する必要がある場面で使用される。<string.h>にmemccpy()関数を追加[8]。文字列を効率的に連結する。POSIXとSVIDのC拡張と同様である。<string.h>にstrdup()およびstrndup()関数を追加[9]。文字列の複製を動的に確保する。POSIXとSVIDのC拡張と同様である。- ポインタのバイトアライメントを決定するために
<stdlib.h>にmemalignment()関数を追加[10]。 - 新たなヘッダの
<stdbit.h>を追加し、多くの整数型でビット関連の操作をするための関数、マクロ、データ型を定義。全てstdc_で始まるので古いコードやサードパーティのライブラリとの競合を最小限に抑えることができる[11]。- 以下の
*は特定の整数型向けの関数ではこれをuc、us、ui、ul、ullのいずれかに置き換え、型ジェネリックマクロではこれを除去して読む[11]。 - ビットで表現した場合の1または0の個数を数える
stdc_count_ones*()およびstdc_count_zeros*()関数を追加[11]。 - ビットで表現した場合の先頭の1または0の個数を数える
stdc_leading_ones*()およびstdc_leading_zeros*()関数を追加[11]。 - ビットで表現した場合の末尾の1または0の個数を数える
stdc_trailing_ones*()およびstdc_trailing_zeros*()関数を追加[11]。 - ビットで表現した場合に最上位ビットから数えて最初に1または0が現れる位置を探す
stdc_first_leading_one*()およびstdc_first_leading_zero*()関数を追加[11]。 - ビットで表現した場合に最下位ビットから数えて最初に1または0が現れる位置を探す
stdc_first_trailing_one*()およびstdc_first_trailing_zero*()関数を追加[11]。 - 値が正しく2の冪乗であるかを確認する(単一のビットだけが1の場合に
trueを返す)stdc_has_single_bit*()関数を追加[11]。 - 与えられた値より大きくない最大の2の累乗を計算する
stdc_bit_floor*()関数を追加[11]。 - 与えられた値より小さくない最小の2の累乗を計算する
stdc_bit_ceil*()関数を追加[11]。 - 与えられた値を表すのに必要なビット数を調べる
stdc_bit_width*()関数を追加[11]。
- 以下の
<time.h>にglibcとmuslにあるような時間を表す構造体をtime_tに変換できるtimegm()関数を追加する[12]。<math.h>にIEEE 754-2019の推奨に基づく
この節は更新が必要とされています。 (2024年11月)以下のコンパイラはC23に実験的に対応しており、これを利用するためのオプションを提供している:
利用可能な文書
C17などの他のC言語の標準規格と同様に、C23のISOの公式規格書は自由に入手することはできない。
C23の仕様が確定する前の最後の作業草案は2023年4月1日付のN3096である[6]。この草案の後の数カ月間、2023年7日9日付の作業草案N3149と2024年2月22日付の公式標準草案N3219が作成されるまでに数百の変更[71]が行われた[71][72]。これら以降の草案は非公開である[71][72]。
標準草案N3219が発表されたのと同日、新たな作業草案N3220[4]が公開された。この草案は公式には将来のC言語の標準である「C2Y」の草案であると説明[72]されているが、付随する「編集者レポート」では、N3219との違いは付録Kの1つの脚注の修正だけであると明記されている[72]。
参考文献
- N3096 (last freely-available working draft before C23); WG14; April 2023. (free download)
- N3149 (working draft of C23 standard); WG14; July 2023. (not available to public)
- N3219 (ISO/IEC 9899:2023 DIS Draft); WG14; February 2024. (ISO draft available but not free)
- ISO/IEC 9899:2024 (official C23 standard); ISO; 2024. (planning for release in 2024)
- N3220 (first working draft after C23; differs from draft standard N3219 only in one footnote[72]); WG14; February 2024. (free download)
脚注
- ↑ “History of C”. cppreference.com (2022年6月27日). 2022年10月19日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2086: C2x Charter”. open-std.org (2016年9月20日). 2022年12月22日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “ISO/IEC PRF 9899”. iso.org. 2024年9月19日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- 1 2 “ISO/IEC 9899:2024 (en) — N3220 working draft”. open-std.org (2024年2月22日). 2024年11月10日閲覧。
- ↑ “WG14-N2437: Agenda for October 2019”. open-std.org (2019年10月21日). 2021年3月5日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- 1 2 “WG14-N3096: Draft for ISO/IEC 9899:2024”. open-std.org (2023年4月1日). 2023年4月2日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2897: memset_explicit()”. open-std.org (2021年12月27日). 2022年10月25日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2349: Toward more efficient string copying and concatenation”. open-std.org (2019年3月18日). 2022年9月30日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2353: strdup() and strndup()”. open-std.org (2019年3月18日). 2022年12月24日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2974: Queryable pointer alignment”. open-std.org (2022年4月15日). 2022年10月13日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- 1 2 3 4 5 6 7 8 9 10 11 “WG14-N3022: Modern Bit Utilities”. open-std.org (2022年7月6日). 2022年12月24日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2833: Add timegm() as non-optional part of time.h”. open-std.org (2021年10月7日). 2021年12月1日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ See N3096 § B.11 for a useful overview. The functions were added in separate documents: N2488, its updated versions, and its refs.
- 1 2 3 “WG14-N2630: formatted input/output of binary integer numbers”. open-std.org (2021年1月1日). 2022年12月14日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N3020: Qualifier-preserving standard library functions”. open-std.org (2022年6月13日). 2022年10月13日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- 1 2 “WG14-N2645: Add support for preprocessing directives #elifdef and #elifndef”. open-std.org (2020年1月25日). 2022年11月28日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “GCC 12 Adds Support For New #elifdef #elifndef Directives”. phoronix (2021年5月12日). 2022年12月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N3017: #embed - a scannable, tooling-friendly binary resource inclusion mechanism”. open-std.org (2022年6月27日). 2022年12月24日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2686: #warning”. open-std.org (2022年7月22日). 2022年11月28日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2799: __has_include for C”. open-std.org (2021年8月30日). 2022年12月24日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2553: Querying attribute support”. open-std.org (2020年8月4日). 2022年10月14日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N3033: Comma omission and comma deletion”. open-std.org (2022年7月20日). 2022年12月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- 1 2 “WR14-N3042: Introduce the nullptr constant”. open-std.org (2022年7月22日). 2022年12月24日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2763: Adding a Fundamental Type for N-bit integers”. open-std.org (2021年6月21日). 2022年12月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N3035: _BitInt Fixes”. open-std.org (2022年7月21日). 2022年10月13日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2867: Checked N-Bit Integers”. open-std.org (2021年11月28日). 2022年12月14日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2778: Variably-Modified Types”. open-std.org (2021年7月11日). 2022年12月22日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2607: Compatibility of Pointers to Arrays with Qualifiers”. open-std.org (2020年10月31日). 2022年10月13日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2899: Not-so-magic - typeof for C”. open-std.org (2022年1月21日). 2022年12月24日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N3007: Type inference for object definitions”. open-std.org (2022年6月10日). 2022年12月24日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N3037: Improved Rules for Tag Compatibility (updates N3032)”. 2024年11月10日閲覧。
- ↑ “C23 is Finished: Here is What is on the Menu” (英語). The Pasture (2022年7月31日). 2024年11月10日閲覧。
- ↑ “WG14-N2775: Literal suffixes for bit-precise integers”. open-std.org (2021年7月13日). 2022年12月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2549: Allow for binary integer constants”. open-std.org (2020年7月30日). 2022年12月22日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2626: Digit separators”. open-std.org (2020年12月15日). 2022年12月19日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N3030: Enhancements to Enumerations”. open-std.org (2022年7月19日). 2022年11月26日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N3029: Improved Normal Enumerations”. open-std.org (2022年7月19日). 2023年1月29日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2935: Make false and true first-class language features”. open-std.org (2022年2月15日). 2022年11月21日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2934: Revise spelling of keywords”. open-std.org (2022年2月15日). 2022年12月24日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2508: Free Positioning of Labels Inside Compound Statements”. open-std.org (2020年3月28日). 2022年12月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2510: Allowing unnamed parameters in a function definition”. open-std.org (2020年4月9日). 2022年12月24日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2900: Consistent, Warningless, and Intuitive Initialization with {}”. open-std.org (2022年1月1日). 2022年12月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2975: Relax requirements for variadic parameter lists”. open-std.org (2022年4月15日). 2022年11月28日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2335: Attributes in C”. open-std.org (2019年3月9日). 2022年10月26日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- 1 2 “Unsequenced functions”. open-std.org. 2024年7月18日閲覧。
- ↑ “WG14-N2265: Harmonizing static_assert with C++”. open-std.org (2018年7月6日). 2023年3月28日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “Labels at the end of compound statements (C compatibility)” (2022年1月13日). 2024年11月10日閲覧。
- ↑ “WG14-N2334: The deprecated attribute”. open-std.org (2019年1月22日). 2022年10月19日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2408: The fallthrough attribute”. open-std.org (2019年8月11日). 2022年12月25日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2270: The maybe_unused attribute”. open-std.org (2018年7月6日). 2022年12月25日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2267: The nodiscard attribute”. open-std.org (2018年7月6日). 2022年10月19日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2554: Minor attribute wording cleanups”. open-std.org (2020年8月4日). 2022年11月28日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2764: The noreturn attribute”. open-std.org (2021年6月21日). 2022年12月25日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2557: Allow Duplicate Attributes”. open-std.org (2020年9月1日). 2022年11月28日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2418: Adding the u8 character prefix”. open-std.org (2019年9月2日). 2023年1月13日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “What is the point of the UTF-8 character literals proposed for C++17?” (英語). Stack Overflow. 2024年11月10日閲覧。
- ↑ “WG14-N2341: ISO/IEC TS 18661-2 - Floating-point extensions for C - Part 2: Decimal floating-point arithmetic”. open-std.org (2019年2月26日). 2022年11月21日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2601: Annex X - IEC 60559 interchange and extended types”. open-std.org (2020年10月15日). 2022年10月14日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N3018: The constexpr specifier for object definitions”. open-std.org (2022年7月6日). 2022年12月24日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2653: char8_t: A type for UTF-8 characters and strings (Revision 1)”. open-std.org (2021年6月4日). 2023年5月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2728: char16_t & char32_t string literals shall be UTF-16 & UTF-32”. open-std.org (2021年5月15日). 2023年5月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N3038: Introduce storage-class specifiers for compound literals”. open-std.org (2022年7月21日). 2022年11月26日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2940: Removing trigraphs??!”. open-std.org (2022年3月2日). 2022年10月26日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2432: Remove support for function definitions with identifier lists proposal”. open-std.org (2019年9月25日). 2022年12月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2841: No function declarators without prototypes”. open-std.org (2021年10月10日). 2022年11月12日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2412: Two's complement sign representation”. open-std.org (2019年8月11日). 2022年12月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “WG14-N2993: Make *_HAS_SUBNORM be obsolescent”. open-std.org (2022年6月6日). 2022年12月5日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “Clang 9.0 - add new language mode for C2x”. LLVM Project Repository (2019年5月14日). 2022年12月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “Pelles C - major changes between 10.00 and 11.00”. smorgasbordet.com. 2022年12月27日時点のオリジナルよりアーカイブ。2024年11月10日閲覧。
- ↑ “C Standards Support in GCC - GNU Project”. gcc.gnu.org. 2025年10月13日閲覧。
- 1 2 3 “N3150 - Editor's Report, Post January-February 2023 Meeting”. open-std.org (2023年7月8日). 2024年11月10日閲覧。
- 1 2 3 4 5 “N3221 - Editor's Report, Post January 2024 Meeting”. open-std.org (2024年2月15日). 2024年11月10日閲覧。
関連項目
外部リンク
- C Language WG14 (Working Group 14)
- WG14 Document Repository
- WG14 Meetings - agenda and minutes
- WG14 Charters: C2x Charter, C23 Charter, Interpreting the C23 Charter, C Standard Charter
C23
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/03/22 02:02 UTC 版)
C23にはフェラーリ製のギヤボックスが搭載されるであろうとの噂は2003年シーズン終了間際から語られていた。それはエンジンをフェラーリから供給されていることも影響していた。 C23の発表会はレッドブルとのスポンサー10周年を記念して、レッドブルが所有する飛行機などの格納庫のハンガー7で派手に行われた。そこでお披露目されたC23はフェラーリと同型のTipo053エンジン(1グランプリ1エンジン規則のため)とフェラーリの2003年型ギヤボックスを搭載するだけでなく、全体がフェラーリの前年モデルF2003-GAに酷似していた。ホイールはO・Z製で、2004年レギュレーションに対応したリヤウイングとエンジンカバーを装着していたが、サイドポッドの丸みやシャークルーバーの位置など、外観はまさにF2003-GAだった。発表会ではオリジナルだったフロントウイングも、最初のテストではF2003-GAと同様のものに変えられた。 このようにあまりにも似ていることから青いフェラーリと揶揄された。
※この「C23」の解説は、「ザウバー・C23」の解説の一部です。
「C23」を含む「ザウバー・C23」の記事については、「ザウバー・C23」の概要を参照ください。
- C23のページへのリンク