2015-06-30

C++標準化委員会の文書 2015-04-pre-Lenexaのレビュー: N4450-N4459

N4450: Variant: a typesafe union (v2)

型安全unionとして、variantライブラリの提案。

Boost.variantと似ているが、variantのネストはサポートしていない。

[PDF注意] N4451: Static reflection

静的リフレクションとして、メタプログラミングでプログラムの構造を辿れる。

論文の冒頭で、会議で上げられた懸念事項が書いてあるが、筆者も同感で、あまりにも巨大すぎる上に暴力的に強力な機能であると思う。

[PDF注意] N4452: Use cases of reflection

N4451で提案されている静的リフレクションは、あまりにも強力すぎる。初心者にそのような強力なツールを与えることは危険ではないか。という会議での懸念に対して、提案されている静的リフレクションの利用例を挙げている論文。

プログラミングにおいては、機械的な雛形コードを手で書かなければならないことがよくある。プリプロセッサーマクロやテンプレートによるメタプログラミングは、そのようなコードの記述量を抑えることに貢献しているが、限界がある。リフレクションがあれば問題を解決できる。

利用例1: ポータブルな型名

std::type_infoのnameメンバー関数の返す文字列は規格化されていない。それどころか、人間が読める文字列を返すとも、ユニークな文字列を返すとも規定されていない。文字列まで規格化された機能が必要である。さらに、nameメンバー関数はconstexpr関数ではないのでコンパイル時に使えない。また、type_infoはtypedefを考慮しないので、これまたやりにくい。

利用例2: ログ

関数の実行時にログを取るさい、関数の引数名をログ出力に含めたいことはよくある。

利用例3: シリアライゼーション

あるクラスのインスタンスをXMLやJSONやXDRのような構造化されたフォーマットで出力したい。これにはクラスごとに個別でメンバーを列挙するコードを手で書かなければならない。リフレクションがあればこのような問題は簡単に解決できる。

利用例4: Cross-cutting aspects

特定の条件を満たした関数の前後に何らかの共通処理を追加したい場合、リフレクションがあれば冗長なコードを書かずに簡単にできる。

利用例4: factory patternの実装

論文では、追加の利用例として、強力な静的リフレクションを使う利用例を挙げている。

特定のnamespace内にあるpersistent_で始まる変数名からSQLを生成。

コンパイル時にC++ソースコードを生成

デリゲートやデコレートの実装

データメンバーの配置を変える

struct foo
{
    bool b;
    char c;
    double d;
    float f;
    std::string s;
};

このようなクラスを与えると

struct rdbs_table_placeholder_foo
{
    column_placeholder<bool>::type b;
    column_placeholder<char>::type c;
    column_placeholder<double>::type d;
    column_placeholder<float>::type f;
    column_placeholder<std::string>::type s;
};

このようなコードを生成できる。

具体的にコード生成をするリフレクションを使ったコードは、論文を参照。

[PDF注意] N4453: Resumable Expressions

resumable expressionの提案。

Urbana会議以前は、コルーチンとresumable関数というやや似通った性質をもつ2つの機能が提案されていた。そして、2つの機能を統一することで合意していたのだが、スタックレスとスタックフルとはまったく別々の需要を満たすための機能であって、多少の共通項があるとはいえ、独立した機能として別々に議論すべきだということになった。これにより、スタックフルコルーチンは、純粋にライブラリ実装にして、スタックフルコルーチンをライブラリ実装できる軽いスタックレスコルーチンをコア言語に導入すべきだという方向に話が進んだ。統一の話がなくなったのであるから、awaitとかyieldなどのキーワードは不要となった。

resumable expressionsは、constexpr関数にヒントを得て設計された。

constexpr関数は、関数をconstexprであると明示的にキーワードで修飾する。そして、任意の式で呼び出すことができる。

constexpr int twice( int x ) { return x * 2 }

constexpr int a = twice( 2 ) ;
int b = twice( 4 ) ;

普通の式で使うには、関数はconstexpr関数であるかどうかを気にする必要はない。resumable expressionsもこのような設計を参考にしている。

まず、resumableキーワードを用いて、resumable関数を宣言する。

resumable void print_1_to_n( unsigned int n )
{
    for ( unsigned int i = 1 ; i <= n ; ++i )
    {
        std::cout << i << std::endl ;

        break resumable ;
    }
}

中断するところで、break resumableと記述する。

あとは、resumable式から使うだけだ。

int main()
{
    resumable auto r = print_1_to_n( 10 ) ;

    while( !r.ready() )
    {
        std::cout << "resuming ... " ;
        r.resume() ;
    }
}

resumable式は、以下の形で使う。

resumable auto r = expr ;

このときのrの型Rは実装が生成する。Rには、result_type, ready(), resume(), result()がある。

yeildやawaitなどは、resumable式を使ってライブラリで実装できる。

だいぶC++らしい小さなコア言語機能の提案だ。これは悪くなさそうだ。

N4454: SIMD Types Example: Matrix Multiplication

N4184で提案されているSIMD演算を使って行列の掛け算を実装する論文。利用例の例示として書かれた。

N4455: No Sane Compiler Would Optimize Atomics

「まともなコンパイラーはアトミックを最適化したりしない」という都市伝説は間違っていることを説いている論文。

コンパイラーはアトミックも最適化する。この論文では、最適化の例を紹介している。

コンパイラーは、プログラムをas-ifルールで最適化できる。これは、コンパイラーは、オリジナルのコードと挙動が変わらなければ、特定のアトミックを強くしたり弱くしたりできる。

最適化の例として、たとえば、アトミックの中間の値をすっ飛ばす。

void inc(std::atomic<int> *y) {
  *y += 1;
}

std::atomic<int> x;
void two() {
  inc(&x);
  inc(&x);
}

このようなコードを、最適化の結果、以下のようにしてもよい。

std::atomic<int> x;
void two() {
  x += 2;
}

他にも、x86においては、lock付きadd/subをlock付きinc/decに置き換えることも可能だ。

また、アトミックのまわりの処理も最適化の対象になる。

int x = 0;
std::atomic<int> y;
int dso() {
  x = 0;
  int z = y.load(std::memory_order_seq_cst);
  y.store(0, std::memory_order_seq_cst);
  x = 1;
  return z;
}

このコードは、以下のように最適化できる。

int x = 0;
std::atomic<int> y;
int dso() {
  // デッドstore操作の除去
  int z = y.load(std::memory_order_seq_cst);
  y.store(0, std::memory_order_seq_cst);
  x = 1;
  return z;
}

上と似ている以下のようなコードは、

int x = 0;
std::atomic<int> y;
int rlo() {
  x = 0;
  y.store(0, std::memory_order_release);
  int z = y.load(std::memory_order_acquire);
  x = 1;
  return z;
}

以下のように最適化できる(ただし、現在LLVMはこの最適化ができない)

int x = 0;
std::atomic<int> y;
int rlo() {
  // デッドstore操作の除去
  y.store(0, std::memory_order_release);
  // 冗長なloadの除去
  x = 1;
  return 0; // 保存された値がここまで到達
}

loadが除去されるのは、他のスレッドとの同期がないためだ。releaseの次にaquireがきているが、コンパイラーはstoreされた値が改変されないので、その次のloadは冗長だと判断する。

なんだかこの最適化は極めて怖い。

以下のようなコードは変換されない。

int x = 0;
std::atomic<int> y;
int no() {
  x = 0;
  y.store(0, std::memory_order_release);
  while (!y.load(std::memory_order_acquire));
  x = 1;
  return z;
}

論文は最後に、それぞれの立場に対して意見を述べている。

標準化委員会へ:これらの最適化が起こらないと仮定するな。むしろ推奨しろ。よりハードウェアに近い最適化ができる既存の方法を標準化しろ。同期と並列実行をより簡単にできて、失敗しにくいライブラリを提供しろ。

開発者へ:アセンブリを捨てろ。そんなに最適化できないし、そもそもコードを書いている時点で存在するアーキテクチャにしか対応できない。コンパイラーのパフォーマンスが期待通りでないのならばバグ報告を投げろ。標準化委員会に同期と並列実行を実現できる方法を提案しろ。ThreadSanitizerのようなツールをt受かってコード中の競合を発見しろ。

ハードウェアベンダーへ:ハードウェアの能力を示せ。

コンパイラー開発者へ:さっさと仕事にもどれ。まだ最適化できることと・・・ぶち壊れるコードは山ほどある。利用者がいいコードを書けるようにしろ。コンパイラーはアトミックの正しくない使い方を検出したならば、メッセージを吐くべきだ。

N4456: Towards improved support for games, graphics, real-time, low latency, embedded systems

N2771のEASTLの論文を考察している。現在のSTLに足りないもの、やや古い論文なので、現代ではもう意味がなくなったものなどを列挙している。

N4457: C++ Standard Core Language Active Issues
N4458: C++ Standard Core Language Defect Reports and Accepted Issues
N4459: C++ Standard Core Language Closed Issues

コア言語に対する問題集。

ドワンゴ広告

この記事はドワンゴ勤務中に書かれた。

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

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

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

シェアハウスとタバコと暴力

以下のようにまとめられている。

「煙草の煙から自身を守るためなら暴力もやむを得ない」のか - Togetterまとめ

何を書いても火に油を注ぎ、単に第三者の余興となるだけなのだが、私(江添)の視点で書いておこうと思う。

まず、妖怪ハウスの間取りについて説明しなければならない。妖怪ハウスにはリビングがあり、その横に和室がある。私はこの和室に住んでいる。リビングと和室に面してベランダが設置してある。このリビングと和室に面したベランダは禁煙である。かつ、室内に煙草の煙が流れこむことや、室内にタバコの吸い殻や灰をばらまくのも、極めて迷惑であり常識がない行為であると同意がなされている。

妖怪ハウスには、喫煙所として定められた、別のもっと大きなベランダがある。

28日の夕方過ぎ、なぜか自室の和室が煙たいことに気がついた。臭いは窓の外からやってくるようである。見ると、リビングと和室に面したベランダでタバコを吸っている見知らぬ人間が二人いる。私はタバコを即座に中止するように、また、家から出て行くように言った。そんなところで煙を発生させる非常識な人間に家に上がることを許可したくはない。

