本の虫

著者:江添亮
ブログ: http://cpplover.blogspot.jp/
メール: boostcpp@gmail.com
Twitter: https://twitter.com/EzoeRyou
GitHub: https://github.com/EzoeRyou

アマゾンの江添のほしい物リストを著者に送るとブログ記事のネタになる

筆者にブログのネタになる品物を直接送りたい場合、住所をメールで質問してください。

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ライブラリでは常に再発明されている機能ではあるが、皆が納得する設計にするのは難しい気がする。

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0