stanford-oval/wikipedia huggingface dataset:
カプラ

カプラ、カプラー、カップラ、カップラー、キャプラ
連結器（w:Coupling (railway)） - 鉄道車両で連結と開放を行うための装置
連結器（w:Coupler (truck)） - 自動車で、セミトレーラーの連結と切り離しを行うトラクタ側の装置。第五輪を参照。
音響カプラ（w:Acoustic coupler） - デジタル信号を音声に変換して伝送する装置
フォトカプラ（w:Optical coupler） - 電気信号を電気的に絶縁して伝達させる装置
連子（Coupler） - オルガンの部品
カプラ (玩具)（w:Kapla）
コネクタの別称
アンテナカップラー - 非整合のアンテナと無線機（または、送信機、受信機）を整合してつなぐ装置。アンテナチューナともいう。
方向性結合器（w:Directional coupler）
光カプラ - 光導波路の光信号を分岐または合流させる装置
姓

フランク・キャプラ - アメリカの映画監督。
フランシス・キャプラ - アメリカの俳優。
フリッチョフ・カプラ - アメリカの物理学者。タオ自然学で知られる。
梅照院 (さいたま市)

| 梅照院 |
| --- | --- |
 
所在地:  埼玉県さいたま市岩槻区太田1-10-4
位置:  北緯35度56分54.2秒 東経139度42分27.5秒﻿ / ﻿北緯35.948389度 東経139.707639度﻿ / 35.948389; 139.707639座標: 北緯35度56分54.2秒 東経139度42分27.5秒﻿ / ﻿北緯35.948389度 東経139.707639度﻿ / 35.948389; 139.707639
山号:  長慶山
院号:  梅照院
宗派:  日蓮宗
本尊:  日蓮大菩薩、一塔両尊
創建年:  天文 - 天正年間（1532年 - 1592年）
開山:  梅照院日如
法人番号:  5030005002752 
 梅照院梅照院 (埼玉県)
テンプレートを表示
梅照院（ばいしょういん）は、埼玉県さいたま市岩槻区にある日蓮宗の寺院。
歴史

天文 - 天正年間（1532年 - 1592年）、梅照院日如によって開山された。当初は「妙広寺」という名称であったが、後に開山にちなみ「梅照院」に改称された。江戸時代の記録によれば、現在よりも境内は広かったという。
1997年（平成9年）に本堂や客殿を新築している。
交通アクセス

岩槻駅より徒歩22分。
Freescale 68HC16

68HC16（またはHC16と略記）は、フリースケール・セミコンダクタ（以前はモトローラ・セミコンダクタとして知られていた）によって作られた、16ビットコアのCPU16に基づき高度にモジュール化されたマイクロコントローラのシリーズである。CPU16コアは完全な16ビットの設計でありながら、68HC11(HC11)のユーザにとって利用しやすいアーキテクチャである。HC11コア設計との類似点は、8ビットの68HC11での設計が16ビットCPUの性能向上を必要としたときのアップグレードパスを提供するための、意図的なものである。HC16とCPU16コアの多くの特徴は、HC11ユーザにとって新しいものである。
HC16がHC11ユーザにソフトウェアのアップグレードパスを提供する一方で、32ビットマイクロプロセッサで見られる非同期アドレス・データバスと完全なハードウェア互換性を提供している。
C++11

C++11は、プログラミング言語 C++ のISO標準 ISO/IEC 14882:2011 の略称である。規格の策定中は2009年中の標準化を目指していたため、C++0x という仮称で呼ばれていた。
ISO/IEC 14882:2003 (C++03) に代わるものとして、2011年8月12日にISOによって承認された。後継のC++14が2014年8月18日に承認されている。
コア言語への機能追加や標準C++ライブラリの拡張を施し、C++TR1ライブラリの大部分を（数学的特殊関数ライブラリを除いて）取り込んでいる。
標準策定の方針

C++ への修正はコア言語と標準ライブラリの双方に及ぶ。
委員会は、新規格の個別の要素の策定に際して次のような方針をとった。
C++98 との、さらに可能であれば C との一貫性および互換性を維持すること。
新機能の実現方法として、コア言語の拡張よりも標準ライブラリの拡張を優先すること。
プログラミングの技法を発展させうるような変更を優先すること。
特定のアプリケーションにのみ有効な機能を導入するよりも、システムやライブラリの設計が容易になるような改良を行うこと。
従来の型安全でない技法に対して、より安全な代替を提供すること。
ハードウェアと密接に動作する能力と効率を向上すること。
現実的問題に対する適切な解決法を用意すること。
“ゼロ・オーバーヘッド原則” (ある機能を使用するためのサポートは、その機能を使用しない場合は影響を及ぼさない) を実践すること。
上級者向けの機能を削ることなく、C++の学習や指導が簡単になるようにすること。
初心者はプログラマ人口の多くを占める。また、多くの初心者は自身が習得した一部の言語機能に拘泥しがちであり、知識を広げようとはしない。従って、初心者への配慮は重要であると考えられた。また、C++の言語仕様の大きさ（アプリケーションやプログラミング・スタイルの多様性も含む）を考えると、どれだけ長い経験を積んだプログラマも新しいプログラミングパラダイムの前では未経験者になり得ることから重要な配慮であると言える。
C++ コア言語への拡張