さて、この失礼な二人は、妖怪ハウスの住人である平林の連れてきた客であることが明らかとなった。私は、何故そのような非常識な客を連れてきたのか、非常に迷惑していると平林に言った。この時、私はかなり怒っていたので、声は自然とどなり声になってしまった。平林の返答は、その語句を具体的に覚えていないが、「そう、残念だったね」などと言った極めて責任感のないものであったと記憶している。私は怒りのあまり机をけった。

この後、つかみ合いに発展した。平林に発生した結果が以下の通り。

私側としては、右目の下と首筋に引っかき傷を得た上に、メガネのフレームが曲がった(私のメガネは樹脂製ではなくチタン製なので、割れることはなかった。)

目撃者によると私から手を出したとのことだが、これは間違いで、平林から手を出してきたのだ。私は手を振りほどこうとしていただけだ。私の背の後ろから観測したので、平林の伸ばす手が見えなかったのだろう。メガネを割ったのは意図的ではなく、クビをしめられている最中になんとか身を離そうともがいた結果だ。

なぜか私が殴ったと思い込んでいる者もいるようだが、(メガネが正面から殴られて割れたように見えるからだろうか)私は殴っていない。なんとか首を絞められているのを振りほどこうとしただけだ。

ぐっちょむについて

ぐっちょむはこの場に居合わせておらず、後から私以外の観測者から話を聞いて私に論争をふっかけてきた者である。他人に受動喫煙をさせる可能性のある場合はタバコを吸わないのが当然であるべきなのだが、ぐっちょむはそれに同意していない。ぐっちょむは伝聞を元に尾ひれをつけて事実と異なることを主張するのと、同じ話題を延々とループするので、話が成立しない。ぐっちょむはドラッグをやっているという話があるので、私は関わりたくない(ドラッグを引き合いに出したのは、まともに会話が成立しないからである。)

住人の一人が警察を呼んだというのは、はるしにゃんが私にラップトップを壊されたと言いがかりをつけたことだ。私には全く身に覚えがないばかりか、その壊れたラップトップが存在するのかも知らない。「説明できないということは私が犯人だ」などという謎の論理を持ちだされても仕方がない。

今後

私に受動喫煙させる失礼な客を連れてきた挙句に、掴みかかってくる人間と同居はできないので、私は次の物件を見つけ次第妖怪ハウスを出て行く。7月中に物件を見つけたいものだ。

2015-06-29

そんなにセキュアではないお粗末なNoScriptのホワイトリスト(修正済み)

The NoScript Misnomer - Why should I trust vjs.zendcdn.net? | The Hacker Blog

「俺の環境はNoScriptを入れてるからセキュアだぜ」などと豪語する勘違い野郎に冷水を浴びせるために、デモ可能なNoScriptを迂回する方法を探していた人間が、NoScriptのお粗末なホワイトリスト指定を発見したそうだ。

NoScriptはデフォルトで、非常に有名なドメイン名(CDN、超有名Webサイト等)をホワイトリストに入れている。

しかし、このドメイン名をホワイトリストは、サブドメインもホワイトリストに入ってしまうという問題がある。もしサブドメインとページ内容を第三者が自由に作成できるようなドメインが入っていれば、信頼が破綻する。

さて、リンク先の著者は、まずホワイトリストに入っているドメインのWebサイトのXSS脆弱性を探そうと考えた。ところが、それをするまでもなく、ある重大な発見をした。

なんと、ホワイトリストに入っているドメイン名の一つ、zendcdn.netが誰にも所有されることなく空いていたのだ。

とりあえず同ドメイン名を10.69ドルで購入してJavaScriptを仕込んでみると、見事NoScriptが迂回できた。

しかし何故誰も所有していないドメイン名がホワイトリスト入りされているのか。

どうやら、ユーザーが有名なCDNをホワイトリストに追加するようNoScriptに要請したようだ。

InformAction Forums • View topic - JavaScript CDNs to add to whitelist

NoScript開発者のGiorgio Maoneに、この脆弱性について連絡を撮ったところ、彼の返事と対応は極めて迅速であり、一時間もしないうちに修正パッチがサイト上に上がり、2日後にはアップデートが全NoScriptユーザーに配布されたという。

リンク先の人間は、NoScriptユーザーはホワイトリストを確認し、自分が信頼しないドメインは取り除くべきであると書いている。

2015-06-23

C++標準化委員会の文書 2015-04 pre-Lenexaのレビュー: N4440-N4449

N4440: Feature-testing recommendations for C++

機能テストマクロの提案。C++17機能に対応するマクロが追加されている。

[PDF注意] N4441: SG5: Transactional Memory (TM) Meeting Minutes 2015-03-23 and 2015-04-06

トランザクショナルメモリーの会議の議事録。

N4442: Default argument for second parameter of std::advance (Rev. 1)

std::advanceの第二引数にデフォルト実引数として1を追加する提案。

std::advance( iter, 1 ) ;

のかわりに、

std::advance( iter ) ;

と書ける。

N4443: Introducing alias size_type for type size_t in class std::bitset (Rev. 1 )

std::bitsetにネストされた型名™size_typeを追加する提案。

他のコンテナーとあわせることで、ジェネリックなコードやポータブルなコードを書きやすくなる。

N4444: Linux-Kernel Memory Model

現行のC/C++のメモリーモデルがLinuxカーネル開発者のお気に召さなかった問題を受けて、Linuxカーネルのメモリモデルをまとめた文書。

Linuxカーネルのメモリモデルについて解説した文書。前回のN4374からの変更点はREAD_ONCE()とWRITE_ONCE()マクロの解説。

N4445: Overly attached promise

promiseに共有状態を管理するためのリソースを破棄させるメンバー関数、resetとreleaseの追加。

あるpromiseオブジェクトを使ったとする。

std::future<int> f()
{
    std::promise<int> p ;
    auto future = p.get_future() ;
    p.set_value( 42 ) ;

    // これ以降、promiseは使わない

    // 何らかの時間のかかる処理

    // promiseオブジェクトが破棄される
    return future ;
}

上記の例では、何らかの時間のかかる処理をしているあいだ、promiseオブジェクトは生きている。すると、共有状態を維持するためのリソースも破棄されないまま維持されてしまう。リソースの制約の厳しい環境では、このような不必要なリソースを早期に破棄したい需要がある。

現行規格でも、ムーブを使えばリソースの破棄は可能だ。以下のような方法でpromiseのオブジェクトpをムーブさせてリソースを開放させられる。

p = std::promise<int>{} ; // これでもよい。
std::promise<int>( std::move(p) ) ; // こちらのほうがわかりやすい

しかし、どちらも冗長でわかりにくい。N4445では、promiseから共有状態のリソースを破棄するためのメンバー関数、resetとreleaseを追加する提案をしている。

releaseは共有状態の破棄。resetは空のpromiseとswapをしたかのように働く。

N4446: The missing INVOKE related trait

ある型がある並びの引数の型で関数呼び出しできるかを調べるis_callableの提案。

より厳密に説明すると、N4169で入ったinvokeが未評価オペランドにおいて合法かどうかを確かめる。is_callableの提案。

template <class, class R = void> struct is_callable; // not defined
template <class Fn, class... ArgTypes, class R>
  struct is_callable<Fn(ArgTypes...), R>;

たとえば、is_callable< F ( A0, A1, A2 ) >::valueは、std::invoke< F, A0, A1, A2>が合法の場合にtrueを、substitutionに失敗する場合にfalseを返す。

void f( std::string, std::vector ) ;

constexpr bool b = std::is_callable_v< decltype(&f) ( std::string, std::vector) > ;

[PDF注意] N4447: From a type T, gather members name and type information, via variadic template expansion

「型Tからメンバー名と型情報をVariadic Templates展開で得る」という、なんとも説明的で実用的なタイトルの提案論文。内容として派生的リフレクション機能だ。

その提案内容も極めて実用的だ。typedef<T, C>, typename<T, C>, typeid<T, C>という文法を追加する。Tはクラス型で、Cはコンセプトか型名で、constexpr operator ()でbool値を返す。trueを返したメンバーだけが展開される。

その動作は、サンプルコードを見たほうが良い。


using namespace std;

namespace ns {
    struct X {
        int x, y;
    };
}

vector<std::string> names{ typeid<ns::X, is_member_object_pointer>... };

tuple<typename<ns::X, is_member_object_pointer>...>
    mytuple = make_tuple(typedef<ns::X, is_member_object_pointer>...);

最後の二行のコードは、コンパイラーによって以下のように変換される。

vector<string> names { "x","y" };

tuple<ns::X::int, ns::X::int>
    mytuple = make_tuple(
        &ns::some_struct::x,
        &ns::some_struct::y);

この提案は新しいキーワードを必要としないしASTコントロールも必要としないし特別なコンパイラーマジックやライブラリーも必要としない。

用途は、シリアライゼーション、メタプログラミング、型変換、イベント駆動開発。テスト駆動開発、GUIプロパティエディター、データベースオブジェクトのマッピングインターフェース、ドキュメントの自動化、コンセプトの自動チェック、コンストラクターのリフレクション。

まあ、便利だとは思うのだが、なんとも低級な機能だ。

N4448: Rounding and Overflow in C++

演算の結果の丸めとオーバーフローの挙動を規定できるライブラリの提案。

丸めモードにはすでにfenv.hがあるが、これは不十分だとしている。

丸めモードに対しては、以下の挙動が提案されている。

enum class rounding {
  all_to_neg_inf, all_to_pos_inf,
  all_to_zero, all_away_zero,
  all_to_even, all_to_odd,
  all_fastest, all_smallest,
  all_unspecified,
  tie_to_neg_inf, tie_to_pos_inf,
  tie_to_zero, tie_away_zero,
  tie_to_even, tie_to_odd,
  tie_fastest, tie_smallest,
  tie_unspecified
};

fastestは実行速度優先。smallestは誤差最小優先。

関数には、convertと、divideとrshiftが用意されている。

オーバーフローには、以下の挙動が提案されている。

enum class overflow {
  impossible, undefined, abort, exception,
  special,
  saturate, modulo_shifted, modulo_dividend, modulo_divisor, modulo_positive
};

impossible: オーバーフローは起こりえない。これを指定したプログラムは厳格な検証によりオーバーフローがー起こりえないことを証明すること。

undefined: オーバーフローはまれにしか起こらないので考えなくてよい。

