[PDF] P0190R0: Proposal for New memory order consume Definition
memory_order_consumeの定義を変更する提案。RCUだけではなくGCなどにも利用できるようにする。Linuxカーネルでも使えるようにする。
[PDF] P0192R0: Adding Fundamental Type for Short Float
32bit以下のサイズのshort float型の追加の提案。
16bit浮動小数点数は機械学習や画像処理の分野で広く使われるようになっている。IEEE 754-2008では2進数16bitのフォーマットが定義されている。今のARMはネイティブにサポートしている。IntelのCPUでもサポートする計画がある。GPUでは、OpenGLが16bit浮動小数点数を規定している。OpenEXRではfloatの半分のサイズの浮動小数点数を組込型同様に扱えるライブラリがある。nVidiaのCUDAでは16bit浮動小数点数行列があるが、C++規格に存在しないために独自規格になっている。GCCはIEEEやARMのサポートのために__fp16型がある。LLVMにもhalf型がある。
16bit浮動小数点数型は現実の需要があるので、C++標準は早急に取り入れるべきであるとする。
型はshort floatで、浮動小数点数リテラルのサフィックスはsもしくはSだ。
short float s1 = 1.0s ;
short float s2 = 1.0S ;
これは早く入るべきだ。
P0193R0: Where is Vectorization in C++‽
C++に手動のベクトル処理を淹れる方法についての考察。ライブラリベースで入れることを検討している。具体的な話はあまりない。
[PDF] P0194R0: Static reflection (revision 4)
静的リフレクション機能の提案。
この提案では、宣言に何らかの演算子を適用すると、メタオブジェクトという型が生成され、その型を用意された特別なtraitsに渡すことで、名前や型などの詳しい情報を得ることができる。
P0195R0: Modernizing using-declarations
using宣言をpack展開に対応させる提案。
例えば、今提案中のoverloadは、
template< typename Head, typename ... Rest >
struct overloader : Head, overload< Rest... >
{
using Head::operator() ;
// コンストラクターなど
} ;
template < typename T >
struct overloader< T > : T
{
using T::operator () ;
} ;
template < typename ... Types >
constexpr auto make_overloader( Types && ... args )
{
return overloader< Types ... >( std::forward<Types>...) ;
}
のように再帰的に書かなければならない。これは非効率的だ。
再帰的に書かなければならない理由は、using宣言がパック展開に対応していないからだ。対応していれば以下のように書ける。
template < typename ... Types >
struct overloader : Types ...
{
using Types::operator() ... ;
} ;
確かに便利だが、利用方法は限られる気がする。あって困ることはないだろう。
[PDF] P0196R0: A generic none_t literal type for Nullable types
型none_tとその値noneの提案。
optionalやanyといったライブラリでは、何も値が入っていないnullな状態になり得る(nullable)。各ライブラリごとにnullを表す別々の型を定義して使うのは冗長であるし、使い勝手も悪い。そこで、nullを意味する共通の型を定義しようという提案。これでジェネリックなコードはnullableな型に対してnullが入っているか確認する場合や、nullを入れる場合、単一の型を扱うだけで良くなる。
これも最近流行りのボキャブラリー型だ。入るべきだろう。
[PDF] P0197R0: Default Tuple-like Access
tupleのようなユーザー定義クラスに対して、tupleのようなアクセス(tuple_size, tuple_element, get)を書くのは面倒だ。そういうアクセスはコンパイラーが自動で生成すればいい。この文書は、tupleのようなアクセスをデフォルトで自動で生成する提案だ。
例えば以下のようなクラス、
struct X
{
char m1 ;
short m2 ;
int m3 ;
} ;
X x{ 1, 2, 3 } ;
に対して、以下のようなtuple風アクセスが何もせずとも自動的に生成される。
tuple_size<X>::value ; // 3
tuple_element< 1, X>::type ; // short
get<2>( x ) ; // int型の値3
get<char>(x) ; // char型の値1
public非staticデータメンバーに対するtuple風アクセスが自動生成される。
protected, privated, virtualな基本クラスがない場合、基本クラスも再帰的に探される。
template < typename Head, typename ... Rest >
struct X : X< Rest ... >
{
Head m ;
X( Head && head, Rest && ... rest )
: X< Rest ... >( std::forward< Rest >( rest ) ... ),
m( std::forward<Head>(head) )
{ }
} ;
template < typename T >
struct X<T>
{
T m ;
X( T && t )
: m( std::forward<T>(t) )
{ }
} ;
X< char, short, int > x{ 1, 2, 3 } ;
tuple_size<X>::value ; // 3
tuple_element< 1, X>::type ; // short
get<2>( x ) ; // int型の値3
get<char>( x ) ; // char型の値1
いわば簡易的な静的リフレクションで、シリアライゼーションなどの用途に使えるだろう。ちなみに、提案はConcept TSに依存しているが、見た限り、コンパイル時チェックに使っているだけで、Concept TSの依存を取り除くのは可能のようだ。
いまのConcept TSには依存しないでほしい。
[PDF] P0198R0: Default Swap
クラスに対してデフォルトのswapを自動生成する提案。コンパイラーはデフォルトのスワップを生成する。デフォルトのswapはメンバーごとのswapを行う。
struct X
{
int m1 ;
std::string m2 ;
std::array<int, 10> m3 ;
} ;
void f( X & a, X & b)
{
// メンバーごとの効率的なswapが行われる
swap( a, b ) ;
}
std::swapはムーブ可能な型に対しては効率良く動くが、std::arrayのような、ムーブをサポートできない型には効率が悪い。std::arrayのようなクラスは、メンバーごとのswapを行うと効率が良い。そのようなコードは単調で機械的に生成できるので、デフォルトで生成する。swapはfriendなフリー関数として扱われる。
この変更の背景には、swapはコピーやムーブと同じぐらい根本的な操作であるという思想がある。
これは入ってほしい。
[PDF] P0199R0: Default Hash
P0029R0では大抵の型を突っ込めるhash_combineが提案されている。これを使えば、クラス保持する状態のうち、比較に関係のある情報を全部突っ込めばハッシュ計算が素人でも簡単に書けるようになる。問題は、そのようなボイラープレートコードを書くのはダルいということだ。
そこで、そのようなボイラープレートコードをデフォルトで生成されるようにする提案。
P0029とともに入ってほしい提案だ。
ドワンゴ広告
今日は夕方から歯医者だったのでさっさと帰宅した。
ドワンゴは本物のC++プログラマーを募集しています。
CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0
ハーフFloatはどうするんだろうと思ってましたが、規格入りしましたか。めでたい。
ReplyDeleteでも自分でつかう機会は少ないと思います。かなり癖がありそうなので。
NVがTegraで1TFlopsとか言ってるのもハーフFloatの恩恵だったと思いますので、
需要自体はそれなりにあるのでしょうね。
ドワンゴでも画像解析とかする時に有用なんじゃないかと思いますよ。
none_tは結局enum_classでいいのかな？共通認識として持っておくのはそんなに悪くもないかもですね。