C++ コア言語の特筆すべき改良点には、マルチスレッドのサポートや、ジェネリックプログラミングのサポート、一様な初期化構文やパフォーマンス向上等が挙げられる。
このページでは、コア言語の機能拡張や変更点を、実行時パフォーマンス向上、ビルド時パフォーマンス向上、使いやすさの向上、全く新しい機能の4つに分けて説明する。機能によっては複数の項目に該当するが、最もよく当てはまる項目で述べることとする。
コア言語の実行時パフォーマンス向上

以下の機能は、主に何らかのパフォーマンス向上を狙ったものである。スピードの向上とメモリ効率の改善の両方が含まれる。
コア言語の実行時パフォーマンス向上 > 右辺値参照とムーブコンストラクタ

C++03以前は、一時変数 (代入演算子の右側に置かれることから、右辺値と呼ばれる) に変更を加えるのは意味がないものと考えられており、関数に参照として渡す場合にはconst T&型としてしか渡すことができなかった。しかし、場合によっては変更できるほうが都合のよいこともあった。例えば所有権の移動（ムーブ）である。
C++11 では、右辺値参照と呼ばれる新たな参照型 T&& が追加された。これにより、右辺値を変更可能なまま関数に渡すことができ、右辺値からのムーブを実現できる。
例えば、std::vector は内部的には C スタイル配列のサイズ付きのラッパである。従来は、std::vector の一時変数が生成されたとき、新たな std::vector を生成してそこに全ての右辺値データをコピーしないといけなかった。コピーの後、一時変数は破壊され、内容は削除される。
右辺値参照があれば、std::vector への右辺値参照を取る std::vector の「ムーブコンストラクタ」を用いることで、単に右辺値から配列へのポインタを取り出してコピーし、空のオブジェクトを残す、ということが実現できる。この場合、配列のコピーは起こらず、空の一時変数を破壊してもメモリの破壊は起こらない。仮にstd::vector にムーブコンストラクタがない場合、通常通りにコピーコンストラクタが const std::vector<>& として呼ばれる。ムーブコンストラクタがある場合、ムーブコンストラクタが呼ばれ、メモリの割り当てが回避できる。
標準ライブラリにムーブコンストラクタが記述されていれば、既存のコードは変更を加えることなく右辺値参照のメリットを享受することができる。std::vectorの一時変数を返す関数は、明示的にstd::vector&&に変更する必要はない。なぜなら、一時変数は自動的に右辺値であるとみなされるからである。
安全上の理由から、右辺値参照として宣言された名前つきの変数をそのまま右辺値として関数に渡すことはできない（そのような変数は左辺値となる）。std::move() を明示的に呼び出すことで、この制限を回避できる。
bool is_r_value(int&&) { return true; }
bool is_r_value(const int&) { return false; }
 
void test(int&& i)
{
  is_r_value(i); // false
  is_r_value(std::move(i)); // true
}
右辺値参照の文言の特性と左辺値参照 (通常の参照) の文言の若干の修正により、右辺値参照を使って完全な関数転送を開発者が提供できるようになる。可変長引数テンプレートと組み合わせ、関数テンプレートから、決まった型の引数を取る別の関数へと引数を転送できる。これは、コンストラクタ引数の転送に最も有用であり、引数に基づいて自動的に的確なコンストラクタを呼ぶようなファクトリ関数の生成に使用できる。
コア言語の実行時パフォーマンス向上 > 一般化された定数式

C++03 には既に定数式が存在している。定数式とは、3 + 4 のように、常に同じ結果を返し副作用の無いものである。定数式はコンパイラの最適化の対象となり、多くの場合コンパイル時に演算が行われ、プログラム中にはその結果のみが格納される。また、C++ の仕様中でも、多くの箇所で定数式の使用が必要となる。配列の定義にも要素数として定数式が必要であるし、列挙子の値にも必要である。
しかし、関数呼び出しやオブジェクトコンストラクタが出現すると、定数式ではなくなる。単純な例を挙げると:
int GetFive() { return 5; }

int some_value[GetFive() + 5]; // 10 要素の整数配列を作りたいが、C++03 では不正。
GetFive() + 5 が定数式でないため、これは C++03 では不正となる。実際には GetFive は実行時に一定値を返すが、コンパイラにそれを知らせる方法がないのである。理論上、関数はグローバル変数に影響を与える、実行時に結果が変わる他の関数を呼ぶ、などの理由がある。
C++11 では、キーワード constexpr が導入される。これにより、関数やオブジェクトコンストラクタがコンパイル時定数であることを保証できる。上の例は、以下のように書き直せる:
constexpr int GetFive() { return 5; }