abort: オーバーフローが起きたらabortする。検出が必要。

exception: オーバーフローが起きたら例外を投げる。検出が必要。

special: オーバーフローが起きたら特別な値を返す(IEE浮動小数点数など)

saturate: オーバーフローが起きたら妥当な範囲の値で最も近いものを返す。

オーバーフローを指定できる関数には、convertの他に、limit( lower, upper value )とその派生版と、lshiftが提案されている。

最後に、丸めとオーバーフローを両方取るconvertとbshiftが提案されている。

N4449: Message Digest Library for C++

暗号に使える強度を持ったハッシュ関数ライブラリの提案。

「設計はPythonのhashlibモジュールから恥ずかしげもなくパクった」

まだ文面が不完全だが、Pythonのhashlib風のインターフェースになっている。

ドワンゴ広告

どうやら弊社では、自社から出た最新の参考書を自腹で買う社員が多いようだ。他ならぬKnuth本ならば仕方あるまい。しかし、ご存命のうちに完成するのだろうか。

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

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

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

江添ボドゲ会@7月

江添ボドゲ会@7月 - connpass

7月4日の土曜日に、野方でボードゲーム会を行う。参加費千円。今回はカレー。

7月には引越しを終えて新居でボドゲ会ができるかと見込んでいたのが、どうやらまだ時間がかかりそうなので、今回も野方の妖怪ハウスで行う。

来月こそは引越しをしたい。

2015-06-22

C++標準化委員会の文書 2015-04 pre-Lenexaのレビュー: N4430-N4439

N4430: Core Issue 1776: Replacement of class objects containing reference members

Core Issues 1776を解決するための文面変更。

ストレージに構築されたクラスオブジェクトを破棄して、そのストレージ上にまたクラスを構築するとき、もとのクラスにconstなリファレンスのデータメンバーがあった際などに、規格の範囲内でoptionalが実装できない制限を緩和する。

またこの文面では、std::launderというアドレスロンダリング用の関数テンプレートが追加されている。

[PDF注意] N4431: Working Draft, Standard for Programming Language C++

最新のC++標準規格のドラフト

N4432: Editor's Report -- Working Draft, Standard for Programming Language C++

N4431に加えられた変更点。今回は大きな変更はない。

N4433: Flexible static_assert messages

static_assertの警告メッセージに、文字列リテラルだけではなく、文脈上const char*, const wchar_t*, const char16_t*, const char32_t*に変換できる定数式を許可しようというもの。

const char * msg = "hello" ;
static_assert( false, msg ) ;

これは現在提案中のコンパイル時文字列ライブラリと組み合わせると強力に使える。

template < typename ErrorCode, typename Message
constexpr auto msg( ErrorCode code, Message message )
{
    return "My Lib: error code "S + code + ": "S + message ;
}

static_assert( sizeof(int) == 4, msg( "001"S, "This library assumes that sizeof(int) is 4." ) ) ;

[PDF注意] N4434: Tweaks to Streamline Concepts Lite Syntax

GCCのコンセプトブランチで、N4377で提案されているコンセプトを実装してみた経験から、現在の提案に対する改良の提案。

boolは冗長。

コンセプトは常に真偽値を返す。conceptキーワードはある。なぜboolキーワードが必要なのか。

template < typename T >
concept bool C() { return ... ; }

template < typename T >
concept bool C = ... ;

明らかにboolキーワードは冗長なので、省略できるようにすることを提案している。

関数コンセプトと変数コンセプトは冗長

コンセプトには、変数コンセプトと関数コンセプトが存在する。これらは定義する文法が異なる他にも、requires-clauseでの呼び出し方も異なる

template &lt; typename T &gt;
concept bool C1() { return ... ; }

template &lt; typename T &gt;
concept bool C2 = ... ;

template < typename T >
requires C1<T>() && C2<T> ;
void f( T ) ;

関数コンセプトを利用するには、冗長な()を余計に記述しなければならない。かつ、コンセプトの利用者は、あるコンセプトが変数コンセプトなのか関数コンセプトなのか把握していなければならない。そんなことはどうでもいいことであり人間が把握すべきことではない。

そもそも、コンセプトに2種類の文法が存在するのは、歴史的なアーティファクトに過ぎない。まだ変数テンプレートがなかった時代に関数コンセプトのみがあり変数テンプレートができたためにその文法を流用した変数コンセプトができたのだ。今の提案では、変数コンセプトのみを使っているので、関数コンセプトは不要だ。そもそも、関数コンセプトは利用時に冗長な()を必要とするのみならず、定義時にも冗長な()やreturnを必要とする。

変数コンセプトに統一することを提案してる。

コンセプトがコンセプト以外の場所で評価できないのは冗長なコードを生む。

ある型TがあるコンセプトCを満たすかどうかを調べるにはどうするか。現行のコンセプトでは、コンセプトはrequires-clauseでしか使えないとされている。すると、ある型がコンセプトを満たすかどうかのbool値を取得するためには、コンセプトそれぞれに対して、以下のような冗長で機械的なラッパーを書かなければならない。

template< class T >
constexpr bool
satisfies_C( ) { return false; }
template< C T > // equivalent to requires C<T> for class T
constexpr bool
satisfies_C( ) { return true; }

こんなコードを書かせるのは明らかに間違っている。コンセプトはbool値を期待するあらゆる文脈で使えるようにすべきだという提案。

どれも正しいように思われる。

[PDF注意] N4435: Proposing Contract Attributes

属性を使った契約プログラミングをサポートする文法の提案。precondition, postcondition, invariantsをサポート。

契約プログラミングに関する提案論文は多数出ているが、実際の文法を考察した提案論文は少ない。この提案論文では、C++11に追加された属性を使った文法を考察している。

まず、公式の機能に属性を使うのが正しいのかという議論がある。アライメント指定やoverrideは、属性でサポートすべきではないとして、キーワードが与えられた。N2761では、属性を使うべき状況として、「型システムに影響を与えず、属性の有無によってプログラムの意味に影響を与えない」ことを要件として提案している。契約は型の一部ではない。規格準拠の実装は、契約を単に受理だけして無視してもよいものである。これを考えると、契約を属性でサポートするのは理にかなっている。

提案では、preconditionとして、[[ pre: expr ]]、postconditionとして、[[ post: expr ]]という文法を提案している。これらはどちらも、関数、関数テンプレート、メンバー関数、メンバー関数テンプレートに付与することができる。

属性を記述する箇所として、論文は、現在の規格には存在しない、関数の宣言の後に記述できるように属性を拡張すべきだという提案をしている。

template< class FwdIterator, class T >
bool
std::binary_search( FwdIterator first, FwdIterator last, T const& value)
[[ pre:(std::is_sorted(first, last)) ]];

この理由は、関数の引数名を契約チェック式のスコープに含めたいためである。

postconditionの例は以下の通り。

template< class RandomAccessIterator >
void
std::sort( RandomAccessIterator first, RandomAccessIterator last );
[[ post:(std::is_sorted(first, last)) ]];

postconditionは、関数がreturn以外の方法(例外、longjmp等)で戻った場合はチェックされない。

この提案では、他の契約プログラミング提案と違い、invariantsを含んでいる。invariantsは、preconditionとpostconditionを組み合わせた効果がある。これは、[[ inv : expr ]]という文法で記述できる。

invariantsは、関数の他に、クラスとループ構文と変数に指定できる。

クラスに付与した場合、クラスのpublicとprotectedなメンバー関数に契約チェックがかかる。privateなメンバーにはかからない。また、コンストラクターには、postconditionチェックのみがされる。デストラクターには、preconditionチェックのみがされる。これは、コンストラクターは未初期化の状態から値を設定するものであり、デストラクターは実行後に値を不定な状態にするものだからである。

ループ構文にinvariantsを付与した場合、ループの実行毎に契約チェックが入る。

変数にinvariantsを付与した場合、変数の構築時と変更時に契約チェックが入る。

[PDF注意] N4436: Proposing Standard Library Support for the C++ Detection Idiom

N3911で追加されたvoid_tを利用したdetection idiomのためのライブラリの提案。

N3911では、以下のようなエイリアステンプレートvoid_tを標準ライブラリに追加した。

template < typename ... >
using void_t = void ;

void_tは、任意個の型引数を受け取って、必ずvoid型を返す。このような単純なものに何の価値があるのかというと、SFINAEで活用できる。

template < typename, typename = void_t<> >
struct has_type
    : std::false_type { } ;

template < typename T >
struct has_type< T, void_t< typename T::type > >
    : std::true_type { } ;

このように、void_tには任意個の型を渡せるので、SFINAEの文脈で使ってやれば、ネストされた形名typeを持っているかどうかでコンパイル時分岐ができる。

decltypeを使えば、式を書くことも可能だ。

template < typename, typename = void_t<> >
struct is_pre_incrementable
    : std::false_type { } ;

template < typename T >
struct is_pre_incrementable< T, void_t< decltype(++std::declval<T &>()) > >
    : std::true_type { } ;

論文では、このような用法をdetection idiomと名づけている。

Jonathan Wakelyによれば、libstdc++で_GLIBCXX_HAS_NESTED_TYPEマクロをvoid_tを使った上記の実装に置き換えたところ、従来の実装に比べて、コンパイラーフロントエンドのメモリ消費量とコンパイル時間が向上したとの報告がある。

現在、規格の文面がpartial specializationでSFINAEが働くかについて曖昧であるという議論が起こっているが、SFINAEが働く方向に意見が向かっている。

論文筆者はdetection idiomを使って既存の標準ライブラリを再実装する実験を行った。この結果、冗長なコードの重複が至るところでみられた。論文筆者は、再実装の過程で、この冗長なコードを隠匿する方法を発見した。論文はその手法をメタ関数コールバック(metafunction callback)と名づけている。そのフレームワークを標準ライブラリに提案している。

このライブラリを使えば、上のhas_typeとis_pre_incrementableは以下のように書ける。

// メタ関数コールバック
template < typename T >
using has_type_op = typename T::type ;

template < typename T >
constexpr bool has_type_v = is_detected_v< has_type_op, T >


// メタ関数コールバック
template < typename T >
using is_pre_incrementable_op = decltype( ++std::declval<T &>() ) ;

template < typename T >
constexpr bool is_pre_incrementable =is_detected_v< is_pre_incrementable_op, T > ;

