C++標準化委員会の文書: P0480R0-P0489R0

P0480R0: Explicit type checking with structured bindings

構造化束縛に型を制約できる機能を追加すべきではないかという提案。

我々は変数の型に制約をかけられる。

SpecificType var = func() ;
// 間に長いコード
process( var ) ;

このように書いた場合、funcの返す型はSpecificTypeに変換可能であり、processはSpecificTypeを受け取るという制約を書いたことになる。後にfuncやprocessの定義が書き換わって、このコードが通らなくなった場合は、コンパイル時に発見できる。

auto var = func() ;
process( var ) ;

このように書いた場合、型に制約がかからない。

構造化束縛では、型に制約をかす方法がない。ライブラリである程度の制約をかすことはできるが、そのためには冗長なコードを書かなければならない。構造化束縛で型に制約をかける機能が必要ではないか。

[PDF] P0481R0: Bravely Default

デフォルトのコピーコンストラクターがあるならば、デフォルトのoperator ==を生成しようという提案。

そして、operator ==が定義されていて、operator !=が定義されていないならば、デフォルトのoperator !=を生成する。

コピーは等価と深く結びついているので、この挙動は問題がないという主張。

なお、タイトルはスクエアエニックスから出された3DSのゲームが元ネタだという。タイトルは完全に意味不明だが、この提案に不思議と合っているから使ったという。

P0482R0: char8_t: A type for UTF-8 characters and strings

UTF-8文字型であるchar8_tの提案。

UTF-8文字列リテラルの型もchar8_t[]型になる。

移行のために、char8_t[]からchar[]への暗黙の型変換を追加する。この暗黙の型変換を追加するには標準変換の細かいルールを変更しなければならないので、最初からdeprecated扱いで入れるのもありだ。

std::u8stringからstd::stringへの暗黙の変換も提供する。

必ず入れなければならない。

[PDF] P0483R0: Extending Memory Management Tools, And a Bit More

T型の値を参照するイテレーター[first, last)を受け取り、未初期化のメモリを参照する出力イテレーターoutに対して、T型がnoexceptなムーブを提供していればムーブ構築を、そうでなければコピー構築を行うアルゴリズム、uninitialized_move_if_noexcept(first, last, out)の提案。

実装は簡単だがあっても困らないだろう。

[PDF] P0484R0: Enhancing Thread Constructor Attributes

C++のスレッドライブラリを使わず、実装依存の独自拡張のスレッドを使う理由に、スレッドに対して様々な実装依存のオプションを指定したいという需要がある。

オプションというのは、例えばスレッドの優先度、アフィニティ、スケジューリング戦略、スタックサイズ、スタック拡大の有無などだ。

これらのオプションをどうやって指定するか。実装がサポートしていない無効なオプションを渡した時にどう通知するか。実装がサポートしているオプションをクエリーする方法などについて、どのように設計すればいいのかということについて軽くまとめている。特に提案はない。

[PDF] P0485R0:Amended rules for Partial Ordering of function templates

テンプレートのpartial orderingの文面に考慮漏れがあり、パラメーターパックが関わった時に、関数テンプレートのテンプレートの実体化が曖昧になる問題を修正。

[PDF] P0486R0: for_each_iter algorithm proposal

参照する値ではなくイテレーターを得るfor_each_iterアルゴリズムの提案。

std::vector<int> v = { 1,2,3,4,5 } ;
for_each_iter( begin(v), end(v), [](auto && i )
    { std::cout << *i << '\n' ; } ) ;

ありそうでなかった。

P0487R0: Fixing operator>>(basic_istream&, CharT*) (LWG 2499)

以下のコードはバッファーオーバーフローの危険性がある。

char buffer[32] ;
std::cin >> buffer ;

C11でgetsが廃止されたように、operator >>( basic_istream &, charT * )も廃止しようという声がある。このオーバーロードは廃止すべきだが、以下のように変更してはどうか。

template<class charT, class traits, size_t N>
  basic_istream<charT, traits>& operator>>(basic_istream<charT, traits>& in,
        charT* scharT (&s)[N]);

これでバッファーオーバーフローの危険性はなくなる。

ついでにstd::arrayにも対応させよう

template<class charT, class traits, class arrayT>
  basic_istream<charT, traits>& operator>>(basic_istream<charT, traits>& in,
        charT*arrayT&& s);

という提案。安全のために採用されるべきだ。

[PDF] P0488R0: WG21 Working paper: NB Comments, ISO/IEC CD 14882

現在のドラフト規格の文面に対するNBコメント集

[PDF] P0489R0: WG21 Working paper: Late Comments on CD 14882

NBコメントの締め切りまでに提出が間に合わなかったコメント集

ドワンゴ広告

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

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

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