int some_value[GetFive() + 5]; // 10 要素の整数配列を作る。C++11 では正しい。
これによりコンパイラは、GetFive がコンパイル時定数であることを理解し、検証できる。
constexpr を関数に使用する場合、関数内でできることは非常に制限される。まず、関数は非 void 型の戻り値を持たねばならず、内容として return expr の形を持たねばならない。そして、引数を置き換えた後、expr は定数式でなくてはならない。ここでいう定数式では、constexpr として定義された他の関数を呼ぶか、他の定数式データ変数を使うかしかできない。さらに、定数式内ではあらゆる形の再帰はできず、 constexpr が付けられた関数は定義されるまで翻訳単位中で呼ぶことはできない。
定数式の値として、変数を定義することも可能である:
constexpr double forceOfGravity = 9.8;
constexpr double moonGravity = forceOfGravity / 6;
定数式データ変数は暗黙的に const である。定数式データ変数には、定数式の結果か定数式コンストラクタの結果のみを格納できる。
ユーザー定義型から定数式データ値を作るには、コンストラクタを constexpr として宣言すればよい。定数式関数と同様、定数式コンストラクタは翻訳単位中で使用する前に定義されていなくてはならない。そして、関数本体は空でなくてはならず、メンバを定数式で初期化しなくてはならない。また、このような型のデストラクタは自動生成のものであるべきである。
constexpr として生成された型のコピーも、constexpr として定義されるべきである。こうすることで、constexpr な関数から返された値もconstexprとなる。コピーコンストラクタや演算子オーバーロードといった、クラスの全てのメンバ関数も、定数式関数の定義と同様 constexpr として宣言できる。これにより、コンパイラはクラスのコピーやその他の処理をコンパイル時に行える。
定数式関数・コンストラクタは、非 constexpr パラメータで呼べる。constexpr な整数リテラルが非 constexpr 変数に代入できるように、constexpr 関数を非 constexpr パラメータで呼び出せるし、その結果を非 constexpr 変数に格納できるのである。constexpr キーワードは、式の全ての内容が constexpr である場合のコンパイル時定数性の可能性をコンパイラに伝えるだけのものである。
コア言語の実行時パフォーマンス向上 > Plain Old Data 型の定義の修正

C++03では、構造体が Plain Old Data (POD) 型として扱われるためにはいくつかのルールに従う必要がある。これを満たす型は C と互換性のあるオブジェクトレイアウトを生成する。しかし、C++03 におけるルールは必要以上に厳しく、より多くの型をPOD型にしてもよいのではないかという指摘があった。
C++11 では POD の定義に関して、いくつかのルールが緩和されている。
クラス・構造体は、それが trivial であり、standard-layout であり、すべての非静的データメンバがPOD型であるとき、POD型とみなされる。
trivial なクラス・構造体は、以下のように定義される。
デフォルトコンストラクタを持ち、かつ、非 trivial なデフォルトコンストラクタを持たない。
非 trivial なコピーコンストラクタを持たない。
非 trivial なムーブコンストラクタを持たない。
非 trivial なコピー代入演算子を持たない。
非 trivial なムーブ代入演算子を持たない。
trivial なデストラクタを持つ。
standard-layout なクラス・構造体は、以下のように定義される。
全ての非静的データメンバが standard-layout 型である。
全ての非静的データメンバに、同じアクセス制御 (public, private, protected) がかかっている。
仮想関数を持たない。
仮想基底クラスを持たない。
全ての基底クラスが standard-layout 型である。
一つ目に定義された非静的データメンバと同じ型の基底クラスを持たない。
非静的データメンバを持つ基底クラスを持たない。もしくは、導出クラスが非静的データメンバを持たず、高々一つの基底クラスしか非静的データメンバを持たない。これはつまり、クラス階層において非静的データメンバを持ってよいクラスは一つだけである、ということである。
コア言語のビルド時パフォーマンス向上 > 外部テンプレート

C++03では、ある翻訳単位で完全に引数が特定されたテンプレートが見つかったとき、コンパイラは常にそのテンプレートを実体化しなければならない。このことはコンパイルの時間を劇的に増加させる。特に、同じパラメータを用いたテンプレートが複数の翻訳単位で実体化されるときは顕著である。そして、C++03 にはそのようなテンプレートの実体化を止めさせる手段もなかった。C++11 では、これに対して外部テンプレートが導入された（これは外部変数に対するアナロジーである）。
C++03 には、特定の場所での実体化を強制的にコンパイラに命じる構文がある。
template class std::vector<MyClass>;
C++11 では、以下のような構文が導入された。
extern template class std::vector<MyClass>;
これにより、コンパイラはこの翻訳単位ではテンプレートの実体化をしないようになる。
コア言語の使いやすさの向上

以下の機能は、主に言語を使いやすくするためのものである。例えば型安全性や、類似したコードの繰り返しを削減すること、間違ったコードが書かれにくくすることなどが含まれる。
コア言語の使いやすさの向上 > 初期化子リスト

C++03では、初期化子リスト (initializer list) の考え方を C から引き継いでいる。つまり、構造体のメンバ定義の順に、引数を波括弧{ }の中に記述するというものである。初期化子リストは再帰的に適用されるので、構造体の配列や構造体を含む構造体にも使用できる。
struct Object {
  float first;
  int second;
};