メタ関数コールバックは、テンプレートである。テンプレートをそのまま渡すと、中でテンプレート実引数を渡す。もしsubstitutionに失敗するか成功するかが実行結果だ。戻り値は、失敗したという情報か、成功した場合のテンプレートの型だ。成功した場合、is_detectedの::valueはtrueになり、::typeはメタ関数コールバックにテンプレート実引数を渡した型になる。失敗した場合、::valueはfalseとなり、::typeはvoid型になる。。メタ関数コールバックにはエイリアステンプレートを使うのが一般的になるだろう。

上記の実装は、変数テンプレートを使っている。クラステンプレートで従来のメタ関数を実装するには、std::true_typeかstd::false_typeを返す必要がある。これには、detected_orが使える。これは、失敗した場合の型を指定できる。

template < typename T, typename = typename T::type >
using has_type_op = std::true_type ;

template < typename T >
struct has_type :
     detected_or_t< std::false_type, has_type_op, T > 
{ } ;

他には、メタ関数コールバックのsubstitutionに成功し、かつ、型が指定した型かどうかを返すis_detected_exactと、それに似ているが、型が指定した型に変換可能かどうかを返すis_detected_convertibleが提案されている。

また、voidもメタ関数コールバックの戻り値としてふさわしい場合に使える。nonesuchという型が提案されている。

これはいいライブラリだ。標準に入るべきである。

[PDF注意] N4437: Conditionally-supported Special Math Functions, v3

TR1に存在した数学関数を、条件付きサポートとして規格に入れる提案。実装しなくても規格準拠である。

TR1はC++11に追加されたが、数学関数だけは入らなかった。その理由は、これらの関数の実装をすべてのC++コンパイラーベンダーに強いるのは負担であるし、それに、「どうせ数学関数が実装されていなくても、ユーザーはうちの会社にカチこんできたりしない」からであった。

この提案で<cmath>に追加される関数は、acosh, asinh, atanh, cbrt, copysign, erf, erfc, exp2, expm1, fdim, fma, fmax, fmin, hypot, ilogb, lgamma, llrint, llround, log1p, log2, logb, lrint, lround, nan, nearbyint, nextafter, nexttoward, remainder, remquo, rint, round, scalbln, scanbn, tgamma, truncと、末尾がfのfloat版と、末尾がlのlong double版。また、マクロと<fenv.h>(浮動小数点演算の例外状態を取得できるライブラリ)も入る。

[PDF注意] N4438: Industrial Experience with Transactional Memory at Wyatt Technologies.

Wyatt Technologies社によるトランザクショナルメモリーの知見。

トランザクショナルメモリーは長年研究されているが、現場で使用した知見はなかなかない。Wyatt Technologies社は、Haskellを参考にしたトランザクショナルメモリーをライブラリで実装して、現場の製品に使用した。

トランザクションの中で、すでに他のトランザクションが行われたかどうかをチェックできる。他のトランザクションが行われた場合、即座にトランザクションは再実行される。

短いトランザクションが連続的に発生するため、長いトランザクションがいつまでたってもコミットできない飢餓状態という問題がある。実装では、許容可能なコンフリクト数を設定可能にしている。許容限度に達した場合、トランザクションの実行を諦めて例外を投げるか、実行ロックをかけるかが選べる。実行ロックとは、そのトランザクションがコミットされるまで、他のトランザクションを許さない排他的なロックである。これにより飢餓状態を解消する。

このトランザクショナルメモリーの実装は、トランザクションをネストできる。ネストできない場合、すでにトランザクションの中であるかどうかを把握しなければならない。Haskellではネストできないので、この点が違っている。

論文に書かれている内容では、トランザクションをネストしたり、トランザクションの中からトランザクションの状態をみたり操作したりできる実用本位の機能が多い。

論文は、現場にトランザクショナルメモリーを導入した明示的にロックを使わないコードの結果は上々であったと報告している。トランザクショナルメモリーを現場に持ち込むことの問題として、新たに雇用する人間にトランザクショナルメモリーの経験のある人材がいないということがあるが、新しく雇ったプログラマーもすぐに覚えることができたと報告している。

実装ではひとつのグローバルなmutexを使ったそうだ。

結論として、トランザクショナルメモリーの経験は素晴らしかった。TMの理論上の問題点は、飢餓状態と副作用にあるが、どちらの問題も対処は難しくなかった。副作用の問題を型システムで対処できれば理想だが、ライブラリベースの実装では無理だ。ロックベースのプログラミングのために必要なコードが複雑になるコストを考えれば、副作用の問題は十分に許容できる範囲だ。

また、retry(トランザクションの中で呼び出して、ある値が変更されるまでスリープする機能)と、after(トランザクションの中で呼び出して、コミット後に行われる副作用を登録する)機能を多用したので、この機能なしではトランザクショナルメモリーは使いづらいとしている。

また、この報告の例は、極めてトランザクショナルメモリーに優しい環境であった。厳しいパフォーマンス上の制約もないし、リアルタイム性も必要ないし、ゲームにおける高フレームレートのような要件もないし、株取引でもない。パフォーマンスが必要な部分は装置から入力を読みだす部分だけで、そこはトランザクショナルメモリーではなくてロックフリーキューを用いた。

[PDF注意] N4439: Light-Weight Execution Agents Revision 3

スレッドよりも軽い、制約の多い、実行媒体(Execution Agent)のセマンティクスを定義している論文。

実行媒体とは、スレッドの他にも、SIMDやGPGPUのようなもっと制約の多い実行媒体を想定している。

ドワンゴ広告

先週、ボーナスがでたので、弊社のお金ない勢が銀座のさくら水産でオフ会(予算600円程度)を行った。そこでは浪費しすぎて給与が右から左にクレジットカードの支払いで消えていく社員たちが卵かけご飯を食べながらお金ない自慢をしあっていた。

ところで、同日同時刻に、弊社のお金ある勢もザギンのシースー屋(ただし予算1000円程度)でオフ会を行ったそうだ。そこで出た結論とは、資産を即座に3倍に増やしたいのであれば、博打しかないとのことだそうだ。

どうやら、弊社のお金ある勢とお金ない勢は、給与額よりは浪費癖で決まるようだ。

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

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

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

2015-06-21

x86のmov命令はチューリング完全

世の中には様々なチューリング完全なシステムがある。

本の虫: うっかりチューリング完全になっちゃったもの

x86のMMUはチューリング完全である。

BGP(Border Gateway Protocol)はチューリング完全である。

http://vanbever.eu/pdfs/vanbever_turing_icnp_2013.pdf

さて、x86の命令セットは極めて複雑で冗長であることが知られている。なんと、mov命令はチューリング完全であるそうだ。

http://www.cl.cam.ac.uk/~sd601/papers/mov.pdf

もちろん、mov命令でメモリ上に任意のコードを書いて実行させればチューリング完全になるが、論文ではそのようなコード生成や自己書き換えによるイカサマは行っていない。また、アドレスモードもたいていのRISCにあるようなものしか使っていないという。

x86のmov命令だけを使った後、無条件jumpで先頭に戻るループを実行することで、チューリング完全になるそうだ。

レジスターに入っている2つのアドレスA, Bが正しいかどうかは、アドレスAにある値をストアして、その後にアドレスBに別の値をストアして、そしてアドレスAの値をみると、AとBが等しいかどうかがわかる。レジスターRiの値にアドレスA入っていて、レジスターRjの値にアドレスBが入っている場合、レジスターRiとレジスターRjが等しいかどうかは、以下のようにしてわかる。

mov [Ri], 0
mov [Rj], 1
mov Rk , [Ri]

このコードはアドレスの指し示すメモリ内容を破壊するが、このアドレスはシンボル用に確保しているものなので問題はない。

比較の結果を0か1で得ることによって、Rkを使って2要素が入ったテーブルを参照することによって、2つのアドレスから選択をすることができる。レジスターNにアドレスNが入っていて、レジスターRi, Rjに選択される2つのアドレスが入っていて、Rkに比較の結果が0か1で入っている場合、以下のようにしてRi, Rjのどちらかのアドレスを選択してRlに入れることができる。

mov [N], Ri
mov [N+1], Rj
mov Rl , [N + Rk ]

この論文を元にした、MOV命令のみを使うコードを生成するコンパイラー、xoreaxeaxeax/movfuscatorがGitHubで公開されている。これはBrainfuckコンパイラーだが、BFBASICを併用することで、BASICからBrainfuckに変換できるので、BASICからmov命令(と末尾の銭湯に戻る無条件jump)のみのコードを生成するとしている。

なお、将来的にはCコンパイラーを実装するとしている。

2015-06-16

予備自衛官の訓練に出頭した

12日から16日までの5日間、予備自衛官の訓練のために朝霞駐屯地に出頭していた。5日間ネットから姿を消したので、何故か私の死亡説が流されていたようだ。

出頭して気がついたのだが、もう予備自衛官になって5年たった。もうそんなになるのかと、少し驚いた。

筆者が予備自衛官であることを人に話すと、最もうらやましがられるのは、銃を撃てることである。。筆者は銃にあまり興味はないのだが、とある人は銃を撃つために毎年のように海外に旅行しているそうだ。曰く、「銃を撃ってそのうえ金がもらえるとはなんといい身分だ」と。今回の射撃は、あまりいい成績ではなかった。

そういえば、今回の訓練の時に気がついたのだが、自衛隊の駐屯地は、筆者の知る限り、東京で唯一のまともな飯が食える場所である。[参考:本当に東京の飯はまずい]

ところで、去年の秋にも訓練に参加したので、今回は半年ぶりになる。この半年間、ボルダリングをしていた成果なのか、10kgほど握力が上がっていた。

来年はいつ参加しようか。

2015-06-11

Duqu 2.0

世間はKaspersky Lab内にStuxnetやDuquの系譜である発展版のマルウェアが仕掛けられたニュースで持ちきりだ。

The Mystery of Duqu 2.0: a sophisticated cyberespionage actor returns - Securelist

Duqu 2.0: Reemergence of an aggressive cyberespionage threat | Symantec Connect Community

Duqu2.0はStuxnetやDuquと共通のコードがみられ、出所が同じであると推測されている。またその規模から、(アメリカ合衆国かイスラエル)国家政府の支援を受けていると推測されている。

