C++標準化委員会の文書: P0240R0-P0249R0

P0240R0: Why I want Concepts, but why they should come later rather than sooner

P0225R0「何故私はコンセプトをすぐに欲しているのか」に対する反論、「何故私はコンセプトを欲しているが、時期尚早であるのか」と題された文書。

現在のコンセプトの問題は、標準ライブラリがまだコンセプトに対応していないことと、constrained templateのチェックができないことだ。

標準ライブラリはプログラマーの模範となるべきライブラリで、標準ライブラリですら対応できていない言語機能は、有用性が十分に検証されているとは言えない。また、コンセプトの標準ライブラリがないということは、ユーザーごとに基本的なコンセプトですら、非互換な車輪の再発明が行われるので好ましくない。

現在のコンセプトは、contrained templateに対するチェック機能がない。つまり、テンプレートが、指定したコンセプトの要件のみを使っているコードかどうかを、実体化せずにチェックできない。C++0x時代のコンセプトを実装したConceptGCCの経験から言えば、エキスパートであっても、手で要件を全て網羅することはできず、コンパイラーに指摘されるまで気が付かない要件漏れが発生している。この機能なしではコンセプトは使い物にならない。また、現在提案中のコンセプトは、将来の拡張性の低い設計で、将来的にチェック機能を追加する際は、未チェックのコンセプトとチェックされるコンセプトという、2種類の言語機能を入れなければならず、言語機能が分断してしまう。

P0241R0: Remove Future-Related Explicit Specializations for Void

futureとpromiseのvoid型への特殊化を除去する提案。

P0146R1で、void型は完全型になるので、特殊化は不要になる。

P0242R0: Standard Library Support for Void

標準ライブラリ、特にiostreamをvoid型に対応させる提案。

P0146R0でvoidが完全型になるので、void型に対応する必要がある。

例えば、テンプレート引数でvoid型が渡された場合、テンプレートコードはコンパイル時分岐が必要なくなる。

template < typename F >
void call_print( F f )
{
    std::cout << f() << std::endl ;
}

int main()
{
    call_print( []{} ) ;
}

提案では、void型に対する入出力は、何もしないとしている。"void"を読み書きしたりするのは、既存のコードから考えても、余計なお世話であろうとしている。

P0244R1: Text_view: A C++ concepts and range based character encoding and code point enumeration library

UTF-8/UTF-16をコードポイント単位で読めるイテレーターを提供するtext_viewライブラリの提案

using CT = utf8_encoding::character_type;
auto tv = make_text_view<utf8_encoding>(u8"J\u00F8erg");
auto it = tv.begin();
assert(*it++ == CT{0x004A}); // 'J'
assert(*it++ == CT{0x00F8}); // 'ø'
assert(*it++ == CT{0x0065}); // 'e'

U+00F8は、UTF-8でエンコードすると、0xc30'b8になってしまうのだが、コードポイント単位でのイテレーター経由で見ることができる。

tahonermann/text_view: A C++ concepts and range based character encoding and code point enumeration library

実装はGitHubで公開されているが、コンセプト機能を多用しているため、最新の開発版GCCでしか動かない。

P0245R1: Hexadecimal floating literals for C++

16進数浮動小数点数リテラルの提案

int main()
{

    double d = 0xffp0 ;

    // 255.0000, 0x1.fep7
    printf("%f, %a\n", d, d ) ;
}

文法は、プレフィクス0x/0Xに続いて、16進数桁を記述して、.で区切って小数点以下を記述し、その後に2進数指数部を記述する。

16進数浮動小数点数リテラルには2進数exponentの指定が必須だ。2進数exponentはeではなくpで記述する

\[0xApB = A \times 2^B\]

たとえば、0xabcp3は、\(\texttt{0xabc} \times 2^3\)となる。

すでにC言語には入っている。

これを執筆途中に、トークン列のパースの問題に苦しんだ。

本の虫: C/C++で0xf+1は合法なのに0xe+1はコンパイルエラーになるのはなんで？

[PDF] P0246R0:Contract Assert Support Merged Proposal

フォントにLinux Libertineを使っているためstやctやらがligatureで表示されてやや戸惑う。

それはともかく、内容はcontract機能の議論の結果の改定案。contract機能とは、関数にpreconditionやpostconditionとして期待される状態をチェックするコードを記述できる機能で、コンパイル時や実行時にチェックできる。いわば高級なコア言語でサポートされたassertと言える。

[PDF] P0247R0: Criteria for Contract Support

これもLinux Libertineフォントによるligatureがうっとおしい。

内容は、実行時contractチェックが満たすべき要件について。

[PDF] P0248R0: Concepts in C++17

C++17にConceptが入るべきだと主張する文書。

筆者は現行のコンセプトに満足していない。

[PDF] P0249R0: Input Devices For 2D Graphics

イベント処理と割り込み処理のためのライブラリの提案。

BoostのSignalを参照している。また、QtやAllegro(ゲームフレームワーク)も引き合いに出しているほか、jQueryの手軽さに最も影響を受けた設計だとしている。

確かに、ある程度のGUIライブラリでは常に再発明されている機能ではあるが、皆が納得する設計にするのは難しい気がする。