Object scalar = {0.43f, 10}; // first = 0.43f, second = 10 であるような、1つの Object インスタンス。
Object anArray[] = {{13.4f, 3}, {43.28f, 29}, {5.934f, 17}}; // 3つの Object インスタンスから成る配列。
この初期化子リストは、静的なデータの初期化や構造体を特定の値に初期化したいときなどに有用である。C++ にはコンストラクタもあるが、初期化子リストの方が有用である。しかし、C++03 では初期化子リストは Plain Old Data (POD) 型と認識された構造体・クラスにしか適用できなかった。std::vector などの非 POD クラスには初期化子リストは使えなかった。
C++11 では、初期化子リストの考え方がテンプレートと結び付けられた。これには、std::initializer_list を用いる。これによって、コンストラクタなどの関数は、初期化子リストを引数として取ることができる。
class SequenceClass {
public:
  SequenceClass(std::initializer_list<int> list);
};
これにより、SequenceClass は、整数の列から構築できるようになる。
SequenceClass someVar = { 1, 4, 5, 6 };
このコンストラクタは、初期化子リストコンストラクタと呼ばれる特殊なコンストラクタである。このコンストラクタを持つクラスは、統一的な初期化構文の適用の際に特別に扱われる（後述）。
std::initializer_list<> クラスは、C++11 標準ライブラリのファーストクラスの型である。しかし、これを構築できるのは、{ } 構文を用いてコンパイラが静的に構築する場合だけである。一度構築されたらその後コピーはできず参照渡しするしかない。初期化リストは定数であり、一度構築されたらそのメンバを変更することはできず、メンバ中のデータも変更できない。
std::initializer_list は実際の型であるため、クラスコンストラクタのみならずそれ以外の場所でも使用できる。例えば、一般の関数の引数とすることもできる。
void FunctionName(std::initializer_list<float> list);
 
FunctionName({ 1.0f, -3.45f, -0.4f });
コア言語の使いやすさの向上 > 統一的な初期化構文

C++03 には、型の初期化に関して多くの問題点があった。初期化に複数の方法があり、しかもお互いを取り替えたときに同じ結果になるわけではなかった。例えば、従来のコンストラクタの構文は関数宣言と同じ形をしており、場合によってはコンパイラが正しく判定できないことがあった。また、初期化リストは集約型やPOD型にしか使うことができなかった。
C++11 では、どんなオブジェクトでも初期化できる完全に統一的な記法 (uniform initialization) が導入された。これは初期化リスト構文の拡張である。
struct BasicStruct {
  int x;
  double y;
};

struct AltStruct {
  AltStruct(int x, double y) : x_(x), y_(y) {}
  
private:
  int x_;
  double y_;
};

BasicStruct var1{ 5, 3.2 };
AltStruct var2{ 2, 4.3 };
var1 の初期化は完全に C 形式の初期化子リストと同様に振る舞う。すなわち、各データメンバーは、初期化子リストのそれぞれの値によってコピー初期化される。必要ならば暗黙の型変換が行われ、型変換が不可能ならば、コンパイルに失敗する。
var2 の初期化は、単純にコンストラクタを呼ぶだけである。
型が明らかな場合、次のように書くこともできる。
struct IdString {
  std::string name;
  int identifier;
};

IdString get_string()
{
  return { "SomeName", 4 }; // 明示的な型の指定は不要。
}
統一的な初期化構文は、必ずしもコンストラクタ構文の代用となるものではない。コンストラクタ構文が必要な場合もある。クラスが初期化子リストコンストラクタ (TypeName(std::initializer_list<SomeType>)) を持つような場合、（初期化子リストがシーケンスコンストラクタの型に適合するのならば）初期化子リストコンストラクタが優先して適用される。例えば、C++11 の std::vector は、そのテンプレート型の初期化子リストコンストラクタを持つ。つまり、
std::vector<int> theVec { 4 };
のように書いた場合、初期化子リストコンストラクタが呼ばれる。固定長の std::vector を生成するための、サイズを指定する引数ひとつを取るコンストラクタstd::vector(size_type n)を呼ぶためには、標準のコンストラクタ構文を使う必要がある。
std::vector<int> theVec ( 4 );
コア言語の使いやすさの向上 > 型推論

C++03やCでは、変数の型は使用に際して明示的に指定しなければならない。しかし、テンプレート型やテンプレートメタプログラミングなどにおいては、特に関数の戻り値型が複雑に定義されているような場合、型を簡単に書き下せないことがある。そのような場合には、中間結果を変数に格納することが難しく、メタプログラミングライブラリの内部仕様を知っていなくてはならなくなる場合もある。
C++11 では型推論により、この制約を軽減する方法が二つ提供された。一つ目の方法は、明示的に初期化される変数の定義に auto キーワードを使う方法である。これにより、初期化子によって変数の型が特定される。
auto someStrangeCallableType = boost::bind(&SomeFunction, _2, _1, someObject);
auto otherVariable = 5;
someStrangeCallableType の型は、関数テンプレート boost::bind がその引数に応じて返す戻り値の型である。これはコンパイラにとっては容易に判別できるが、ユーザーが調べるのは困難である。
otherVariable の型はまだ分かりやすい。これは、整数リテラルの型である int となる。
二つ目の方法は、キーワード decltype である。これによって、オペランドで指定した式の型をコンパイル時に取得することができる。
int someInt;
decltype(someInt) otherIntegerVariable = 5;
auto で宣言した変数の型はコンパイラにしか分からないので、decltype は auto と組み合わせて使うと特に有用である。
auto はコードの冗長性を省くのにも有用である。例えば、以下のように書かれている場合、
for (std::vector<int>::const_iterator itr = myvec.begin(); itr != myvec.end(); ++itr)
autoを使えばもっと短く書くことができる。なお、vector::cbegin()とvector::cend()は、C++11で追加されたメンバー関数であり、const_iteratorを返すことが規定されている。
for (auto itr = myvec.cbegin(); itr != myvec.cend(); ++itr)
コンテナをネストして使うような場合、違いはもっと大きくなる。一方、そのような場合は typedef を使うこともできる。
コア言語の使いやすさの向上 > 範囲に基づく for ループ