Kaspersky Lab内に仕掛けられ、Kaspersky Labによって発見されてDuqu 2.0と命名されたこのマルウェアは、Windowsの作成当時のゼロデイ脆弱性を利用して、カーネルメモリ内のみに常駐し、ストレージ上に痕跡を残さないことで、検出を難しくしているという。

創始者のKaspersky本人は、Forbesの寄稿で、セキュリティ研究会社を狙うのは割に合わないと書いている。

Why Hacking Kaspersky Lab Was A Silly Thing To Do

曰く、そもそも連中はうちに侵入して何をしたいのだ? うちの製品のソースコードとかノウハウを盗みたいのか? しかし、日進月歩で技術革新が進むこの業界で、今この瞬間の技術情報を盗んでも無意味だ。そもそも、うちは商業企業である。うちは政府とも契約を結んでいるし、国家機密に関わるような場所に納品する際にはソースコードの提出だってしている。技術情報が欲しければ普通に顧客としてくればいいではないか。国家犯罪を暴いているうちに幼稚なエゴでもって仕返しがしたかったのか? そのために何百万ドルもの血税を無駄にしているのか。意味がわからない。と。

しかし、アメリカ合衆国かイスラエル国家の支援を受けた団体が、ロシア国家の支援を受けた企業を攻撃するのはなかなかわかりやすい構図ではある。

2015-06-09

C++標準化委員会: 2015-04 pre-Lenexaのレビュー: N4420-N4429

[PDF注意] N4420: Defining Test Code

C++の型システムにテストを追加する提案。

テストは重要である。C++標準はテストをサポートする機能を提供していない。そのため、C++プログラムはサードパーティのマクロ満載のお互いに非互換なテスト用フレームワークを使わなければならない。

この提案は、テストコードと非テストコードをプログラム中で明確に分断するための機能をテスト修飾子を提案している。

void f() test ; // テスト用コード

void g() test
{
    f() ; // OK
}

void h()
{
    f() ; // ill-formed
}

テスト修飾された関数やクラスは、非テスト修飾されたコードから使うことはできない。

N4421: C++ Standard Evolution Active Issues List

N4422: C++ Standard Evolution Completed Issues List

N4423: C++ Standard Evolution Closed Issues List

C++の新機能提案に対する既存の問題、解決済みの問題、却下された問題。

N4424: Inline Variables

inline変数の提案。

以下のようなコードを含むライブラリーがあるとする。

// library.h
struct X
{
    static int data ;
} ;

このライブラリーはヘッダーのみで使えることを想定した設計にしたい。さて、このstaticデータメンバーをどこかの翻訳単位で定義しなければならない。ではどこで定義すればいいのだろうか。

これを解決するには、inline関数がstaticストレージ上の変数へのリファレンスを返せばよい。

namespace detail {
    int & get_data()
    {
        static int data ;
        return data ;
    }
}

これは動くが、余計な関数をひとつ書かなければならないし、変数を使うときに冗長な関数呼び出し式を書かなければならない。

N4424提案は、変数をinline宣言することで、プログラム中で共通の実体を指すようにしてくれるものだ。

// library.h
struct X
{
    // クラス外に定義を書く必要はない
    static inline int data ;
} ;

以前提案されていたN4147は、inline変数というよりは、inline式とも言うべきもので、初期化子の式が、その副作用も含めて、変数を使った場所で評価されるというものだった。今回のN4424提案はどこかの翻訳単位に定義を書かずともプログラム中で共通の実体を指すという目的を限定したものになっている。

[PDF注意] N4425: Generalized Dynamic Assumptions

コンパイラーは最適化のために様々な情報を必要とするが、そのような情報は外部の環境に依存していて、コード中から取得できないことがある。もし、プログラマーがそのような乗法をコンパイラーへのヒントとして記述することができれば、コンパイラーはよりよく最適化ができる可能性がある。この提案は、そのような前提条件を記述できるコア言語機能を追加する提案である。

すでに、既存のC++コンパイラーで、コンパイラーに前提条件のヒントを与える独自拡張を提供しているものがある。

MSVCは__assume(expression)というintrinsicを提供している。ここに書かれた式はtrueとなるとみなされる。コンパイラーはこの情報を使って最適化ができる。式は評価されない。

IntelのC++コンパイラーも__assumeに加えて、__assume_alignedを提供している。これはポインターのアライメントの保証を記述するものである。

IBMのXLコンパイラーは__alignxというポインターのアライメント保証を指定するための機能を提供している。

Clangは__builtin_assumeと__builtin_assume_alignedというintrinsicを提供している。また、MSVC互換モードの場合、__assumeも受け付ける。

GCCは__builtin_unreachableと__builtin_assume_alignedを提供している。

提案されている文法は、既存のtrue/falseキーワードを再利用するものだ。

true(expression)は、オペランドの式がtrueと評価されることを保証する。false(expression)は、式がfalseと評価されることを保証する。式は実際には評価されない。


true( ++i ) ; // 式は実際には評価されないので、iはインクリメントされない。

true( i == 5 ) ; // コンパイラーはiは5と等しいとみなしてよい

true( false ) ; // この文には到達しない(コンパイラーはこの文を含むコードパスを除去してよい)

false( i < 2 ) ; // iは2未満にならない

void foo( int i )
{
    true( i > 6 ) ; // iは6より大きい保証

    // この分岐はコンパイル時に評価できるし、除去できる
    if ( i < 3 )
    {
        // ...
    }
}

また提案では、alingof演算子を拡張して、true/false演算子の中で使えるようにしている。

void bar( float * q, const float * p, int n, int m )
{
    true( alignof(p) == 16 && alignof(q) == 16 ) ;
    true( m % 16 == 0 ) ;


    // mは16の倍数であることが保証されているので、
    // コンパイラーは実行時のチェックなしに、
    // このループを余さず展開したりベクトル化したりできる
    for * int i = 0 ; i < n ; ++i )
    {
        q[i] = p[i] + p[i+m] ;
    }
}

契約プログラミングをより低級にした感じだ。

N4426: Adding [nothrow-]swappable traits

std::is_nothrow_swappable<T>を追加する提案。

加えて、この提案では、std::is_swappable<T>, std::is_swappable_with<T, U>, std::is_nothrow_swappable_with<T, U>も追加する。

[PDF注意] N4427: Agenda and Meeting Notice for WG21 Pre-Lenexa Telecon Meeting

電話会議の予定表

[PDF注意] N4428: Type Property Queries (rev 4)

静的リフレクション機能として、enum型とクラス型の情報を取得できるstd::enum_tratisとstd::class_traitsの提案。

enum_traitsは、テンプレートに渡したenum型の列挙子の識別子と値を取得できる。

利用例

template < typename T,  std::size_t I >
int print( )
{
    std::cout << std::enum_traits<T>::enumerators::identifier << '\n'
        << std::enum_traits<T>::enumerators::value << std::endl ;
    return 0 ;
} 

template < typename ... dummy >
void expand( dummy ... ) { } 


template < typename T, std::size_t ... I >
void print_enumerators_impl( std::index_sequence< I ... > )
{
    // 引数の評価順序を固定しようというN4228提案が可決されることを信じている
    expand( print< T,  I > ( ) ... ) ;
}

template < typename T,
    typename Indices = std::make_index_sequence< std::enum_traits<T>::enumerators::size > >
void print_enumerators( )
{
    print_enumerators_impl<T>( Indices() ) ;   
}

class_traitsについて詳しくは論文を参照してもらうとして、提案では基本クラスの型とvirtual基本クラスかどうか、メンバーの識別子とポインター、ネストされた形の識別子と型の一覧を取得できる。取得できるのはpublicなメンバーのみ。

このようなtraitsにしておけば、将来の拡張は容易いとしている。

また論文は、将来の拡張として、reflectidというキーワードを提案している。これは、reflectid(E)のように使う。オペランドに式を与えると、decltypeのように、式を評価した結果の型を使う。reflectid(E)のEがenum型の場合、結果はenum_traits<E>型になる。reflectid(C)のCがクラス型の場合、結果はclass_traits<C>になる。

reflectidが必要な理由は、アクセス指定に対応するためだ。reflectidが導入されれば、reflectidが使われた文脈に応じた情報を列挙したclass_traitsが得られる。また、名前空間はテンプレートパラメーターで渡す方法がないため、reflectidのようなコア言語でのサポートが必要だ。テンプレートもテンプレートに渡すよりは、reflectidが欲しい。

Clangベースの実験的実装が公開されている。

ChristianKaeser/clang-reflection

N4429: Rewording inheriting constructors (core issue 1941 et al)

継承コンストラクターの挙動を変更する提案。継承コンストラクターはusing宣言の文法を使うが、挙動が異なる。これまで、派生先でコンストラクターを生成して、基本クラスのコンストラクターにデリゲートするような定義をされていた。これにより、using宣言とは違った挙動が生じてしまう。

提案では、継承コンストラクターの挙動を、派生先クラスが基本クラスのコンストラクターを本当に継承したかのように定義する変更を提案している。これにより破壊的変更もあるが、挙動の不一致がなくなり、より自然になる。

具体的な例は論文を参照してもらうとして、様々な例が上げられている。

よい変更だと思う。

ドワンゴ広告

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

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

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

2015-06-07

江添ボドゲ会@6月を開催した

江添ボドゲ会@6月 - connpass

江添ボドゲ会@6月を開催した。

今回は、新たなボドゲとして、Splendorとコヨーテと犯人は踊るを仕入れた。

今回の参加者は8人だった。前回は20人近い参加者が来たが、今回は少しおとなしかった。

今回の料理はカレーにした。カレーを作ったのは久しぶりかもしれない。

今回、ウー・ウェンの切菜刀 WN155というものを買ってみた。自分の包丁が欲しくていろいろ調べた結果、これが最も手頃で使いやすそうだと判断したためだ。実際に使ってみると、これがとても使いやすかった。鋼の両側をステンレスで挟んだ三重構造になっているため、錆びやすく切れ味もよいし、研ぎやすいはずだ。

今回のボドゲ会では、去年に買ったまま放置していたイカサマゴキブリが開封されてプレイされていたようだ。私はプレイできなかったのが残念だ。