C++03では、コンテナの要素を列挙するためには多くのコードを書く必要があった。一方C#やJavaのような言語には、コンテナの最初から最後までをたどるシンプルな「foreach文」が備わっている。
C++11にも同様の機能が追加された。以下のようなfor文の別表現を使ってコンテナの要素を簡単に列挙することができる。
int my_array[5] = {1, 2, 3, 4, 5};
for (int& x : my_array) {
    x *= 2;
}
この形式のfor文は、範囲に基づくfor (range-based for) と呼ばれる。この形式は、Cスタイルの配列や、初期化リスト、イテレータを返すbegin()関数とend()関数が定義されたあらゆる型に対して使うことができる。begin()とend()を持つ標準ライブラリのコンテナはすべてこの形式で列挙できる。
ただし、ループの途中でイテレータを無効化することがあるケースでは、range-based forを使用することはできない。
コア言語の使いやすさの向上 > ラムダ関数とラムダ式

C++ 標準では、特に std::sort() や std::find() といった C++ 標準ライブラリのアルゴリズム関数と組み合わせた時に、アルゴリズム関数の呼び出しの近くで述語関数を定義したいと思う機会が多い。しかし、このためには関数内部でクラスを定義するしかなかった。この方法は記述量が多く、またコードの流れを妨げがちである。加えて、標準 C++ の規則では、関数の中で定義されたクラスをテンプレートの中で使うことを認めていないので、結局どうしても使うことは不可能であった。
これに対して、C++11ではラムダ関数が定義できるようになった。
ラムダ関数は以下のように定義される:
[](int x, int y) -> int { int z = x + y; return z + x; }
これは、int型の引数を二つとり、int型の値を返すラムダ式である。その内容は{ } の中に記述される。
ラムダ関数の内容が "return 式" の形式である場合には、戻り値型を省略することができる。
[](int x, int y) { return x + y; }
このラムダ関数の戻り値型は decltype(x+y) になる。
ラムダ関数が値を返さない場合、つまり戻り値型が void の場合も戻り値型を省略できる。
ラムダ関数の外で定義された変数であっても、ラムダ関数の中で使用することができる。この種のものは一般にクロージャと呼ばれる。クロージャは[ ]の中に記述する。
std::vector<int> someList;
int total = 0;
std::for_each(someList.begin(), someList.end(), [&total](int x) {
  total += x;
});
std::cout << total;
これは、リストの全要素の合計を表示する例である。
変数 total がラムダ関数のクロージャの一部として格納される。これはスタック変数 total への参照なので、代入することで外側の total の値も変更される。
& は参照を表すシンボルである。スタック変数に対応するクロージャ変数は、&を付けずに定義することも可能で、その場合はラムダ関数は値をコピーする。これにより、スタック変数を参照するのかコピーするのかどちらの意図があるのかわかるようになる。スタック変数を参照することは危険な場合がある。例えば (C++11 標準の) std::function オブジェクトに格納するなどして、ラムダ関数を生成したスコープの外側で使いたい場合は、ラムダ関数がスタック変数を参照していないことをよく確認する必要がある。
ラムダ関数がその定義のあるスコープの内側で実行されることが保証されている場合は、次のように記述すれば、スタック変数をひとつひとつ指定せずに全ての利用可能なスタック変数を使用できる。
std::vector<int> someList;
int total = 0;
std::for_each(someList.begin(), someList.end(), [&](int x) {
  total += x;
});
[ ]の中には次のような指定が可能である。
[]        // ラムダ関数外のどの変数も使うことができない。
[x, &y]   // xはコピーされる。yは参照渡しされる。
[&]       // すべての外部変数は、もし使われれば暗黙的に参照渡しされる。
[=]       // すべての外部変数は、もし使われれば暗黙的にコピーされる。
[&, x]    // xは明示的にコピーされる。その他の変数は参照渡しされる。
[=, &z]   // zは明示的に参照渡しされる。その他の変数はコピーされる。
また、ラムダ関数がクラスのメンバ関数により定義された場合、そのクラスのフレンドであると見なされる。そのようなラムダ関数は、そのクラス型のオブジェクトへの参照を使って、内部のメンバにアクセスできる。
[](SomeType *typePtr) { typePtr->SomePrivateMemberFunction(); };
この例は、このラムダ関数の生成するスコープが SomeType のメンバ関数の中にある場合にのみ動作する。
this ポインタは、各時点でメンバ関数が作動しているオブジェクトを指しているが、その扱いは特別である。ラムダ関数中に明示的な指定が必要になる。
[this]() { this->SomePrivateMemberFunction(); };
[&] または [=] 形式のラムダ関数を用いていれば、thisの記述は必要ない。
ラムダ関数の型はコンパイラ依存であり、明示的に記述することはできない。ラムダ関数を引数として取得したい場合は、その型をテンプレート型にするか、std::function などの型消去の仕組みを使う必要がある。auto キーワードを使ってラムダ関数をローカル変数に格納することはできる。
auto myLambdaFunc = [this]() { this->SomePrivateMemberFunction(); };
コア言語の使いやすさの向上 > 戻り値を後ろに置く関数構文

標準Cの関数宣言の構文は、C言語の機能に対しては最適なものであった。C++ は C から離れて発展してきたが、その基本的な構文を維持しつつ、必要に応じて拡張してきた。しかし、C++ がさらに複雑になってくると、多数の制約、特に関数テンプレートの宣言に関する制約が露呈するようになった。例えば、次のように関数の戻り値の型が文脈によって決まる場合、C++03では明示的にテンプレート型引数で指定するか、boost::result_ofやboost::decayのような型推論をエミュレートする補助ライブラリに頼るしかなかった。
template<typename TResult, typename LHS, typename RHS>
TResult AddFunc(const LHS& lhs, const RHS& rhs) { return lhs + rhs; }

int a = AddFunc(1, 2); // コンパイルエラー。
int b = AddFunc<int>(1, 2); // C++03 以前でも、引数の型は実引数から推論できるので省略可能だが、戻り値の型は推論できない。
TResult 型は、LHS と RHS の型を加算して作られる型であり、それらの実際の型によって決まる。
C++11では、前述のように decltype という機能が追加されたが、これを直接戻り値の型推論に使うことはできない。
// 正しくない
template<typename LHS, typename RHS>
decltype(lhs+rhs) AddFunc(const LHS& lhs, const RHS& rhs) { return lhs + rhs; }
パーサーが decltype(lhs+rhs) を解析する時点で、lhs と rhs はまだ定義されておらず、有効な識別子にはなっていない。したがって、この書き方も C++ に適合していない。
この問題に対処するために、C++11 では次のような関数の定義と宣言の構文が導入された。
template<typename LHS, typename RHS>
auto AddFunc(const LHS& lhs, const RHS& rhs) -> decltype(lhs+rhs) { return lhs + rhs; }

int a = AddFunc(1, 2);
autoでいったん型を前置しておき、後置のdecltypeで補足している。
この構文は、非テンプレート関数の宣言や定義にも使用できる。
struct SomeStruct {
  auto FuncName(int x, int y) -> int;
};

auto SomeStruct::FuncName(int x, int y) -> int {
  return x + y;
}
この構文で使われるautoキーワードは、自動型推論の場合とは異なった意味をもつ。
コア言語の使いやすさの向上 > オブジェクト構築の改良

C++03では、コンストラクタは他のコンストラクタを呼び出せず、各コンストラクタでクラスメンバの初期化を全て行わなくてはならない。これはしばしば初期化コードの重複を招く。また、基底クラスのコンストラクタは、派生クラスに直接は公開されない。つまり、基底クラスのコンストラクタと殆ど同等であったとしても、派生クラス側でコンストラクタを定義する必要がある。他にも、constでないデータメンバは、メンバの宣言時に初期化できず、コンストラクタで初期化しなければならない。
C++11では、このような問題点に対する解決策が提供された。
まず、C++11では、コンストラクタが他の同等なコンストラクタを呼び出すこと（委譲）が可能になった。これにより、コンストラクタが他のコンストラクタを最小のコード追加で利用できるようになる。他の言語（Java等）では、既にこれを取り入れているものもある。
構文は以下のようになる:
class SomeType {
  int number;
  
public:
  SomeType(int newNumber) : number(newNumber) {}
  SomeType() : SomeType(42) {}
};
注意すべき点として、C++03では1つのコンストラクタの動作完了と同時にオブジェクトの構築は完了していると考えることができていたが、C++11では一度のオブジェクトの構築に全てのコンストラクタが動作完了しなければならない、と考えなくてはならない点である。複数のコンストラクタが動作することを認めるので、委譲を行う各コンストラクタは完全に構築が完了したオブジェクトに対して動作することを意味する。派生クラスのコンストラクタは、基底クラスでのコンストラクタ間委譲が全て終了した時点で呼び出されることになるであろう。
次に基底クラスのコンストラクタに関して、C++11では、基底クラスのコンストラクタを継承するようにクラスに対して指定することが可能になる。これにより、コンパイラは派生クラスのコンストラクタ呼び出しを基底クラスのそれへと転送するコードを生成することになる。注意すべき点は、この機能は、全てのコンストラクタ呼び出しを基底クラスに転送するか、全く転送しないか、の二者択一の機能であることである。他の注意点として、多重継承時の制限もある。同じシグネチャを持つ2つのコンストラクタに転送することはできないし、転送先のコンストラクタと同じシグネチャを持つコンストラクタを後で宣言することはできない。
構文は以下のようになる:
class BaseClass {
public:
  BaseClass(int value);
  BaseClass(float value);
};