さて、毎月第一土曜日に開いている江添ボドゲ会も、だいぶ定着してきた。ただし、部屋が狭すぎるように思う。これを解決するためにも、また、通勤の手間を省くためにも、そろそろ引越しをしたくある。引越し先はリビングの面積を重視したい。しかし、そうすると自分でシェアハウスを建ち上げるのがよく思えてきた。

条件としては、職場の徒歩圏内に家が欲しい。リビングが広くてボドゲが開催できること。4部屋以上あることだ。いくつかふさわしい物件を見つけ、実際に不動産屋に聞きに行っているのだが、どうもなかなか決まらない。すでに先約があったりする。中でも惜しかった物件は、まだ人が住んでいて来月まで内見すら出来ないのに、すでに申し込みが入っているそうだ。流石に現物を見ずに申し込みなどできるわけがないので、惜しいながらも以下の物件は見送った。

【SUUMO】東京都江東区富岡1/門前仲町駅の賃貸・部屋探し情報(100027149628) | 賃貸マンション・賃貸アパート

法人契約が必要な物件は広告でその旨を書くべきだと思う。検討するだけ時間の無駄だ。

もうひとつ、東京の賃貸事情で特殊なことには、ある程度の規模の賃貸となると、所有者が法人相手にしか貸さないということだ。リスク回避のためでもあろうが、そのせいで借り手がいないのであれば大変な機会損失ではないのだろうか。とある場所に、同僚が5人で住めば実質一人あたりの月負担が2万円という素晴らしい物件があったのだが、法人契約を要求されたため諦めた。弊社社員は、職場近くに済むことが多いのだが、銀座近くは、ワンルームでさえ月9万円が最低価格だ。それを考えれば実にいい物件なのだが、所有者が貸さないというのであればどうしようもない。

そういえば、先週末に京都に行った時、町中を歩いているて不動産屋の前の広告をチラと眺めた時、筆者は思わず愕然としてしまった。西大路通に4LDKが月6万で出ているではないか。しかも礼金なしだという。何らかの理由があるのであろうが、それにしてもこの価格はありえない。いや、京都が安いのではない。東京の賃貸価格が高すぎるのだろう。

今はこの物権をねらっている。

【SUUMO】東京都江東区佐賀1/門前仲町駅の賃貸・部屋探し情報(100027332062) | 賃貸マンション・賃貸アパート

2015-06-05

C++標準化委員会の文書 2015-04-pre-Lenexaのレビュー: N4410-N4419

N4410: Responses to PDTS comments on Transactional Memory

Transactional Memory TSに対するNBコメントに対する返答。

日本からは反対意見をいくつか送った。

JP1では、トランザクショナルセーフという概念がmath.hにも適用されるのは既存のコードのパフォーマンスの劣化を招く恐れがあるという反対意見を送った。例えば、浮動小数点数の精度を実行時に非トランザクショナルセーフに変更する実装が多いが、これをトランザクショナルセーフにするには、極めて高いコストを支払わなければならないという懸念だ。

回答はrejectされた。math.hは意図的にトランザクショナルセーフから外されているとのことだ。

前回のC++WG JPの会議では、それならば問題はないが、ドラフトにはそのような文面が見当たらないので要確認という結論になった。

JP2では、関数のブロックスコープのstaticストレージ上の変数は非トランザクショナルセーフにすべきだという反対意見を送った。アトミック実行が非アトミック実行と同期しなければならなくなる懸念がある。

回答は、rejectされた。関数のブロックスコープのstaticストレージ上の変数はトランザクショナルだろうが非トランザクショナルだろうが、アトミックであるべきだという合意があるからだという。現行の規程が、非トランザクショナルなコードパスに余計なオーバーヘッドをもたらす懸念はないという。

これを受けての日本での議論は詳細に覚えていないが、まあ、コンパイラー屋も出席する会議でそういう合意が得られたのであればそうなのだろうという雰囲気だったような気がする。

N4411: Task Block (formerly Task Region) R4

fork-joinライブラリとして、Task Blockライブラリの提案。前回までの提案では、Task Regionと呼ばれていたが、OpenMPの文脈で別の意味に使われていて混同される可能性があるということ、task regionは名詞であるので、関数名としては、動詞が好ましいことから、task blockに解明された。また、task_region_finalに何らfinal的な意味合いはないのでdefine_task_block_restore_threadに改名した。task_blockクラスを作る関数をtask_regionをdefineプレフィクスをつけてdefine_task_blockにしたので、task_region_handleもhandleサフィックスをとってtask_blockに改名した。

利用例

template<typename Func>
int traverse(node *n, Func&& compute)
{
    int left = 0, right = 0;

    define_task_block([&](task_block& tb) {
        if (n->left)
            tb.run([&] { left = traverse(n->left, compute); });
        if (n->right)
            tb.run([&] { right = traverse(n->right, compute); });
    });

    return compute(n) + left + right;
}

N4412: Shortcomings of iostreams

i2015-02-24のCologne LWG会議でostreamの問題点の話し合いをまとめた文書らしい。

XMLやJSONのようなデータのテキスト表現を行うプロトコルがあり、この場合の機械的に精製されたテキスト表現はロケールに依存すべきではない。

整数や浮動小数点数と文字列との相互変換の方法が簡単にできない。

浮動小数点数に関しては、値をテキスト表現に変換して戻す信頼できる方法が存在しない。

std::streambufはBase64エンコードのようなバイトストリーム処理に適してない。

std::filebufのようなものはコード変換を行うべきではない。コード変換はstd::streambufのフィルターとして行うべきだ。

入出力操作におけるOSのエラー通知はユーザー側に渡されるべきで、ライブラリで握りつぶすべきではない。

フォーマット方式はフラグで設定するが、これはstreamオブジェクトに状態として維持されてしまう。

iostreamは文字型とchar_traitsによるテンプレート化がなされているが、char_traitsは現実的に使われていない。

a<< b << c << dのようなチェインは、型安全に任意個の値を出力できるという点では成功したインターフェースだ。ただし、ソフトウェアの規模が大きくなると、オーバーロード解決が煩雑になる。解決不可能だ。

C++11ならば、Variadic Templatesのよるprintfのようなインターフェースが可能になる。

Matt WilsonのFastFormatライブラリや、Boostのlexical_castを参考にしたAPIを考察する価値がある。

ユーザー定義型に対する入出力を拡張できる機能は必須だ。

現在、moneyとtimeのfacetが使われていない。

ロケールが深く組み込まれている。ロケールはグローバルオブジェクトなので、出力する関数呼び出しごとに二回の同期が必要になる。

ロケールは不完全だ。ICUなどの現実的なライブラリを参考に設計すべきだ。

テキストの内部表現は統一したほうが都合がいい。UTF-32は固定長エンコード(寝ぼけてるのか?)だがメモリーフットプリントがUTF-8より多い。

個人的には、iostreamは完全に設計が破綻しているので、これ以上改良を加えるより、捨てたほうがいいと思う。

[PDF注意] N4414: Executors and Schedulers Revision 5

executorライブラリの提案。

ある処理を並列実行するさいに、どのように並列実行するかという方法を、executorという概念から使うことができる。

executorは、void spawn( Func && )という共通のメンバー関数を持つ。

標準では、thread_per_task_executor、thread_pool_executor、loop_executor(タスクを積んでいって一気に呼び出し元のスレッドで処理する)、serial_executor

リファレンス実装が公開されている。

https://github.com/ccmysen/executors_r5/tree/master/include

[PDF注意] N4415: Simple Contracts for C++

契約プログラミングをコア言語でサポートするための提案。属性ベースの機能のようだ。

契約とは、関数の事前条件と事後条件を保証するためのもので、高級なassertとみなすこともできる。

ただし、その目的はエラー報告でもテストフレームワークでもない。期待する動作との齟齬を検出するための基礎的な機構だ。

すでにライブラリによるサポートの提案は出ていたが、コア言語でのサポートの声も大きいので、これはコア言語でサポートをする提案となっている。

契約は関数宣言に属性で記述する。契約に記述された式を評価した結果がfalseとなれば、契約は満たされない。

契約は関数宣言に記述するが、型の一部ではない。ただし、関数は名前で直接呼び出されても、関数へのポインター経由で呼びだされても、契約によるチェックは行われる。

この論文で提案されている文法は、属性を使うものだ。

[[ expects : condition ]] で呼び出す前の事前条件を指定する。

[[ ensures : condition ]] で呼び出した後の事後条件を指定する。

たとえば、Vectorクラスの添字演算子の事前条件は、以下のように書ける

T & operator [] ( size_t i ) [[ expects : i < size() ]] ;

同様に、ArrayViewクラスのコンストラクターの事後条件は、以下のように書ける。

ArrayView( const vector<T> & v ) [[ ensures : data() == v.data() ]] ;

契約はどのように動くのか。

契約の条件式は型チェックされる。

関数の本体が実行される前に、事前条件が評価される。結果がtrueであれば、関数の本体は通常通り実行される。結果がfalseであれば、実行の継続は保証されない。プログラムはabortするか、例外を投げるか、あるいは挙動が未定義ながらそのまま実行を続けるかなど、何らかの実装依存の挙動をする。つまり、規格準拠の実装は契約をすべてチェックしてもいいし、一部のみチェックしてもいいし、あるいは無視してもよいということだ。

同様に、事後条件は関数の戻り値を返した後、ローカル変数を破棄した後、呼び出し元に処理が反る前に評価される。結果がtrueであれば、通常通り処理が継続する。結果がfalseであれば、プログラムは事前条件と同じように、異常終了など、何らかの実装依存の挙動をする。事後条件は例外によって関数を抜けた場合は評価されない。

ここで提案している契約は、あたかもassert( condition )を関数の前後に配置して(ローカル変数などにアクセスできないという制約はあるが)実行したように振る舞う。この設計には現実的な理由がある。

契約チェックの有効無効、一部のみ有効を切り替えることができる。マクロなどを使った切り替え方法を提供することは考えていない。正しいプログラムが正しいデータに対して実行された時は、契約を無視するのは、プログラムの観測可能な挙動に影響を与えないはずだ。つまり、デッドコードの除去的な最適化手法とみなすこともできる。実装は契約チェックの有効無効を切り替える方法を提供することが推奨される。