class DerivedClass : public BaseClass {
public:
  using BaseClass::BaseClass;
};
最後にメンバの初期化に関して、C++11では、メンバの初期化に以下のような構文が認められる:
class SomeClass {
  int iValue = 5;
};
この例では、コンストラクタが初期化内容を上書きしない限り、iValueは5に初期化される。上書きする例は次のようになる:
class SomeClass {
  int iValue = 5;
  
public:
  SomeClass() {}
  explicit SomeClass(int iNewValue) : iValue(iNewValue) {}
};
この場合、空のコンストラクタではiValueはクラス定義に従って初期化されるが、int引数を取るコンストラクタの場合はその引数に従って初期化されることになるであろう。
コア言語の使いやすさの向上 > 明示的な仮想関数オーバーライド

C++03では、ユーザーが基底クラスの仮想関数をオーバーライドする際、誤って意図に反する新しい仮想関数を作成する可能性がある:
struct Base {
  virtual void some_func(float);
  virtual bool on_error();
};

struct Derived : Base {
  virtual void some_func(int);
  virtual bool on_eror();
};
派生クラスDerivedを設計したユーザーは、Base::some_funcおよびBase::on_errorをオーバーライドするつもりで記述したが、それぞれ引数の型や関数名（シグネチャ）が異なるため新しい仮想関数が生成される。上記はC++コードとして誤りではないためコンパイルエラーにならず、間違いに気付くことができない。
C++11では、overrideキーワードの導入により、このような問題が解消された:
struct Base {
  virtual void some_func(float);
  virtual bool on_error();
};

struct Derived : Base {
  virtual void some_func(int) override; // 不正：基底クラスの仮想関数をオーバーライドしていない。
  virtual bool on_eror() override; // 不正：同上。
};
overrideキーワードで修飾された仮想関数が、基底クラスのオーバーライド先と一致するかどうかをコンパイラがチェックし、一致しない場合にエラーを報告する。
overrideの他にfinalキーワードがある。finalで修飾された仮想関数のオーバーライドは許可されない。
struct Base {
  virtual void f() const final;
};

struct Derived : Base {
  void f() const; // エラー：Derived::fがfinal Base::fをオーバーライドしようとする。
};
コア言語の使いやすさの向上 > ヌルポインタ

C++03では、定数0に、整数定数とヌルポインタという2つの役割が与えられている（この振る舞いは、Cの黎明期（1972年）から続いている）。
長い間プログラマは、0の代わりに定数NULLを使って、この潜在的な曖昧性を大体は回避してきた。しかし、C++になされた2つの設計上の選択が、新たな曖昧性をもたらした。Cでは、NULLはプリプロセッサマクロであり、((void*)0)か0と展開されるよう定義されている。C++では、void*型から他のポインタ型への暗黙の変換は認められないので、Cの1つ目の定義と同じくNULLを定義すると、char *c = NULLのような単純な例でもコンパイルエラーになる。これを修正するため、C++ではNULLは0へと展開される。0は、あらゆるポインタ型への変換が特別に認められているのである。この結果、オーバーロード機構と酷い相互作用を引き起こす。例えば、以下のような宣言があり
void foo(char *);
void foo(int);
foo(NULL)として呼び出す場合、foo(int)の方が呼ばれることになる。この挙動は、多くの場合に意図されたものではない。
新標準では、ヌルポインタを指定するためにのみ予約された新たなキーワードnullptrが導入される。nullptrは整数型との比較や代入はできないが、あらゆるポインタ型との比較・代入ができる。
互換性のため、0の現行の機能も残されるが、この新構文が上手くいけば、C++委員会は0とNULLをヌルポインタとして使用することを非推奨と宣言し、意味の重複を排除するであろう。
コア言語の使いやすさの向上 > 強い型付けの列挙型

C++03では、列挙型は型安全でなかった。列挙型が異なっていても、実質的には整数として扱われていた。このため、型の違う列挙型の値同士が比較できてしまった。C++03で唯一提供されていた型安全性は、整数や、ある列挙型の値が、暗黙的に他の列挙型には変換されない、ということだけである。また、内部的な整数型はコンパイラの実装に依存しており、列挙型のサイズに依存するコードは可搬ではなかった。さらに、列挙型の値のスコープは、列挙体が定義されたスコープと同じとなる。そのため、二つの列挙型が、同じ名前のメンバをもつことはできなかった。
C++11では、以上のような問題のない、特別なクラス化された列挙型が導入された。enum class（またはenum struct）宣言を用いることで、これを表現できる。
enum class Enumeration {
  Val1,
  Val2,
  Val3 = 100,
  Val4 /* = 101 */,
};
この列挙は型安全である。enum classの値が暗黙的に整数値に変換されることはなく、したがって整数値と比較することもできない（Enumeration::Val4 == 101はコンパイルエラーになる）。
enum classの内部的な型はコンパイラの実装に依存しない。デフォルトではintであり、次のように明示的に指定することもできる。
enum class Enum2 : unsigned int {Val1, Val2};
列挙名は列挙型のスコープで定義される。列挙名を使うときには、Enum2::Val1のように明示的にスコープを指定しなければならない。上の例では、Val1は未定義である。
さらに、C++11では従来スタイルの列挙型にも、明示的なスコープや内部的な型の指定ができる。
enum Enum3 : unsigned long {Val1 = 1, Val2};
この場合、列挙名は列挙型のスコープで定義される（Enum3::Val1）が、後方互換性のため、列挙型が定義されたスコープにも定義される（Val1）。
C++11では列挙型の前方宣言も可能である。以前は列挙型のサイズが内容によって決まっていたため、列挙型は前方宣言できなかった。明示的あるいは暗黙的に列挙のサイズが決定できさえすれば、前方宣言が可能である。
enum Enum1;                     // C++03とC++11両方で不正。内部的な型が明示されていない。
enum Enum2 : unsigned int;      // C++11では正しい。内部的な型が明示されている。
enum class Enum3;               // C++11では正しい。enum class宣言はデフォルトの型がintである。
enum class Enum4: unsigned int; // C++11では正しい。
enum Enum2 : unsigned short;    // C++11でも不正。Enum2が既に違う型で宣言されている。
コア言語の使いやすさの向上 > 山括弧

テンプレートを用いた総称プログラミングを導入するのに、新形式の括弧を導入するのが必要であった。そのためC++には、丸括弧"()"、角括弧"[]"、波括弧"{}"に加えて、山括弧"<>"が導入された。しかし、これにより字句的曖昧さが生じ、（プログラマの意図とは違う、という意味で）間違って解析され、構文エラーになるという事態が発生した:
typedef std::vector<std::vector<int> > Table;  // OK。
typedef std::vector<std::vector<bool>> Flags;  // エラー！ ">>"は右シフトと解析される。
 
void func(List<B>= default_val);  // エラー！ ">="は比較演算子と解析される。
void func(List<List<B>>= default_val);  // エラー！ ">>="は右シフト代入と解析される。
 
template<bool I> class X {};
X<(1>2)> x1;  // OK。
X< 1>2 > x1;  // エラー！ 一つ目の">"は山閉じ括弧と解析される。
C++11の字句解析では、最も深くネストした開き括弧が山括弧"<"である場合、">"は、次に">"や"="が続いていても山閉じ括弧として扱われる。これにより、上記のエラーは最後のものを除いて修正される。最後のものを修正するには、曖昧さを取り除くために丸括弧を足さなくてはならない。
X<(1>2)> x1;  // OK。
こうすることで、"("から")"の間については、コンパイラは<>の文字を山括弧と扱わなくなる。
コア言語の使いやすさの向上 > 明示的な変換関数

C++規格には、一引数コンストラクタを暗黙的な型変換関数として扱われないようにするための修飾子として、explicitキーワードが導入された。しかし、これは変換関数には何の効果も無い。
例えば、スマートポインタのクラスは、本物のポインタと同じように振る舞うためにoperator bool()を持っていることがある。この変換を追加することで、if (smart_ptr_variable)としてそれをテストできる（ポインタが非NULLならtrueを、NULLならfalseと判定できるはずである）。しかし、この変換を認めると、不本意な変換も発生してしまう。C++のboolは算術型として定義されているため、整数型やさらには浮動小数点型としてまで変換されてしまい、ユーザーが意図しない数値型としての動作を引き起こしてしまうのである。
C++11では、explicitキーワードを変換関数にも適用できるようになる。コンストラクタへの適用と組み合わせ、さらなる暗黙的型変換を防止できる。
コア言語の使いやすさの向上 > 別名テンプレート

C++03では、typedefを定義する際にできることは、他の型に対して別名を付けることだけであり、存在するすべてのテンプレート引数が指定されたテンプレートの特殊化に対して別名をつけることもこれに含まれる。typedefのテンプレートを作ることはできない。例えば:
template <typename First, typename Second, int Third>
class SomeType;

template <typename Second>
typedef SomeType<OtherType, Second, 5> TypedefName; // C++03では不正
これはコンパイルできない。
C++11では以下の構文でこれが可能になった。
template <typename First, typename Second, int Third>
class SomeType;

template <typename Second>
using TypedefName = SomeType<OtherType, Second, 5>;
C++11ではusing構文は型の別名付けにも使用できる。
typedef void (*Type)(double); // 従来の形式
using OtherType = void (*)(double); // 新たに導入された形式
コア言語の使いやすさの向上 > 透過的なガベージコレクション

C++11には、透過的ガベージコレクションの機能は直接には導入されない。代わりに、C++11標準には、C++でのガベージコレクションの実装を容易にする仕様が導入された。
完全なガベージコレクションのサポートは、もっと後の標準やTechnical Reportに回されることになった。
コア言語の使いやすさの向上 > 制限の無い共用体

C++標準にはunionのメンバになれるオブジェクトの型に対する制限がある。例えば、trivialでないコンストラクタが定義されているオブジェクトは共用体の中に含めることが不可能である。共用体に課された制限の多くは無くてもよいと考えられたため、次期標準では参照型を除いて共用体のメンバの型の制限が全廃される。この変更により、共用体は使いやすく強力で有用なものになる。
以下はC++11で許される共用体の簡単な例である:
struct point {
  point() {}
  point(int x, int y): x_(x), y_(y) {}
  int x_, y_;
};

union {
  int z;
  double w;
  point p;  // pointがtrivialでないコンストラクタを持つためC++03では不正だが、C++11では問題ない。
};
この変更は現行の規則を緩めるだけなので、既存のコードを破壊することはない。
コア言語機能の改良

以下の機能は、従来のC++では全く不可能であったり、異常に冗長な記述が必要だったり、可搬性の無いライブラリを使わないといけなかったりしたような機能を提供するものである。