契約チェックはどの粒度で行われるべきだろうか。関数の宣言単位だろうか。クラス定義定義だろうか、名前空間、翻訳単位、あるいはプログラム全体か? 関数ごととか、プログラム全体の粒度というのは、ほとんどのプログラムにとって現実的な粒度ではない。クラスごととか名前空間ごとなどというのも茨の道だ。この提案では、翻訳単位ごとの契約の切り替えを提案している。

契約が満たされなかった時に、std::abortを呼び出すのは、プログラムによっては適切ではない場合もある。例外を投げたほうがいい場合もあるだろう。ただし、組込みシステムなどの資源が希少な環境でも使えるようにすることを考えると、例外を必須にはできない。関数へのポインターを設定することによるコールバック関数も、デッドコードの除去という点で難しい。多くの超重要なシステムは、不必要なコードを絶対に入れないという厳しいポリシーを持っている。

2014年のUrbana, IL会議でも好まれたように、この提案では、契約違反の挙動を実装依存とし、契約チェックを、all, none, pre-condition, post-conditionだけに限定することを翻訳単位ごとに切り替えるようなことを認める。

この提案に含まれないもの。

この提案は単純化のために、契約プログラミングとして有益な機能の多くを省いた。たとえば、invariantsとか、abstract statesとか、関数の本体に入った際の最初の実引数の値を参照できる機能とか、事後条件で関数の戻り値を参照できる機能だとか、例外時の契約チェックだとかだ。これらの機能は、その価値を判断して無益だと結論したから取り入れなかったのではなく、C++に契約を入れるにあたって単純なものを先に入れ、進化的に改良していく手法をとりたいからだ。

この提案は、既存のABIに変更を加える必要はない。単に型チェックだけを行って後は無視する実装も規格準拠の実装だ。また、実装は事前条件、事後条件に相当するassertを機械的に挿入するだけでも規格準拠となる。このような実装戦略はABIの変更を必要としない。実装は、契約による情報を、挙動を変えない限り、コード生成のヒントとして使うことができる。

関数が複数箇所で宣言される場合、契約は全てに書くべきか。省略すべきか。理想では、契約は一箇所のみに書くべきであるが、単純化のために、以下のルールを提案する。ある翻訳単位で、宣言が契約を持つ場合、後続の宣言もすべて、ODR的に同一の式を持つ契約がなければならない。また、関数宣言が契約を持つ場合、その定義も契約を持たねばならない。実装には翻訳単位を超えて契約が正しいことを確認する義務はない。宣言では契約を書かず、定義だけ契約を書くことも許容される。これはインターフェースから契約を隠すことになるので、その意義は疑問だが。

契約に書ける式とは何か

契約の条件式は、副作用フリーであるべきだ。すなわち、その評価の有無はプログラムの観測可能な挙動に差を生じさせるべきではない。その意味では、constexpr関数に近い。ただし、constexpr関数に限定するのは現実的ではない。そのため、提案では、単に契約の式は副作用フリーであるべきだと記述するに留める。

virtual関数について

virtual関数のオーバーライドは、基本クラスのオーバーライドされるvirtual関数の契約も受け継ぐ。オーバーライダーが契約を記述する場合は、元の関数と同じ契約でなければならない。契約を弱めたり強めたりすることはできない。

struct A
{
    bool f() const ;
    bool g() const ;
    bool h() const ;

    virtual void v() [[ expects : f() && g() ] ;
} ;

struct B: A
{
    void v() ; // OK、継承する
} ;

struct C : A
{
    void v() [[ expects : f()  ]] ; // エラー、弱化
} ;

struct D : A
{
    void v() [[ expects : f() && g() && h() ]] // エラー、強化
} ;

オーバーライド先で事前条件を弱めたり、事後条件を強めたりするのは、技術的に妥当だが、この提案は機能の簡潔さを目的としているので、そのような機能を今回は提案しない。

クラスのメンバー関数の契約が参照できるメンバーとはなにか。

契約はインターフェースの一部であるので、契約でprivateなメンバーを参照してしまうと、隠匿流出になってしまう。この提案では、契約の条件式は、メンバー関数のアクセス指定と同じだけのアクセスができると規定している。

  • publicメンバー関数の契約は、publicなメンバーのみを参照できる
  • protectedメンバー関数の契約は、publicとprotectedなメンバーを参照できる
  • privateメンバー関数の契約は、すべてのメンバーを参照できる。

friend宣言で関数を定義している場合は、publicなメンバーのみ参照できる。

属性の文法拡張

この提案は、現在のC++11で導入された属性にはない文法として、コロンを使っている。[[ expects : condition ]], [[ ensures : condition ]]。既存の属性の文法で書くと、[[ expects(condition ) ]], [[ ensures(condition) ]]となる。論文では、コロン記法は、C++11のLisp風の属性記法より、読みやすいので、契約以外にも有益であるとして、属性の拡張も提案している。

関数ポインターは、契約の有無は問わない。

double f( double x ) [[ expects : x >= 0.0 ]] ;
double (*pf)( double ) = &f ; // OK

ポインターを契約付きで宣言することもできる。契約がない関数へのポインターを契約付きの関数へのポインター宣言に代入しようとするとエラーになる。


double f( double x ) [[ expects : x >= 0.0 ]] ;
double (*pf)( double ) [[ expects : x >= 0.0 ]] = &f ; // OK

double g( double x ) ;
double (*pg)( double ) [[ expects: x != 0.0 ]] = &g ; // エラー

コア言語に組み込むことで、解析ツールによるサポートもしやすくなった。

Bloombergの提案N4378との比較

Bloombergの提案は、「契約assertの言語サポート」という銘打っているものの、言語サポートについてはよく分からず、その実体は、いいところが単なるasertフレームワークでしかない。その設計はプログラマー外とする箇所に手動で仕込むことを想定している。インターフェースレベルで契約を表現する方法はないし、コンパイラーやツールが効率的に解析できる機構にもなっていない。この提案の想定は、契約とは非公式に英語で書かれるものであって、インターフェースレベルでコード上に書くものではないというものだろう。明らかに、これは解析ツールの役に立たず、契約内容を呼び出し元から見ることもできない。さらに、assert管理はグローバルであるため、assertの利用を完全に決定できる中央権威が存在しなければならない。これは、複数の部署、団体が書いたコードを組み合わせる、たいていの環境のプログラムには適用が難しい。契約assertのコンポーネント単位の管理をないがしろにしてはならない。

N4293との違い

文法をキーワードから属性にした。契約は、正しいプログラムであれば、取り除いても何ら観測可能な挙動に影響を与えないものであるから、属性を使うのは理にかなっている。

N4293で提案されている機能のいくつかを、本提案は単純化のためにサポートしていない。これは将来の拡張に期待したい。

[PDF注意] N4416: Don't Move: Vector Can Have Your Non-Moveable Types Covered

タイトルが面白い。

vectorにコピーもムーブもできない要素型に対応させるためにメンバー関数テンプレートを追加する提案。

C++03のvectorは、コピーできない要素型を扱えなかった。C++11になって、コピーできなくてもムーブできれば扱えるようになった。ただし、ムーブすらできない型は依然として扱うことができない。

vectorがコピーかムーブを要求する理由は、内部ストレージのサイズが足りない場合に、より大きなストレージを確保してオブジェクトの移し替えを行うからだ。

ところで、最近、mutexやatomicをデータメンバーに持つクラスが増えてきている。これらのクラスは、暗黙にコピーもムーブもできない。しかし、このクラスのオブジェクトの集合をvectorに入れて管理したい。

ではどうするのか。提案では、厳密にストレージのサイズを指定するメンバー関数テンプレートと、ストレージのサイズの伸長を行わないemplaceを追加することで対応している。このメンバー関数テンプレートのみを使って要素の追加を行えば、ムーブ不可能な型でも対応できる。

void reserve_initially(size_type n)

コンテナーがempty()の時のみ、厳密にn個の要素分のストレージを確保する。

template <class... Args> void
emplace_back_capped(Args&&... args)

size() < capacityのときのみemplaceする。

emplace_back_cappedが失敗した場合はどうするのか。例外を投げるのか。絶対失敗しないことを事前条件とするのか。提案では、既存のemplaceもストレージを確保できない時は例外を投げるし、既存の挙動と一致するので例外を投げるとしている。

その他には、resizeがある。resize_capped(n, args ...)は、empty()のときに、厳密にn個の要素分のストレージを確保してargs...で構築した要素でemplaceする。resize_downはn <= size()のときにn個にリサイズする。

提案では、一貫性を保つために、dequeやlistやvector、その他のコンテナーアダプターにも同等のメンバーテンプレートを追加することも考察している。

[PDF注意] N4417: Source-Code Information Capture

__LINE__, __FILE__, __func__に変わるまともなソースコード情報を取得できるクラスライブラリの追加提案。静的リフレクション機能の一つだ。

前回の提案であるN4129からの変更点は、offset_from_start_of_fileの削除と、コンストラクターにコンパイラーマジックがなくなったこと。かわりにcurrentが追加された。あとp

int main()
{
    std::source_location info ; // この場所のソースコード情報を保持

    std::cout
        << "line: " << info.line_number() // 行番号
        << "\ncolumn: " << info.column() // 行頭からの文字数
        << "\nfile name: " << info.file_name() // ファイル名
        << "\nfunction_name" << info.function_name() // 関数の本体の中の場合関数名、それ以外の場合は空文字列
        << std::endl ;
}

関数の引数に渡すために、特別なconstexpr staticメンバー関数currentが用意されている

// ログ記録用の関数
void logger( std::source_location info ) ;

int main()
{
    logger( std::source_location::current() ) ;
}

currentは呼び出された箇所に相当するsource_locationの値を返す。

[PDF注意] N4418: Parameter Stringization

実引数として与えられた呼び出し元の式を文字列化して取得する機能を追加する提案。これも静的リフレクション機能に分類される。

CプリプロセッサーマクロにできてC++にできないことのひとつに、引数式を文字列化するということがある。


void custom_assert( bool cond )
{
    if ( ! cond )
    {
        std::cout << "assertion failure!: " << "引数に渡した式の文字列" << std::endl ;
    }
}

void f( int * ptr, std::size_t size )
{
    custom_assert( ptr != nullptr ) ;

    // ...
}

このようなコードを実現するには、Cプリプロセッサーマクロの#演算子を使わなければならない。


void custom_assert_impl( bool cond, const char * expr_str )
{
    if ( ! cond )
    {
        std::cout << "assertion failure!: " << expr_str << std::endl ;
    }
}

#define custom_assert ( expr ) custom_assert_impl( (expr), #expr )

void f( int * ptr, std::size_t size )
{
    custom_assert(( ptr != nullptr )) ;

    // ...
}

この提案は、C++にはこのプリプロセッサーの代替機能が必要であるとしている。具体的な文法についてはまだ深く考えられていない。

[PDF注意] N4419: Potential extensions to Source-Code Information Capture

source_location提案に対する拡張提案。

最新の提案では削除されたoffset_from_start_of_fileの追加

行番号に対応するsource_locationを取得する機能の追加。

取得する情報を選ぶことができる機能

大量の長い関数名が存在するソースコードで、関数名情報を取得する場合は、バイナリに関数名を埋め込まなければならず、バイナリが肥大化する。そのために、必要な情報の一部だけを取得できるように、取得する方法を指定できる機能。

ユーザー定義の情報をsource_locationに仕込める機能。

function_nameで得られる名前はデマングルされていないものであることが予測されるので、デマングルした人間に読みやすい名前に変換する機能

ドワンゴ広告

最近、ドワンゴ社内で、何らかの理由により、業務外で交流のない人間と食事に行く需要がにわかに発生しているため、マッチングサービスの実装が望まれている。また、レコメンド機能があると便利かもしれない。「この社員と食事に言った人はこんな社員とも食事に行っています」

また最近、ドワンゴ社内で始まった謎の制度のせいで、アマゾンで特定の技術書が売り切れるという現象が発生しているようだ。

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

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

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

技術を理解しないクソバカの治める国、ニッポン

以下のようなニュースを読んだ。

年金機構、職員の電子メールを禁止 外部向け「当面の間」 - ITmedia ニュース

最近、この国の政治が技術的に全く理解できなくなってきている。私がとうとう狂ってしまったのか、それとも世界がおかしいのか。世人皆濁我独清、衆人皆酔我独醒。とはこの謂か。

この理論で行くと、我々は年金機構からコンピューターを廃止すべきであるし、紙とペンも廃止すべきであるし、そもそも言語自体を廃止すべきだろう。あらゆる情報を記録する方法は廃止されなければならない。

これにつけて思い出すのは、自衛隊がWinnyで流出事件を起こした時、新隊員に一切のストレージの所有が禁じられたという話だ。なんでも、雑誌の付録についているDVDですら処罰の対象になったそうだ。そもそもそのDVDには新たにデータを書き込むことはできないし、その雑誌は自衛隊の駐屯地内の売店で売られているものであるのだが。

そして、皆携帯電話を持っているが、不思議なことに携帯電話はストレージとはみなされないらしい。

皆そうとう酔っているらしい。

そういえば、私が東京に移って予備自衛隊の訓練に行く時に、コンピューターは持ち込んではならないという通達があった。しかし、全員携帯電話を持ち込んでいたし、なぜか地本は私が携帯電話を当然持っていることを想定した連絡をしてきたので実に首を傾げざるを得ない矛盾である。

自衛隊と技術といえば、私はこれを扱ったことがある。

野外通信システム

Wikipediaにも書かれているから周知の事実となっているが、Androidが使われているとだけ言えば、もう問題は察してもらえるだろう。およそSI屋が発明できるソフトウェアにおけるあらゆる問題があまさず詰め込まれていた。本当に考えられるだけの問題はすべて存在している。

寧赴湘流、葬于江魚之腹中、安能以皓皓之白、蒙世之塵埃乎

公衆無線LANサービスへの加入を検討している

たまに、無線によるインターネットが欲しくなる時がある。それほど頻繁には起こらない。せいぜい、月に一度だ。外で他人と連絡を取りたいときや、数時間外ですごさなければならない時だ。こんな時、どうするか。

もし時間があって移動できるのであれば、ネットカフェを探すという手がある。しかし、そういう場合はあまりない。

LTEやWiMAXを契約するほど頻繁に無線ネットワーク回線が欲しいとは思わない。だいいちWiFiルーターを持ち歩くのは面倒だ。

すると、どこかのWiFiサービスと契約するのがいいのではないだろうか。これならWiFiルーターを持ち歩く必要もないし、料金もそれほど高くない。では、どこにするのがよいのか。

少し調べたところでは、au WiFi SPOTは、GNU/Linuxにはまともにクライアントが用意されていないプロトコルを使わなければ認証ができないようだ。

au Wi-Fi SPOTにLinuxから接続できるようにしてみた - Dマイナー志向

フレッツスポットは、WiFiでPPPoEを行わなければならず、UbuntuではGUIのネットワーク設定ではWifi経由でPPPoEを設定できず、pppoeconfを使わなければならないようだ。

とすると、どこだろうか。要件としては、

  • GNU/Linuxで使える(auは無理)
  • 新幹線の中で使える(docomo Wi-Fi, BBモバイルポイント, UQ Wi-Fi, フレッツスポット)
  • 駅の中で使える
  • 町中ですぐに見つかるフランチャイズ店がWiFiを提供している

あたりだろうか。

公衆無線LANサービスは、有線インターネット回線をひくときにISPと契約をすると、オプションでつけられるようになっていることが多い。そろそろ引っ越したいし、引越してISPと契約するときに考えてみようか。

2015-06-03

なぜオカンの買ってくる服はダサいのか

週末に、新幹線で東京から京都に向かっている途中、地震による停電で停車してしまった。あまりにも暇なので、ふとくだらないことを考えた。考えたついでに書き留めておいた。以下がその内容である。

オカンの買ってくる服はダサいという都市伝説。

世の中にはオカンの買ってくる服はダサいという都市伝説が広まっている。この都市伝説が本当に正しいのかどうか、今ここで確認する方法はない。何しろ、私は停電中の新幹線の中でこれを書いているのだ。ただし、個人的には納得できる部分もある。もちろん、服装の美しさを選ぶ能力には個人差がある。中には極めてかっこいい服を選べるオカンもいるだろう。しかし、オカン全体の平均として、オカンの選ぶ服はダサいという

ダサいとはなんだろうか。服の美しさが平均を下回っていることだとする。すると不思議だ。オカンという集合は日本の女全体の集合に比べて、ダサい服を選びやすく偏っているということになる。

少子化の進む現代とはいえ、オカン集合は日本の女集合のかなりの部分を占める。いくらバイアスのかかった選択をされた集合だからといって、オカン集合の平均が全体の平均を大きく下回るというのはどうにも納得できない。

そもそも、養子という極小数の例外を除けば、オカンとなるには生殖行為が必要になる。一般に、ヒトが生殖行為の相手を選ぶ際には、性的魅力の評価が行われる。服装の美しさも性的魅力を評価する情報の一部になるはずである。そのようなバイアスのかかった集合の平均が低いということは、つまり生殖活動をした女は、服装の美しさを選ぶ能力が低いということになる。

しかし、この考察を元に考えれば、オカンになりたい女は服装の趣味を悪くすべしということになる。それはいかにも納得がいかぬ。

ところで、子供がオカンの買ってくる服がダサいと考えるようになる時期は、早くとも10歳前後になるだろう。この期間、オカンの服装の評価に変化が起こるのだろうか。筆者の常識の範囲内で考えてみよう。

仮説1: 子供はよく服を汚す。オカンは汚れてもいい服を買ってくる。汚れてもいい服はダサい。

これは違うように思われる。汚れに強い服、汚れてもよい服といえば、主に作業服だが、平均的なオカンの買ってくる服は作業服ではない。

仮説2: オカンは金を節約するために安い服を買う。安い服は、価格を抑えるためにダサい。あるいは、ダサいがために売れない服が値下げされて投げ売られる。

仮説1よりは納得できる。果たして安い服はダサいのだろうか。凝った刺繍や印刷がされている制作費のかかる服であっても、ダサい服はある。ましてや、ダサすぎるといくら安くても売れない可能性があるため、ダサい服にも限度がある。第一、安価に製造された服は、必ずしもダサくなるものだろうか。

また、親は、個人差はあれど、子供に投資する傾向がある。教育を行わせるのも将来への投資である。一般に、多くの親は、孫の顔が見たいなどと言うものであり、そのためには子供の性的魅力を上げなければならない。ダサい服を着ていては性的魅力がない。孫の顔が見たければ、子供の性的魅力向上にも投資すべきだろう。

仮説3: オカンの服装の美しさの評価基準は親世代のものである。そのため、子世代の評価基準に照らし合わせるとダサい。

筆者の主観だが、親世代に美人であったと目されていた当時の若い女の画像を見ると、若いのにもかかわらず、オバハン臭く感じる。オバハンの評価基準はオカンである。これは、当時の化粧や服装の評価基準が現代と一致しておらず、その評価基準を受け継いだ親世代のオカンが相変わらずそのような化粧、服装をするため、若くてもオバハンだと錯覚するのであろう。

しかし、この仮説にも納得できない。というのは、オカンが服を買ってくる時代は現代である。ダサい服は売れない。現代の洋服屋は、現代の評価基準でダサくない服を売っているはずである。現代の洋服屋で服を買うのに平均を下回る美しさというのはどういうことだろうか。

いや、そもそもオカンの買ってくるダサい服は、購入されているわけである。オカンの大多数がダサい服を購入するのであれば、それはすでに多数派に属するのであって、多数派がダサいと評価されるのは一向に理解できない。

ダサいの評価基準について

ここまで考えて、もしかしたら、服の美しさの評価基準の前提が間違っているのではないかという考えに思い至った。先に筆者は、ダサいとは平均を下回る美しさであると書いた。これは間違っているのではないか。つまりこうだ。平均はダサい。平均は見慣れていてありふれているので、すでにダサいのだ。平均を上回る服のみがかっこいい服なのだ。これならば、平均的なオカンの買ってくる平均的な服がダサいという都市伝説は納得できる。

しかし、この場合、何もオカンに限る必要はない。オトンの買ってくる服も平均的にダサければ、自分で買ってくる服も平均的にダサいということになる。なぜオカンだけが槍玉に上がるのか。子供の服を買い揃えるのはオカンであるというステレオタイプな意見が、このような都市伝説を生むのだろうか、

くだらない考察を続けていると、30分ほどして電気が復旧し、新幹線が動き出した。